打破传统思维 | 另一视角下的SSRF
AlbertJay
- 关注
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
收藏一下~
可以收录到专辑噢~
前言
尽管长久以来,测试服务器端请求伪造(SSRF)漏洞时,多是为了探寻内网服务与端口,以此获取敏感数据或实现远程代码执行(RCE),但近期遇到的一些情况让我不得不重新思考这一漏洞的利用方式——即便面对的SSRF缺陷看似影响有限,没有传统的内网渗透场景。对于另类SSRF产生了新的想法,因此用这篇文章给大家分享。
SSRF是什么?
SSRF,即Server-Side Request Forgery,是一种允许攻击者操纵服务器发送伪造请求的安全漏洞。攻击者通过篡改应用向URL发起的数据导入、发布或其他读取操作的请求,使之指向完全不同的地址,或者通过路径遍历等方式操控URL构建,从而达到访问内部资源的目的。
传统视角
通常,我们讨论SSRF时,关注点集中于攻击者如何利用此漏洞侵入内网,获取敏感信息。企业对此类风险有所防范,会隔离关键系统,限制端口访问,实施严格的策略来降低SSRF的风险,使其在赏金计划或客户眼中变得无关紧要。
新视角:SSRF至账户接管
新思路是利用SSRF作为跳板,间接触及客户端,目标直指用户及其数据,尤其是在子域名下的SSRF利用。关键在于让SSRF反映出客户端使用的头部信息,如同代理一般,让攻击者能够定义应用程序中的代理设置,从而实现类似子域名接管的效果,掌控所有流向该子域名的内容。尽管在一些非核心子域或开发环境中的影响可能受限,但这仍然是高度危害的,因为我们最终目的是影响用户。
实现步骤
如果SSRF位于ssrf.dev.example.com,我们需要找到*.example.com下的带有认证的应用程序,其Cookie设置如下:
Set-cookie: session=
可试读前30%内容
¥ 19.9 全文查看
9.9元开通FVIP会员
畅读付费文章
畅读付费文章
最低0.3元/天
免责声明
1.一般免责声明:本文所提供的技术信息仅供参考,不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》,作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。
2. 适用性声明:文中技术内容可能不适用于所有情况或系统,在实际应用前请充分测试和评估。若因使用不当造成的任何问题,相关方不承担责任。
3. 更新声明:技术发展迅速,文章内容可能存在滞后性。读者需自行判断信息的时效性,因依据过时内容产生的后果,作者及发布平台不承担责任。
本文为 AlbertJay 独立观点,未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
解析Next.js中的SSRF漏洞:深入探讨盲目的SSRF攻击及其防范策略
2025-02-08
企业防线的薄弱环节:深入了解供应链网络攻击的风险
2024-12-31
修复秘籍:如何有效应对CVE-2024-20767和CVE-2024-21216漏洞
2024-12-19
文章目录