Chapter05-SSRF

1.SSRF简介

SSRF(Server-side Request Forgery)，服务端请求伪造，允许用户命令服务器向非预期的目标发起请求。
SSRF可能导致内网探测、文件读取、任意命令执行等危害。

2.常见的SSRF攻击

SSRF利用信任关系从Web应用进行攻击（内网防御往往薄弱），执行未授权的操作，如内网探测、文件读取等。

2.1 针对当前服务器的SSRF

攻击者通过回环地址(通常为127.0.0.1或localhost)，允许计算机将消息发送给本机。Web应用往往会信任内网机器的请求。因为

1. 信任边界突破，某些页面可能仅本地访问，但是通过SSRF，间接实现了本地访问。
2. 认证绕过，访问控制检查在Web应用前的不同组件完成，内部服务没有外部服务那样严格的认证机制。
3. 灾难恢复，Web应用可能允许本地计算机在未登录认证的情况下访问，为管理员丢失凭据时提供了一种恢复系统的方法

SSRF案例：
假设有一个购物网站，允许用户查看某商品是否有库存。
网站需要查询后端REST api，通过HTTP请求将URL传递给后端API端点。
当用户查询时，服务器向指定的URL发起请求，并将结果返回给用户。如果服务器没有对URL进行过滤，那么SSRF就可能产生了。
攻击者可能会尝试访问本机的/admin页面。

stockApi = http://localhost/admin
从外网访问需要权限认证，但是该URL请求来自本机，那么可能会赋予完全访问权限。

此时可以尝试是否存在SSRF漏洞

此时可以利用intruder（1）探测内网开放端口

（2）探测内网目录

2.2 针对其它后端系统的SSRF

在某些情况下，Web服务器能够与其它用户无法访问的后端系统进行交互，这些系统通常具有不可路由的内网IP地址。
后端系统由于网络拓扑结构的保护，因此往往具有较弱的安全态势。许多情况下，内网系统包含敏感功能，并且能够与其交互的人往往不需要身份验证就能访问。

假设内网其它主机有一个管理接口，https://192.169.0.52/admin，此时攻击者可以利用Web网站的SSRF漏洞，访问其他主机的管理页面。即，利用当前主机为跳板
（1）同子网段存活主机探测
（2）目标主机目录探测，发现/admin目录，并且可以未授权访问

2.3 常见SSRF防御的绕过

2.3.1 基于黑名单的绕过

Web网站可能会阻止主机名的输入，如127.0.0.1和localhost，或阻止敏感目录(敏感URL)的访问。此时可以尝试绕过：

1. 使用127.0.0.1的替代表示，如十进制(2130706433)或十六进制(7F000001)的形式，或尝试127.1
2. 尝试注册自己的域名，并将地址解析为127.0.0.1
3. 使用URL编码或大小写绕过等方式，混淆字符串
4. 一个自己控制的URL，重定向到目标URL。尝试不同的重定向代码和目标URL的不同协议

案例：

1.访问目标网站功能，抓包分析流程，发现其会向后端API发送url请求
2.尝试修改url，令其访问本机，被拦截

3.将loaclhost修改为十进制形式、十六进制形式、127.1形式，发现十进制无效、十六进制无法识别、127.1绕过了检测
（1）十进制表示
（2）十六进制
（3）127.1形式

4.尝试访问本机admin接口(REST api)，发现被拦截

5.大小写绕过，二次URL编码都能绕过桡
6.此时，我们可能无法在直接网页中删除user，因为要通过SSRF漏洞点作为跳板，才可以访问内网API，并执行操作
7.查看返回包，找到网页中的功能接口
8.将路径拼接到SSRF漏洞url上
成功删除用户carlos(①进入外网不可访问的内网网页，②触发其中的功能)

2.3.2 基于白名单的绕过

有些Web网站只允许输入白名单url，Filter可能会在开头查找匹配项，或查找包含在输入中的匹配项。可以利用url解析不一致来尝试绕过过滤。
当URL实现临时解析和验证时，URL规范包含许多可能被忽略的特性：

1. 可以用@字符在主机名之前的URL嵌入凭据，https://whitelist-host:fakepassword@evil-host，校验代码可能错误地提取@之前的内容作为主机名，而后端会解析恶意域名。
2. 可以用#表示URL片段，#后面的内容不会发送到服务器，仅用于前端定位https://evil-host#whitelist-host
3. 可以利用DNS层次结构，注册一个域名(攻击者的域名)，https://whitelist-host.evil-host，服务器可能检测到url包含whitelist-host，允许访问，但实际访问的是恶意域名。
4. URL编码混淆，如果过滤验证的代码和后端执行http请求的代码处理编码的步骤不一致，那么就可能存在绕过。如双重URL编码后，过滤器解码一次，允许通过，而服务器会递归解码到不可再解码

任何绕过方式都可以尝试组合使用

2.3.2 基于开放重定向绕过SSRF过滤

有时可利用开放重定向的漏洞绕过过滤器的防御。
Open Redirect： 允许攻击者构造恶意链接，诱导用户跳转到任意第三方网站。正常情况下，网站重定向功能应该只能跳转到受信任的域名(如本站其它链接)。存在漏洞时，可以跳转到任意域名。
假设用户提交的URL经过严格的验证，但是允许访问URL的应用程序包含开放的重定向漏洞。如果用于生成后端HTTP请求的API支持重定向，那么可以构造一个URL通过过滤器，并将重定向请求发送到所需的目标后端。
即：
1）构造一个合法白名单的URL，指向Whitelist的某个重定向接口；
2）该接口返回302跳转，将请求重定向到攻击者真正想访问的内网地址。

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin
①Web应用验证stockApi是否在白名单域，通过验证；
②Web应用请求URL，触发开放重定向，像内网发起请求
这个过程中stockApi就是存在Open Redirect漏洞的接口
案例：
（1）访问nextProduct接口，发现会发生重定向
path参数被作为Location重定向url
（2）尝试将重定向地址修改为恶意地址(内网探测)

成功将路由重定向到内网IP，但此时外网用户无法直接访问内网IP
（3）SSRF，一定是在存在SSRF的漏洞点访问内网，其它无SSRF的地方，都无法直接访问内网
回到stockApi楼顶点，传入URL
&被识别为POST参数分隔符
（4）URL编码特殊字符后，成功访问内网接口

（5）只有SSRF漏洞点才能执行内网操作，所以要在stockApi删除用户

2.4 盲SSRF

也许存在SSRF漏洞，能够向Web应用提交URL发起后端HTTP请求。但后端请求的响应并不会在前端响应返回。
Blind SSRF难以利用，其危害往往低于有响应的SSRF，并且无法从后端系统检索敏感数据。虽然有时会导致服务器或其它后端组件的代码执行。

2.4.1 检测盲SSRF

盲SSRF检测的可靠方法是OAST带外技术，触发对外部网站的HTTP请求，并监视网络交互。
值得一提的是，有时会观测到对恶意域名的DNS解析，但没有后续的HTTP请求。 这是因为目标网站试图发起HTTP请求，这会触发DNS lookup，但实际的HTTP请求被网络层过滤阻止。
对于内网来说，允许出站DNS流量是相对常见的，许多目的需要这么做，但会阻止到非预期目标的HTTP请求。

2.4.2 利用盲SSRF

即使发现了盲SSRF，也很难成功利用，因为无法查看后端的请求，并不能用于内网探测。
但是，仍可以利用其探测目标服务器本身，或其它后端服务器上的其它漏洞。
可以通过扫描器探测内网IP地址，发送已知漏洞的payload，如果payload可以OOB，那么可能会在未打补丁的内网服务器上发现严重漏洞。
另一种利用方式是诱导目标服务器主动连接到攻击者控制的恶意服务器，通过精心构造的恶意响应（如畸形HTTP数据包），利用服务器HTTP实现中的客户端漏洞（如curl、requests等库），就可以实现远程代码执行。

案例：

（1）进入网址，在Referer字段，修改为恶意域名。恶意域名也应该遵循http://evil.net协议

要点：

1. 对于盲SSRF，需要抓取每个可能的数据包进行尝试
2. 为什么是referer请求头

   Refer字段是检测盲SSRF的常见入口之一
   （1）易被后端处理，许多应用会解记录、解析或基于Referer生成动态内容（如统计来源）
   （2）隐式信任，通常Referer是自动填充的，可能会忽略校验
   （3）广泛支持，几乎所有请求都包含Referer字段

3. 只有Referer请求头吗？

   任何用户可控的HTTP headers、提交参数，都有可能成为SSRF的入口。
   如，服务器端利用Host生成绝对URL，如Location:Host/login
   XFH、XFF，反向代理服务器可能信任这些参数，覆盖实际的Host

3.SSRF的隐藏攻击面

SSRF很容易被发现，因为Web应用正常流量涉及包含完整URL的请求参数。即，所有可能的涉及URL的请求头、提交参数。如Referer、Host、X-Forwarded-Host等。

1. 请求中的URL

   有时，Web服务器只将Host或部分url路径放入请求参数中。然后将提交的参数(部分URL端点)合并到服务器请求的完整URL中。如果该值很容易被识别为主机名或URL，那么潜在的攻击面很明显。
   但是，由于无法控制整个URL，SSRF利用可能会受到限制。

2. 数据格式中的URL

   一些网站允许以包含数据解析器为该格式请求的url的规范格式传输数据，以XML为例，XML的数据解析可能会导致SSRF漏洞（XXE）。
   SSRF via XXE： 通过注入恶意外部实体，诱导服务器发起非预期的HTTP请求。
   XML规范允许通过SYSTEM关键字加载外部资源(HTTP、FTP等）

3. 通过Referer请求头

   一些Web应用会分析跟踪访问者，会记录请求中的Referer头，访问其中出现的第三方URL。因此，Referer通常是SSRF的攻击面

4.总结

1. 任何可能的url传入点，都可能导致SSRF
2. SSRF一定要在漏洞点进行进一步操作

SSRF的防御：

（1）严格过滤用户输入的URL，最好启用白名单
（2）禁用非必要协议
（3）关闭非必要端口和服务