2. SSRF

SSRF(Server-side Request Forge, 服务端请求伪造)。

由攻击者构造的攻击链接传给服务端执行造成的漏洞，一般用来在外网探测或攻击内网服务。

SSRF漏洞形成的原因大部分是因为服务端提供了可以从其他服务器获取资源的功能，然而并没有对用户的输入以及发起请求的url进行过滤&限制，从而导致了ssrf的漏洞。
通常ssrf容易出现的功能点如下面几种场景

• 抓取用户输入图片的地址并且本地化存储
• 从远程服务器请求资源
• 对外发起网络请求
• ……

黑客在使用ssrf漏洞的时候，大部分是用来读取文件内容或者对内网服务端口探测，或者在域环境情况下且是win主机下进行ntlmrelay攻击。

URL url = new URL(url);
URLConnection connection = url.openConnection();
connection.connect();
connection.getInputStream();
StringBuilder response = new StringBuilder();
BufferedReader in = new BufferedReader(
new InputStreamReader(connection.getInputStream()));
String line;
while ((line = in.readLine()) != null) {
    response.append("/n").append(line);
}
System.out.print(response.toString());

比如上面代码中的url可控，那么将url参数传入为file:///etc/passwd

URL url = new URL("file:///etc/passwd");
URLConnection connection = url.openConnection();
connection.connect();
...

以上代码运行以后则会读取本地/etc/passwd文件的内容。

但是如果上述代码中将url.openConnection()返回的对象强转为HttpURLConnection，则会抛出如下异常

Exception in thread "main" java.lang.ClassCastException: sun.net.www.protocol.file.FileURLConnection cannot be cast to java.net.HttpURLConnection

由此看来，ssrf漏洞也对使用不同类发起的url请求也是有所区别的，如果是URLConnection|URL发起的请求，那么对于上文中所提到的所有protocol都支持，但是如果经过二次包装或者其他的一些类发出的请求，比如

HttpURLConnection
HttpClient
Request
okhttp
……

那么只支持发起http|https协议，否则会抛出异常。
如果传入的是[http://192.168.xx.xx:80](http://192.168.xx.xx:80)，且192.168.xx.xx的80端口存在的，则会将其网页源码输出出来

但如果是非web端口的服务，则会爆出Invalid Http response 或Connection reset异常。如果能将此异常抛出来，那么就可以对内网所有服务端口进行探测。
java中默认对(http|https)做了一些事情，比如:

• 默认启用了透明NTLM认证
• 默认跟随跳转

关于NTLM认证的过程这边不在复述，大家可以看该文章《Ghidra 从 XXE 到 RCE》
默认跟随跳转这其中有一个坑点，就是

它会对跟随跳转的url进行协议判断，所以Java的SSRF漏洞利用方式整体比较有限。

• 利用file协议读取文件内容（仅限使用URLConnection|URL发起的请求）
• 利用http 进行内网web服务端口探测
• 利用http 进行内网非web服务端口探测(如果将异常抛出来的情况下)
• 利用http进行ntlmrelay攻击(仅限HttpURLConnection或者二次包装HttpURLConnection并未复写AuthenticationInfo方法的对象)

对于防御ssrf漏洞的攻击，不单单要对传入的协议进行判断过滤，也要对其中访问的地址进行限制过滤。