《SSRF检测的一些思考》

     项目首页也有介绍，其是根据Cracking the lens's Research^[2]写出来的。以笔者不到四级的英语，勉强可以理解作者是通过构造畸形的HTTP请求、佐以特殊的请求头，使得服务器处理时出现问题，从而请求到自定义的服务器上。听起来似乎很简单，实际利用时也确实如此，因为作者已经给出了工具collaborator-everywhere^[3]，比起英文，代码要好理解一些。其定义了注入点以及payload的形式

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

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

到目前为止其实已经可以发现SSRF了，不过只有访问记录还不够，还需要将触发请求-访问记录关联起来，贴一张作者检测出的结果

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

至此，该工具实现原理算是明白了，不过很显然比起文章中所介绍的，它的注入点只涵盖了header字段，而Blind-SSRF^[1]可以看作是它的补充

可以把它的模板分为三种类型的：

1. 增加特定请求头

2. 修改Host字段

3. 对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。

前文中的两个工具已经可以检测出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整合之后一次发送。至此已经解决了最开始的几个问题，实际使用后的结果：

这并不是一项新的技术，但是在实际渗透中往往会有意想不到的收获，改进后的工具已放在github：Burp4SSRF^[4]，目前只是简单的改进了下原有的工具，下一步要做的事还有很多，比如Burp自带的DNSLog有时会抽风，再比如通过burp日志查看请求时会发现某些畸形请求无法查看......不过方法总比困难多，新的一年也要继续写bug哦😋😋😋

• [1]

  https://github.com/0xAwali/Blind-SSRF

• [2]
  

  https://portswigger.net/research/cracking-the-lens-targeting-https-hidden-attack-surface

  
  

• [3]

  https://github.com/PortSwigger/collaborator-everywhere

  
  

• [4]

  https://github.com/No4l/Burp4SSRF

  
  

• https://youtu.be/zP4b3pw94s0

  
  

• https://portswigger.net/burp/extender/api/