前言

尽管长久以来，测试服务器端请求伪造（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=

4A评测 - 免责申明

本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。

不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。

本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。

如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！

程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。

侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）