服务器端请求伪造(SSRF)-规避常见的SSRF防御

admin 2022年8月18日08:00:02安全百科评论12 views2704字阅读9分0秒阅读模式

在本节中,将描述一些常见的防止SSRF行为的措施,并介绍如何绕过这些防御机制。


带有基于黑名单输入过滤的SSRF

一些应用程序会阻止包含主机名(如127.0.0.1localhost)或敏感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

服务器端请求伪造(SSRF)-规避常见的SSRF防御

API修改成http://127.0.0.1/admin可以看到被过滤限制了

服务器端请求伪造(SSRF)-规避常见的SSRF防御

尝试把127.0.0.1改成127.1,还是被过滤

服务器端请求伪造(SSRF)-规避常见的SSRF防御

 

admin进行两次URL编码后替换进去,可以看到响应成功了

服务器端请求伪造(SSRF)-规避常见的SSRF防御

 

服务器端请求伪造(SSRF)-规避常见的SSRF防御

再次替换APIURL,删除用户Carlos,完成本试验

服务器端请求伪造(SSRF)-规避常见的SSRF防御


带有基于白名单输入过滤的SSRF

某些应用程序以白名单的方式匹配输入,在这种情况下,有时可以通过利用URL解析中的不一致来绕过过滤。

URL规范包含许多在实现URL的即时解析和验证时容易被忽略的特性:

●可以在URL的主机名前嵌入@字符作为凭据,比如:

https://[email protected]

●可以使用#字符来指示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,发送后可以看到响应要求一定要访问指定的域名

服务器端请求伪造(SSRF)-规避常见的SSRF防御

 

继续改造请求,尝试用@加上这个域名进行分割,从响应来看虽然返回服务器内部错误,但是@可以通过前端验证

服务器端请求伪造(SSRF)-规避常见的SSRF防御

尝试再加上分页符#号,又被限制了

服务器端请求伪造(SSRF)-规避常见的SSRF防御

#号进行二次URL编码替换后,可以绕过SSRF防御机制了 

服务器端请求伪造(SSRF)-规避常见的SSRF防御

 

服务器端请求伪造(SSRF)-规避常见的SSRF防御

构造删除carlos的语句,成功删除后完成试验

服务器端请求伪造(SSRF)-规避常见的SSRF防御



通过开放重定向绕过SSRF过滤

有时可以利用开放重定向漏洞来绕过所有类型基于过滤的防御。

在前面的SSRF示例中,假设用户提交的URL经过严格验证,以防止恶意利用SSRF行为。但是,允许URL的应用程序包含一个开放重定向的漏洞。如果用于发出后端HTTP请求的API支持重定向,就可以构造一个满足过滤要求的URL并导致重定向请求到所需的后端目标。

例如,假设应用程序包含一个开放重定向漏洞,URL如下所示:

服务器端请求伪造(SSRF)-规避常见的SSRF防御

返回重定向到:

服务器端请求伪造(SSRF)-规避常见的SSRF防御

可以利用开放重定向漏洞绕过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

修改下APIURL,直接访问另一个主机的管理面板,发现被过滤限制了 

服务器端请求伪造(SSRF)-规避常见的SSRF防御

在商品页面中点击"Next product",可以看到这个请求回来的响应是一个重定向,把这个请求也发送到Repeater

服务器端请求伪造(SSRF)-规避常见的SSRF防御

改造这个请求,尝试看让重定向到内部服务器,发现响应包重定向成功

服务器端请求伪造(SSRF)-规避常见的SSRF防御

把上面这条请求的路径替换到库存请求的API后面,成功访问到管理面板 

服务器端请求伪造(SSRF)-规避常见的SSRF防御

改造下API后面的URL,删除用户carlos,完成本试验

服务器端请求伪造(SSRF)-规避常见的SSRF防御

场景小结:

本次的三个场景,分别从黑名单,白名单和其他绕过的方式演示了SSRF漏洞利用的多样性,只要有给用户提交的链接调用接口,就容易存在SSRF漏洞攻击。


服务器端请求伪造(SSRF)-规避常见的SSRF防御


文件上传漏洞-概念梳理

访问控制和权限提升漏洞-概念梳理

信息泄露漏洞-概念梳理

业务逻辑漏洞-概念梳理

命令注入攻击(上)
目录遍历攻击(上)

身份验证漏洞-概念梳理

SQL注入攻击-检索隐藏的数据
HTTP高级请求走私-响应队列中毒
HTTP Host头漏洞攻击-概念梳理


原文始发于微信公众号(H君网安白话):服务器端请求伪造(SSRF)-规避常见的SSRF防御

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年8月18日08:00:02
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  服务器端请求伪造(SSRF)-规避常见的SSRF防御 http://cn-sec.com/archives/1241189.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: