Day21
示例代码:
1 | public class Decrypter{ |
对称加密CBC的Padding Oracle攻击,已知密文699c99a4f27a4e4c310d75586abe8d32a8fc21a1f9e400f22b1fec7b415de5a4
,在不知道密钥的情况下,通过该漏洞获取明文。漏洞原理这里不具体表述,直接写个python脚本得到明文结果。
如下:
Day22
示例代码:
1 | public class ReadExternalUrl extends HttpServlet { |
getUrl()
方法主要对target
值进行校验,是否以http开头,是否为有效的外部URL,并通过setFollowRedirects()方法设置为不可重定向。在第二部份中允许设置Location头进行重定向,且对传入的Location头只校验是否有http://
。此时,发送恶意用户所控制的Location头,则可进行SSRF。同时由于对Location头的校验不严,又可能产生文读取漏洞。
1 | import socket |
注:这里虽然说说通过setFollowRedirects()方法设为禁止重定向,但这个配置好像没起到作用,不知道是不是我个人环境问题。
Day23
示例代码:
1 | public class ShowCalendar extends HttpServlet { |
StringEscapeUtils.escapeHtml4()
方法只对name参数进行转义。calendar
对象所包含的TimeZone为用户传入的id
值,格式化输出时,调用内部的toString()方法,同时并示对其进行过滤转义,此时若id
传入的值为恶意的代码,则会产生格式化字符串漏洞。
poc:
1 | http://127.0.0.1:8888/day23/ShowCalendar?id=%3Cscript%3Ealert(1)%3C/script%3E¤t_time=2001-07-04T12:08:56&name=%25shell |
Day24
示例代码:
Invoker.java
1 | class Invoker implements Serializable { |
day24.java
1 | "/unserialize", consumes = "text/xml") (value = |
用户传入的xml数据被DocumentBuilderFactory解析为一个实例,通过disallow-doctype-decl
设置为true
,故不存在xxe漏洞。接着通过xPath表达式过滤出属性serialization='custom'
的第一个节点。随后转化为字符串后通过XStream进行反序列化。Invoker.java
文件中,Invoker类和User类都实现了Serializable接口,都使用了readObject()方法。Invoker类的readObject方法允许我们通过使用字符串数组调用构造函数并调用该对象的用户控制方法(不带参数)来创建任意对象。同时利用User类的内部的Invoker子类,绕过xPath的检查。
poc如下:
1 | <it.lingwu.test.User serialization="custom"> |
可看到正常执行系统命令。
总结
没想到这24个漏洞拖了这么长时间,虽然各个漏洞利用链并不复杂,但涉及的种类还是蛮多,像我这种对代码基础较差的能学到很多东西。