SSRF安全指北(2)

相对于php，在java中SSRF的利用局限较大，一般利用http协议来探测端口，利用file协议读取任意文件。常见的类中如HttpURLConnection，URLConnection，HttpClients中只支持sun.net. (java 1.8)里的所有协议:http，https，file，ftp，mailto，jar，netdoc。

但这里需要注意一个漏洞，那就是weblogic的ssrf，这个ssrf是可以攻击可利用的redis拿shell的。在开始看到这个漏洞的时候，笔者感到很奇怪，因为一般java中的ssrf是无法攻击redis的，但是网上并没有找到太多的分析文章，所以特地看了下weblogic的实现代码。

详细的分析细节就不说了，只挑重点说下过程，调用栈如下

我们跟进sendMessage函数（UDDISoapMessage.java）

sendMessage将传入的url赋值给BindingInfo的实例，然后通过BindingFactory工厂类，来创建一个Binding实例，该实例会通过传入的url决定使用哪个接口。

这里使用HttpClientBinding来调用send方法，

send方法使用createSocket来发送请求，这里可以看到直接将传入的url代入到了socket接口中

这里的逻辑就很清晰了,weblogic并没有采用常见的网络库，而是自己实现了一套socket方法，将用户传入的url直接带入到socket接口,而且并没有校验url中的CRLF。

SSRF的攻防过程也是人们对SSRF漏洞认知不断提升的一个过程，从开始各大厂商不认可SSRF漏洞->攻击者通过SSRF拿到服务器的权限->厂商开始重视这个问题，开始使用各种方法防御->被攻击者绕过->更新防御手段，在这个过程中，攻击者和防御者的手段呈螺旋式上升的趋势，也涌现了大量绕过方案。

常见的修复方案如下：

用伪代码来表示的话就是

if check_ssrf(url):

do_curl(url)

else:

print(“error”)

图中的获取IP地址和判断IP地址即是check_ssrf的检验，所有的攻防都是针对check_ssrf这个函数的绕过与更新，限于篇幅原因，这里取几个经典绕过方案讲解一下

30x跳转也是SSRF漏洞利用中的一个经典绕过方式，当防御方限制只允许http(s)访问或者对请求的host做了正确的校验后，可以通过30x方式跳转进行绕过。

针对只允许http(s)协议的情况，我们可以通过

Location: dict://127.0.0.1:6379跳转到dict协议，从而扩大我们攻击面，来进行更深入的利用。

针对没有禁止url跳转，但是对请求host做了正确判断的情况，我们则可以通过Location: :6379的方式来绕过限制

其实在SSRF利用的过程中也零星有利用url解析导致绕过check_ssrf的payload，但大部分利用payload之所以能成功是因为防御者在编写代码时使用的正则匹配不当。第一个正式的深入利用是orange在blackhat大会上提出的A-New-Era-Of-SSRF-Exploiting，利用语言本身自带的解析函数差异来绕过检测，在该ppt中举例了大量不同编程语言的url解析函数对url解析的差异，从而导致check_ssrf和do_curl解析不同导致的绕过，有兴趣的同学可以参看附录一，这里以笔者发现的一个例子作为讲解。

在python3中，笔者发现对于同一个url:@qq.com，urllib和urllib3的解析就不一致。