SSRF检测的一些思考
DNS平台没有立刻收到请求,是在之后的某个时间段收到了不同的请求信息,这至少表明了一点,此处存在有无回显的SSRF,虽然想要证明有更大的危害比较困难,但是至少说明了存在有SSRF的风险,所以接下来就探究下其原理。
Cracking the lens
项目首页也有介绍,其是根据Cracking the lens's Research写出来的。以笔者不到四级的英语,勉强可以理解作者是通过构造畸形的HTTP
请求、佐以特殊的请求头,使的服务器处理时出现问题,从而请求到自定义的服务器上。听起来似乎很简单,实际利用时也确实如此工具collaborator-everywhere,比起英文,代码要好理解一些。其定义了注入点以及payload
的形式

其会对请求进行处理,在每次请求中添加上述payload

可以注意到无论注入点是什么,都会加入一个请求头Cache-Control: no-transform
,该字段主要作用是控制缓存,而no-transform
的意思为无论什么情况,都不对请求响应做任何处理。加入这个字段是为了防止在传输中请求被处理,从而导致无法正常进行检测。经过处理后的请求头看起来是这样的

【一>所有资源获取<一】
1、网络安全学习路线
2、电子书籍(白帽子)
3、安全大厂内部视频
4、100份src文档
5、常见安全面试题
6、ctf大赛经典题目解析
7、全套工具包
8、应急响应笔记
到目前为止其实已经可以发现SSRF
了,不过只有访问记录还不够,还需要将触发请求-访问记录关联起来,贴一张作者检测出的结果

它会循环的去检测collaborator
是否有收到请求,然后将请求及其产生原因展示出来


至此,该工具实现原理算是明白了,不过很显然比起文章中所介绍的,它的注入点只涵盖了header
字段,而Blind-SSRF可以看作是它的补充
Blind-SSRF
可以把它的模板分为三种类型的:
- 增加特定请求头
- 修改
Host
字段 - 对
URL
进行处理
增加请求头这一点其实不用多说什么,与上文一样,不同之处在于其采用了一个请求增加一个字段的方式,它的一个请求包看起来是这样的

WL-Proxy-Client-IP
与X-Forwarded-For
类同,一般情况下是用来获取客户端IP
的。
针对后两种的处理则是要复杂不少,其一般都是逻辑处理失误所导致的问题,例如原文中提到的例子
Url backendURL = "http://public-backend/";
String uri = ctx.getRequest().getRawUri();
URI proxyUri;
try {
proxyUri = new URIBuilder(uri)
.setHost(backendURL.getHost())
.setPort(backendURL.getPort())
.setScheme(backendURL.getScheme())
.build();
} catch (URISyntaxException e) {
Util.sendError(ctx, 400, INVALID_REQUEST_URL);
return;
}
在Apache HttpComponents 4.5.1
版本时它并不会检测uri
是否是/
开头的,这意味着我们可以通过构造畸形的HTTP
请求,从而访问到指定backendURL
外的地址,例如:

经过拼接后获取到的proxyUri
其实就是http://public-backend@host
这样的形式了,@
前的public-backend
会被当作用户名,而真正请求的地址则是uri
中指定的host
。
Burp4SSRF
前文中的两个工具已经可以检测出SSRF
了,但是还存在些许缺陷:
-
collaborator-everywhere 情况覆盖不全面、此外其把请求中的
referer
等直接修改后有时会导致请求出错 -
blind-ssrf 不能直观的展示出漏洞情况
针对这些问题,笔者决定对collaborator-everywhere
做一个简单的修改,让它覆盖面更广,同时采用被动扫描的方式,防止对正常请求造成影响。
首先是请求方式的修改,这个就很简单了,只需要将原先的继承自IProxyListener
改为IScannerCheck
即可,前者表明在请求进行时对请求做处理,而后者则是交给主动或被动扫描器进行处理,更改之后的扫描逻辑就在Injector
的doPassiveScan
函数当中了

当injectPayloads
将header
与param
注入到request
中后,使用makeHttpRequest
函数发送请求。
除此之外就是对Host
以及uri
作为注入点时的处理,这里新加入了一个injectAnyWhere
函数

在处理完常规注入点后,剩下的raw
以及host
单独进行处理,这里的raw
是从请求包的第一行开始进行替换,因为这两种类型都会对请求体造成不可逆的影响,所以此处对每一个payload
都发送一次请求,而不是像前一种情况,所有payload
整合之后一次发送。至此已经解决了最开始的几个问题,实际使用后的结果:

总结
这并不是一项新的技术,但是在实际渗透中往往会有意想不到的收获
目前只是简单的改进了下原有的工具,下一步要做的事还有很多,比如Burp自带的DNSLog
有时会抽风,再比如通过burp日志查看请求时会发现某些畸形请求无法查看……不过方法总比困难多。
网友评论