前言

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