Weblogic SSRF
漏洞是一个比较经典的
SSRF 漏洞案例，该漏洞存在于
http://127.0.0.1:7001/uddiexplorer/SearchPublicRegistries. jsp 页面中，如图 1
-1
所示
图 1-1 Weblogic SSRF 漏洞
Weblogic SSRF
漏洞可以通过向服务端发送以下请求参数进行触发，如果该
IP和端口存在并且开放，则返回以下信息，如图 1-2
所示
rdoSearch=name&txtSearchname= sdf&txtSearchkey=&txtSearchfor=&selfor=
Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001
图 1-2 IP 或端口存在且开放时返回的信息
如果该
IP
不存在或者端口不存在，则返回以下信息，如图
6-13
所示
图 1-3 IP 或端口不存在时返回的信息
根据请求的
URI
可以看到请求的是
SearchPublicRegistries.jsp
，该文件的存储路径为
user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/ uddiexplorer/
5f6ebw/war/SearchPublicRegistries.jsp
。
从请求的 URL
中可以发现最关键的参数是
operator
参数，在
SearchPublic Registries.JSP 文件的第
48
行获取了该参数，如图 1
- 4
所示。
图 1-4 operator 参数
在第 102
行调用
search.setOperator
方法并将
operator
作为参数传入，并在第
107行调用 search.getResponse
方法，如图 1
-5
所示
图 1-5 调用 search.getResponse 方法
getResponse方法的第
65
和
66
行分别调用了一个
Http11ClientBinding
对象的
send方法和 receive
方法，当探测的
IP
存在且端口开放时，会在
receive
方法处抛出异常，异常类型为 IOException
。当探测的
IP
不存在或者端口不开放时，会在
send 方法处抛出异常，异常类型为
IOException
。如图 1
-6
所示
图 1-6 调用 send 方法和 receive 方法
抛出的异常在第
88
行被封装成一个
XML_SoapException
对象返回给客户端，如图 1-7
所示
图 1-7 XML_SoapException 对象
异常内容就是
var18.getMessage
方法返回的结果，如图 1
-8
所示
图 1-8 var18.getMessage 方法返回的结果
小结
SSRF 漏洞犹如一位隐形杀手，常年隐匿于大型站点中不起眼的角落，有非常大的威胁。国内的互联网科技公司如腾讯、阿里巴巴、华为、百度等，均出现过 SSRF漏洞，且具有一定的危害。在安全问题愈发得到重视的现在，SSRF
漏洞也得到了“特别关注”。
因此对于安全审计人员来说，更应注意 SSRF 漏洞的挖掘，除了基本的搜索关键函数审计的方法外，还要注意源程序对于 SSRF
的防御策略是否存在漏洞，攻击者是否可以绕过其防御策略，或者能否配合特殊环境下的配置，形成漏洞利用链。另外需要注意的是，代码审计绝不意味着纯白盒审计。SSRF
漏洞也可以通过黑盒的方式去挖掘、测试，能挖掘出漏洞且不影响正常业务的方式都是好方式。