在本节中，将描述一些常见的防止SSRF行为的措施，并介绍如何绕过这些防御机制。
带有基于黑名单输入过滤的SSRF
一些应用程序会阻止包含主机名（如127.0.0.1和localhost）或敏感URL（如/admin）的输入。
在这种情况下，我们通常可以使用下列技术绕过过滤：
●使用127.0.0.1的替代IP，比如2130706433（十进制）、017700000001（八进制）或127.1
●注册自己解析为127.0.0.1的域名，可以使用spoofed.burpcollaborator.net
●使用URL编码或大小写变体混淆被阻止的字符串
场景试验-带有基于黑名单输入过滤的SSRF：
https://portswigger.net/web-security/ssrf/lab-ssrf-with-blacklist-filter
场景说明：
这个试验场景具有库存检查功能，可从内部系统获取数据，开发人员部署了两个需要绕过的弱反SSRF防御系统。
试验目的：
要完成这个试验，需要更改库存检查URL以访问http://localhost/admin的管理界面并删除用户carlos。
攻击过程：
①打开页面后访问个商品并查询下库存，把查询库存的请求发送给Repeater
②把API修改成http://127.0.0.1/admin可以看到被过滤限制了
③尝试把127.0.0.1改成127.1，还是被过滤
④把admin进行两次URL编码后替换进去，可以看到响应成功了
⑤再次替换API的URL，删除用户Carlos，完成本试验
带有基于白名单输入过滤的SSRF
某些应用程序以白名单的方式匹配输入，在这种情况下，有时可以通过利用URL解析中的不一致来绕过过滤。
URL规范包含许多在实现URL的即时解析和验证时容易被忽略的特性：
●可以在URL的主机名前嵌入@字符作为凭据，比如：
https://expected-host@evil-host
●可以使用#字符来指示URL片段，比如：
https://evil-host#expected-host
●可以利用DNS命名层次结构将所需的输入放入自己控制的DNS名称中，例如：
https://expected-host.evil-host
●可以对字符进行URL编码以混淆URL解析代码，如果实现过滤的代码处理URL编码方式与后端执行HTTP请求的不一样，那么攻击就会有用。
●可以一起使用组合这些技术。
场景试验-带有基于白名单输入过滤的SSRF：
https://portswigger.net/web-security/ssrf/lab-ssrf-with-whitelist-filter
场景说明：
这个试验场景具有库存检查功能，可从内部系统获取数据，开发人员部署了SSRF防御系统。
试验目的：
要完成这个试验，需要更改库存检查URL以访问http://localhost/admin的管理界面并删除用户carlos。
攻击过程：
①打开页面后选择一个商品并查询库存，把这个请求发送给Repeater。
②尝试把API后面的链接修改成http://127.0.0.1/admin，发送后可以看到响应要求一定要访问指定的域名
③继续改造请求，尝试用@加上这个域名进行分割，从响应来看虽然返回服务器内部错误，但是@可以通过前端验证
④尝试再加上分页符#号，又被限制了
⑤将#号进行二次URL编码替换后，可以绕过SSRF防御机制了
⑥构造删除carlos的语句，成功删除后完成试验
通过开放重定向绕过SSRF过滤
有时可以利用开放重定向漏洞来绕过所有类型基于过滤的防御。
在前面的SSRF示例中，假设用户提交的URL经过严格验证，以防止恶意利用SSRF行为。但是，允许URL的应用程序包含一个开放重定向的漏洞。如果用于发出后端HTTP请求的API支持重定向，就可以构造一个满足过滤要求的URL并导致重定向请求到所需的后端目标。
例如，假设应用程序包含一个开放重定向漏洞，URL如下所示：
返回重定向到：
可以利用开放重定向漏洞绕过URL过滤，利用SSRF漏洞如下：
POST /product/stock HTTP/1.0Content-Type:application/x-www-form-urlencodedContent-Length:118stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin
这个SSRF漏洞利用是有效的，因为应用程序首先验证提供的API URL是否在允许的域上，然后应用程序请求提供的URL，这会触发打开重定向，遵循重定向规则，向攻击者选择的内部URL发出请求。
场景试验-通过开放重定向漏洞绕过过滤的SSRF：
https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection
场景说明：
这个试验场景具有库存检查功能，可从内部系统获取数据，库存检查器已被限制为只能访问本地应用程序，因此需要首先找到影响应用程序的开放重定向。
试验目的：
要完成这个试验，需要更改库存检查URL以访问http://192.168.0.12:8080/admin的管理界面并删除用户carlos。
攻击过程：
①打开页面后访问个商品并查询下库存，把查询库存的请求发送给Repeater。
②修改下API的URL，直接访问另一个主机的管理面板，发现被过滤限制了
③在商品页面中点击"Next product"，可以看到这个请求回来的响应是一个重定向，把这个请求也发送到Repeater
④改造这个请求，尝试看让重定向到内部服务器，发现响应包重定向成功
⑤把上面这条请求的路径替换到库存请求的API后面，成功访问到管理面板
⑥改造下API后面的URL，删除用户carlos，完成本试验
场景小结：
本次的三个场景，分别从黑名单，白名单和其他绕过的方式演示了SSRF漏洞利用的多样性，只要有给用户提交的链接调用接口，就容易存在SSRF漏洞攻击。
SQL注入攻击-检索隐藏的数据
HTTP高级请求走私-响应队列中毒
HTTP Host头漏洞攻击-概念梳理
原文始发于微信公众号（H君网安白话）：服务器端请求伪造(SSRF)-规避常见的SSRF防御
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论