1. 项目概述深入理解SSRF与IP限制绕过的攻防本质在渗透测试和网络安全研究领域SSRF服务器端请求伪造一直是一个极具威胁且充满挑战的漏洞类型。它之所以危险是因为它利用了服务器“受信任”的身份能够发起攻击者无法直接发起的请求从而成为穿透网络边界、触及内网资产的“特洛伊木马”。而“IP地址限制绕过”则是SSRF攻击链中的核心技巧是检验一个SSRF漏洞是否真正可利用、以及利用深度如何的关键。简单来说当目标服务器对请求的目标地址如内网IP段192.168.0.0/16、10.0.0.0/8或127.0.0.1进行了看似严密的过滤时攻击者如何通过巧妙的“变形”和“欺骗”让这些请求成功抵达被禁止访问的地址这就是IP限制绕过的艺术。这个主题适合所有对Web安全、应用安全感兴趣的安全从业者、开发者和CTF选手。对于开发者理解这些绕过手法能帮助你写出更健壮、无懈可击的过滤代码对于安全研究员和渗透测试工程师掌握这些技巧则是挖掘深层次漏洞、评估真实风险的必备技能。本文将从一个实战者的视角系统性地拆解SSRF中绕过IP地址限制的各种“奇技淫巧”不仅告诉你“怎么做”更深入剖析“为什么能这么做”以及在实际攻防场景中如何应用和防御。2. 核心绕过思路与原理深度解析要绕过IP限制我们首先必须理解服务器端是如何进行过滤的。常见的过滤逻辑通常基于字符串匹配或正则表达式对用户传入的URL参数进行解析然后检查解析出的主机名或IP地址是否在黑名单如内网IP中或者是否在白名单如仅允许特定域名中。这种过滤往往发生在应用层而请求的实际发起可能由不同的库如Python的requests、PHP的curl、Java的HttpURLConnection或系统调用完成。正是这种“解析层”与“实际请求层”之间的差异以及互联网协议和标准中一些“特性”或“模糊地带”为我们提供了绕过的空间。2.1 绕过逻辑的基石解析差异与协议特性所有的绕过手法本质上都是在利用“过滤器的解析结果”与“底层网络库或操作系统解析结果”的不一致性。过滤器可能用一种方式理解你给的URL而真正发起请求的组件用另一种方式理解它如果两者结果不同且后者解析出的地址是攻击者想要的那么绕过就成功了。另一种思路是利用协议本身的特性比如某些协议如file://、gopher://、dict://在设计上就可能用于访问本地资源或执行特定操作它们可能不受基于HTTP/HTTPS的IP过滤逻辑约束。此外像DNS重绑定这类攻击则是利用了“域名解析结果会随时间变化”这一特性在过滤时是一个合法外网IP在真正请求时却变成了一个内网IP。理解了这个核心我们就可以将绕过手法分为几个清晰的类别IP地址的语法变形、利用URL解析的歧义、借助中间跳转、使用非标准协议以及操纵DNS解析过程。下面我们将逐一深入并配以大量实战案例。3. IP地址语法变形绕过详解这是最直接、也最常见的一类绕过方法。当过滤器简单地使用字符串匹配如indexOf(‘127.0.0.1’)或简单的正则表达式如/^192\.168\.\d\.\d$/来检测IP地址时我们可以利用IP地址的多种合法或“非标准”表示形式来欺骗它。3.1 点分十进制表示的变形一个IP地址127.0.0.1在计算机看来它本质上是一个32位的整数。点分十进制只是人类可读的一种表现形式。我们可以利用其他进制的表示或者省略部分格式。1. 不同进制表示十进制整数形式127.0.0.1转换为十进制是2130706433。你可以尝试直接访问http://2130706433。许多网络库支持这种格式。八进制形式将每个部分转换为八进制。127-0177,0-0,0-0,1-01。可以写成http://0177.0.0.01注意前导0表示八进制。有时过滤器可能只检查数字而忽略了前导0的八进制含义。十六进制形式将每个部分或整个IP转换为十六进制。127.0.0.1的十六进制是0x7f000001。可以尝试http://0x7f000001或http://0x7f.0x0.0x0.0x1。2. 省略部分或全部点号有些解析器允许省略点号将IP视为一个长整数。例如http://127.1可能被解析为127.0.0.1因为127.1等价于127.0.0.1中间缺失的部分补0。同理http://127.0.1也指向127.0.0.1。更极端的http://2130706433十进制本身就没有点号。3. 添加多余的点号或特定端口http://127.0.0.1.末尾加点在某些解析场景下可能被接受。http://127.0.0.1:80evil.com或http://127.0.0.1#evil.com。这里的关键是利用URL中的和#。在URL中用于分隔认证信息#是片段标识符。有些粗糙的过滤器可能只提取或#之前的主机部分而实际请求的库如curl可能会以不同的优先级解析。例如curl对于http://127.0.0.1:80evil.com可能会连接到evil.com但某些自定义的过滤器可能错误地认为主机是127.0.0.1。这一点需要结合具体环境测试并非总是有效。注意并非所有应用程序或网络库都支持这些非标准格式。例如Python的socket.inet_aton()函数能解析很多怪异格式如127.1但更现代的ipaddress库或一些严格的校验函数可能就不行。实战中需要模糊测试。3.2 利用IPv6与IPv4的混合及封装IPv6提供了更广阔的变形空间并且常被内网过滤规则忽略因为传统内网多用IPv4。1. IPv6本地地址直接使用IPv6的环回地址::1对应IPv4的127.0.0.1。尝试http://[::1]或http://[::1]:80。很多只过滤了IPv4地址的防御会漏掉这个。IPv6的内网链路本地地址fe80::/10或唯一本地地址fc00::/7也可能被用于访问内网服务。2. IPv4映射的IPv6地址这是将IPv4地址嵌入IPv6地址的一种标准格式。例如127.0.0.1可以表示为::ffff:127.0.0.1或::ffff:7f00:1十六进制。URL中写作http://[::ffff:127.0.0.1]。甚至可以用缩写的IPv6格式如http://[::ffff:7f00:1]。过滤器可能只匹配点分十进制对这种格式束手无策。3. 利用DNS解析的“巧合”注册一个域名将其A记录指向127.0.0.1。例如假设你控制evil.com将其解析到127.0.0.1。然后提交http://evil.com。如果过滤器只检查IP是否属于内网段而对域名进行DNS解析后的IP结果检查不严或者只在过滤时解析一次且你控制了解析结果就可能绕过。这引向了更高级的DNS重绑定攻击。为了更直观地对比这些方法我们可以看下面的表格绕过手法示例URL利用原理可能失效的场景十进制整数http://2130706433IP本质是32位整数支持直接访问目标服务器网络库不支持八进制格式http://0177.0.0.01利用前导0表示八进制过滤器对IP进行规范化后再比较省略点号http://127.1解析器自动补全缺失的八位组为0使用严格的IP地址验证库IPv6环回http://[::1]过滤规则只针对IPv4服务器不支持IPv6网络栈IPv4映射IPv6http://[::ffff:127.0.0.1]IPv6格式伪装IPv4地址应用层在发起请求前将地址规范化域名指向http://localhost.evil.com(A记录为127.0.0.1)过滤器检查域名而非最终IP服务器在过滤时主动解析域名并检查IP4. 利用URL解析歧义与缺陷绕过URL标准RFC 3986看似明确但在实现中不同的解析库如浏览器、curl、libcurl、各语言内置的HTTP客户端可能存在细微差别。攻击者可以利用这些差别“欺骗”过滤器。4.1 URL编码与双重编码这是利用了解析阶段的不同。过滤器可能在解码URL一次后进行检查而实际请求的库可能解码两次或者对URL的不同部分进行解码。对IP地址部分编码将点号.编码为%2e将数字编码为十六进制。例如127.0.0.1可以写成%31%32%37%2e%30%2e%30%2e%31每个字符的URL编码。如果过滤器在比较前没有解码或者只解码了一次它可能看不到127.0.0.1这个字符串。但后端请求库在发起请求前可能会完全解码最终连接到本地环回地址。对整个URL或主机名部分进行双重编码例如点号.的URL编码是%2e。%2e中的%字符本身可以再编码为%25。所以.可以变成%252e。如果过滤器解码一次看到的是%2e认为不是点号而请求库解码两次最终还原为.。这种手法常用于绕过一些WAFWeb应用防火墙的简单规则。4.2 利用和#的歧义如前文简要提及URL的通用格式是scheme://[user:password]host[:port][/path][?query][#fragment]。符号用于分隔认证信息用户名密码和主机。http://foobar.com表示以用户foo无密码访问bar.com。关键在于之前的内容是认证部分之后是主机部分。如果过滤器错误地从之前提取“主机”例如一些蹩脚的正则如^(http://)?([^/])它可能会把foo当作主机而实际请求的库如curl会正确地将bar.com作为主机。因此构造http://127.0.0.1evil.com蹩脚的过滤器看到的是127.0.0.1黑名单而curl默认会去连接evil.com。重要补充现代浏览器和curl的默认行为是如果前没有有效的认证信息格式如user:pass它们可能会将整个127.0.0.1evil.com尝试解析为主机名这通常会解析失败。因此为了让生效通常需要提供一个密码即使是空的。例如http://127.0.0.1:80evil.com或http://a:evil.com这里a:是认证信息。这需要根据目标使用的具体HTTP库来测试。#符号片段标识符不会发送到服务器。http://evil.com#127.0.0.1。一些简单的过滤器可能会截取#之前的内容作为URL即evil.com看起来是合法的。但某些库在解析时可能会因为URL编码或解析顺序问题产生不同的结果。不过单纯用#绕过在现代库中比较困难。4.3 利用不完整的URL或畸形Host头省略协议如果参数直接拼接到一个基础URL后面可能会形成奇怪的解析。例如后端代码可能是$url http:// . user_input;。如果用户输入evil.com最终成为http://evil.com。某些解析器可能会将前空白的认证信息忽略最终访问evil.com。利用Host头覆盖在HTTP请求中Host头部字段指示服务器的域名。有些服务器端脚本特别是PHP在获取请求目标时可能会优先使用$_SERVER[‘HTTP_HOST’]即HTTP请求头中的Host而非URL中解析出的主机。如果过滤器只检查了URL参数但实际请求的代码使用了Host头那么攻击者可以在提交恶意URL参数如http://allowed-external-site.com的同时在HTTP请求中修改Host头为127.0.0.1。这需要能控制发送的原始HTTP请求常见于结合CSRF或使用Burp Suite等工具手动构造请求的场景。5. 通过跳转与协议切换进行绕过当直接变形和解析歧义都无法绕过时我们可以考虑“曲线救国”让请求先到达一个“合法”的地点再由那个地点转发到我们真正想去的“非法”目的地。5.1 302/307跳转绕过这是非常经典且有效的方法。其原理是服务器端的过滤器只检查了用户直接提供的URLA这个URL是合法的例如一个攻击者控制的外网服务器evil.com。服务器程序去请求AA返回一个HTTP 302或307状态码并携带一个Location响应头指向真正想要访问的内网地址B如http://192.168.1.1。此时服务器程序或其使用的HTTP库会自动跟随这个跳转去请求B从而成功访问到内网资源。整个过程中过滤器只看到了A而实际请求发向了B。成功的关键在于服务器端的HTTP客户端配置为自动跟随重定向这是很多库的默认行为如curl、requests。过滤器在第一次请求A之后没有对跳转后的目标B进行第二次检查。很多初级的防御方案都会忽略这一点。实操步骤准备一个攻击者可控的Web服务器如VPS或利用GitHub Pages、云函数等。在该服务器上编写一个简单的脚本PHP/Python/Node.js均可当接收到请求时立即返回302跳转到目标内网地址。PHP示例?php header(Location: http://192.168.1.1/admin); ?Python Flask示例from flask import Flask, redirect app Flask(__name__) app.route(/) def redirect_to_internal(): return redirect(http://192.168.1.1/admin, code302)将可控服务器的URL如http://your-evil-server.com/redirect.php提交给存在SSRF漏洞的参数。观察服务器响应如果成功你可能会看到来自内网192.168.1.1的响应内容。心得302跳转绕过的成功率很高尤其是在CTF比赛中。在真实环境中一些安全意识较强的系统可能会禁用HTTP客户端的重定向跟随或者对重定向目标进行二次校验。此时可以尝试307跳转临时重定向要求方法和消息体不变有时能绕过一些简单的重定向禁用策略。5.2 利用非HTTP/HTTPS协议SSRF漏洞的“请求”并不局限于HTTP。很多网络库支持多种URL协议Scheme。如果过滤器只检查了http://和https://或者只对这两种协议进行主机名/IP检查那么使用其他协议就可能直接绕过。file://协议用于访问本地文件系统。file:///etc/passwd可以读取服务器本地的文件。这是SSRF用于读取敏感文件的经典方式。它完全绕过了网络层的IP限制因为请求根本没有发往网络。gopher://协议一个非常古老但强大的协议它可以构造任意格式的TCP数据包。通过gopher可以攻击内网中的Redis、Memcached、MySQL、FastCGI等服务甚至能发起POST请求。例如gopher://127.0.0.1:6379/_后面跟上特殊格式的Redis命令可以攻击未授权访问的Redis服务。由于gopher协议在现代浏览器中已基本不支持但许多服务器的后端网络库如libcurl仍支持它因此它成了SSRF攻击的“大杀器”。dict://协议用于查询字典服务器但它可以用于探测端口。dict://127.0.0.1:6379/info可以向Redis服务的6379端口发送一个INFO命令如果端口开放且服务响应我们就能看到返回信息从而确认服务存在。ftp://、ldap://、tftp://等这些协议也可能被利用取决于服务器环境和支持的库。协议利用的关键点探测支持协议首先需要探测目标服务器后端支持哪些URL协议。可以通过报错信息、延时差异盲SSRF或尝试访问已知协议来测试。注意协议格式不同协议URL的格式差异很大。例如gopher协议需要将TCP数据流进行特殊编码后放在URL路径中。防御视角最安全的做法是白名单机制只允许http和https协议并严格校验主机。但要注意即使只允许HTTP302跳转和DNS重绑定依然可能构成威胁。6. DNS重绑定攻击时间差的艺术DNS重绑定DNS Rebinding是一种更高级、更难防御的绕过技术。它利用了“域名解析结果可以变化”这一DNS的基本特性。6.1 攻击原理攻击流程如下攻击者注册一个域名如evil.com并完全控制其DNS服务器。为该域名设置一个非常短的TTL生存时间例如0秒或1秒。攻击者向存在SSRF漏洞的服务器提交URLhttp://evil.com/。服务器端的过滤器或第一次解析对evil.com进行DNS查询。此时攻击者控制的DNS服务器返回一个合法的、外网的IP地址例如1.2.3.4一个攻击者拥有的无害服务器。过滤器检查这个IP发现不在黑名单内于是允许请求。服务器程序开始向evil.com发起HTTP请求。由于TTL极短服务器的DNS解析器会重新查询evil.com的IP。此时攻击者瞬间将evil.com的DNS记录修改为目标内网IP地址例如192.168.1.1。服务器的DNS解析器拿到了新的IP192.168.1.1并基于这个IP建立了TCP连接发送了HTTP请求。由于这个连接是在DNS解析之后才建立的因此请求成功发往了内网地址。攻击者收到来自内网服务的响应可能需要通过外网服务器1.2.3.4进行中转或者在某些场景下直接能看到响应。6.2 成功条件与难点DNS重绑定攻击的成功需要多个条件同时满足服务器DNS解析器行为必须遵守TTL并且在每次建立新连接或连接池中的连接过期后时重新解析域名。有些客户端或操作系统会有DNS缓存可能不理会极短的TTL。过滤时机IP过滤必须在第一次DNS解析时进行并且不对后续实际的Socket连接所使用的IP进行再次校验。如果过滤逻辑集成在HTTP客户端库中并且在发起TCP连接前再次获取IP则可能失败。攻击者控制DNS需要有一个可以快速修改DNS记录的域名服务器。尽管条件苛刻但在云原生、微服务架构下由于服务实例生命周期短、DNS查询频繁DNS重绑定攻击的可行性在增加。一些公开的在线工具如rbndr.us提供了用于测试的DNS重绑定服务简化了攻击过程。6.3 防御思路从防御者角度看应对DNS重绑定需要在获取IP地址后立即使用并禁止在同一个会话中因DNS更新而切换IP。有些编程语言或库提供了禁用DNS缓存的选项但这可能影响性能。对解析出的IP进行持续校验不仅在请求发起前检查在建立TCP连接时确保连接的IP与之前解析的IP一致。但这需要更底层的网络控制。使用白名单域名而非IP直接信任特定的域名只允许访问这些域名从根本上避免依赖动态的IP解析。这是最有效但灵活性最差的方法。使用应用层代理或网络层防火墙所有出站请求必须经过一个代理该代理具有固定的DNS解析策略和严格的出口过滤规则。7. 实战场景与综合技巧理论需要结合实践。下面我们模拟几个经典场景看看如何综合运用上述技巧。7.1 场景一CTF题目中的经典绕过假设一个CTF题目提供了一个Web接口输入URL会返回该URL的内容但过滤了127.0.0.1、localhost、192.168.*、10.*等字符串并且检查URL是否以http://或https://开头。尝试步骤基础测试输入http://example.com正常返回。说明功能可用。IPv6测试输入http://[::1]/。如果返回了本地服务的信息如“Internal Server Error”或本机Web服务的默认页则绕过成功。进制转换输入http://2130706433/127.0.0.1的十进制。或者尝试http://0177.0.0.01/八进制。域名重定向如果上述都不行考虑302跳转。在自己的VPS上部署一个跳转脚本指向http://127.0.0.1/flag.php然后提交VPS的URL。非HTTP协议尝试file:///etc/passwd。如果题目允许任意协议且后端支持file可能直接读到文件。结合符号如果题目允许http和https但黑名单过滤很严可以尝试http://foobar.com127.0.0.1。这里需要理解解析顺序可能因库而异。更可靠的是利用URL编码http://%6c%6f%63%61%6c%68%6f%73%74即localhost的每个字符的URL编码。7.2 场景二真实环境中的内网探测与攻击假设在一个渗透测试中你发现了一个SSRF漏洞但目标服务器对请求地址做了严格过滤只允许访问*.target-company.com的子域名。攻击思路子域名接管检查是否有target-company.com的闲置子域名如dev.target-company.com、staging.target-company.com可以被你接管例如通过未删除的CNAME记录指向你的云服务。如果成功接管你就可以在该子域名上部署302跳转脚本将请求导向内网。利用已知服务如果目标内网有服务如Confluence、Jenkins存在XSS漏洞你可以构造一个URL通过SSRF让服务器去访问这些内网服务上的XSS页面。该XSS页面可以执行JavaScript将敏感数据回传这需要内网服务允许执行JS且能出网。这是一种“SSRFXSS”的组合拳。DNS重绑定尝试如果条件允许可以尝试DNS重绑定。将evil.target-company.com假设你通过某种方式注册或欺骗了一个近似域名的DNS记录先指向一个合法IP待SSRF过滤器通过后迅速重绑定到内网网关IP192.168.1.1尝试访问其管理界面。协议降级与端口探测即使主机名被白名单限制但协议可能没限制。尝试dict://assets.target-company.com:6379/info来探测该子域名主机上是否开放了Redis端口。因为dict协议可能不受HTTP主机白名单逻辑的约束。7.3 工具与自动化测试手动尝试所有变形效率很低。可以使用一些自动化工具来辅助Burp Suite的 Collaborator用于检测盲SSRF。将Collaborator生成的域名插入到可能的SSRF参数中如果目标服务器发起了请求Collaborator会收到通知从而确认漏洞存在。ffuf、gobuster等模糊测试工具可以用于快速枚举和测试各种IP变形、URL编码等payload。自定义脚本编写Python脚本使用requests或aiohttp库批量发送各种变形后的URL根据响应时间、长度、内容来判断是否成功。例如如果访问一个不存在的内网IP通常会快速超时或连接拒绝而访问到真实服务则会有不同的响应。8. 防御措施与安全开发建议了解了攻击手法作为开发者我们应该如何构建更坚固的防御统一解析与校验使用权威的URL解析库如Python的urllib.parseJava的java.net.URI来解析用户输入的URL并从中提取hostname。不要使用正则表达式手动解析URL极易出错。对提取出的hostname进行DNS解析获取其所有对应的IP地址可能是IPv4和IPv6。严格的IP地址过滤将解析得到的所有IP地址与内网IP段黑名单进行比较。黑名单应覆盖IPv4环回127.0.0.0/8IPv4私有地址10.0.0.0/8,172.16.0.0/12,192.168.0.0/16IPv4链路本地169.254.0.0/16IPv4多播224.0.0.0/4IPv6环回::1/128IPv6私有地址fc00::/7,fe80::/100.0.0.0和localhost域名重要必须将IP地址规范化后再比较。例如将0177.0.0.01先转换为标准的127.0.0.1。使用标准的IP地址处理库如Python的ipaddress来完成这个工作。协议白名单只允许业务必需的协议通常是http://和https://。明确拒绝file://、gopher://、dict://、ftp://等危险协议。禁用重定向跟随或对重定向目标进行二次校验配置HTTP客户端禁止自动跟随重定向如curl的CURLOPT_FOLLOWLOCATION设为0Pythonrequests的allow_redirectsFalse。如果业务必须允许重定向那么必须在每次重定向发生时对新的目标URL重复执行上述的解析、DNS查询和IP过滤流程。应用层出口过滤在服务器网络层面配置严格的出站防火墙规则限制服务器只能访问必要的公网IP和端口。即使SSRF漏洞存在请求也无法到达内网敏感系统。这是最后一道也是最有效的防线之一。使用网络隔离与认证将存在SSRF风险的服务部署在独立的安全区域DMZ与核心内网严格隔离。内网服务不应仅依赖IP白名单而应具备强身份认证如API密钥、双向TLS即使请求来自“内部IP”没有合法凭证也无法访问。安全意识与代码审计在代码审查中对所有从用户输入获取URL并发起网络请求的地方保持高度警惕。使用安全的默认配置。例如许多HTTP客户端库默认跟随重定向应在初始化时显式关闭。SSRF的攻防是一场关于“解析”和“信任”的博弈。攻击者不断寻找解析链条中的薄弱环节而防御者需要确保从用户输入到网络套接字建立的每一步都经过一致且严格的安全检查。没有一劳永逸的银弹唯有深入理解其原理结合白名单、规范化解析、网络层隔离等多重手段才能有效缓解SSRF带来的风险。在实际漏洞挖掘中面对一个SSRF点多角度尝试、耐心测试往往就能发现那些被开发者忽略的“模糊地带”从而打开内网渗透的大门。
SSRF漏洞中IP限制绕过技术：从原理到实战的攻防解析
发布时间：2026/7/5 9:22:55
1. 项目概述深入理解SSRF与IP限制绕过的攻防本质在渗透测试和网络安全研究领域SSRF服务器端请求伪造一直是一个极具威胁且充满挑战的漏洞类型。它之所以危险是因为它利用了服务器“受信任”的身份能够发起攻击者无法直接发起的请求从而成为穿透网络边界、触及内网资产的“特洛伊木马”。而“IP地址限制绕过”则是SSRF攻击链中的核心技巧是检验一个SSRF漏洞是否真正可利用、以及利用深度如何的关键。简单来说当目标服务器对请求的目标地址如内网IP段192.168.0.0/16、10.0.0.0/8或127.0.0.1进行了看似严密的过滤时攻击者如何通过巧妙的“变形”和“欺骗”让这些请求成功抵达被禁止访问的地址这就是IP限制绕过的艺术。这个主题适合所有对Web安全、应用安全感兴趣的安全从业者、开发者和CTF选手。对于开发者理解这些绕过手法能帮助你写出更健壮、无懈可击的过滤代码对于安全研究员和渗透测试工程师掌握这些技巧则是挖掘深层次漏洞、评估真实风险的必备技能。本文将从一个实战者的视角系统性地拆解SSRF中绕过IP地址限制的各种“奇技淫巧”不仅告诉你“怎么做”更深入剖析“为什么能这么做”以及在实际攻防场景中如何应用和防御。2. 核心绕过思路与原理深度解析要绕过IP限制我们首先必须理解服务器端是如何进行过滤的。常见的过滤逻辑通常基于字符串匹配或正则表达式对用户传入的URL参数进行解析然后检查解析出的主机名或IP地址是否在黑名单如内网IP中或者是否在白名单如仅允许特定域名中。这种过滤往往发生在应用层而请求的实际发起可能由不同的库如Python的requests、PHP的curl、Java的HttpURLConnection或系统调用完成。正是这种“解析层”与“实际请求层”之间的差异以及互联网协议和标准中一些“特性”或“模糊地带”为我们提供了绕过的空间。2.1 绕过逻辑的基石解析差异与协议特性所有的绕过手法本质上都是在利用“过滤器的解析结果”与“底层网络库或操作系统解析结果”的不一致性。过滤器可能用一种方式理解你给的URL而真正发起请求的组件用另一种方式理解它如果两者结果不同且后者解析出的地址是攻击者想要的那么绕过就成功了。另一种思路是利用协议本身的特性比如某些协议如file://、gopher://、dict://在设计上就可能用于访问本地资源或执行特定操作它们可能不受基于HTTP/HTTPS的IP过滤逻辑约束。此外像DNS重绑定这类攻击则是利用了“域名解析结果会随时间变化”这一特性在过滤时是一个合法外网IP在真正请求时却变成了一个内网IP。理解了这个核心我们就可以将绕过手法分为几个清晰的类别IP地址的语法变形、利用URL解析的歧义、借助中间跳转、使用非标准协议以及操纵DNS解析过程。下面我们将逐一深入并配以大量实战案例。3. IP地址语法变形绕过详解这是最直接、也最常见的一类绕过方法。当过滤器简单地使用字符串匹配如indexOf(‘127.0.0.1’)或简单的正则表达式如/^192\.168\.\d\.\d$/来检测IP地址时我们可以利用IP地址的多种合法或“非标准”表示形式来欺骗它。3.1 点分十进制表示的变形一个IP地址127.0.0.1在计算机看来它本质上是一个32位的整数。点分十进制只是人类可读的一种表现形式。我们可以利用其他进制的表示或者省略部分格式。1. 不同进制表示十进制整数形式127.0.0.1转换为十进制是2130706433。你可以尝试直接访问http://2130706433。许多网络库支持这种格式。八进制形式将每个部分转换为八进制。127-0177,0-0,0-0,1-01。可以写成http://0177.0.0.01注意前导0表示八进制。有时过滤器可能只检查数字而忽略了前导0的八进制含义。十六进制形式将每个部分或整个IP转换为十六进制。127.0.0.1的十六进制是0x7f000001。可以尝试http://0x7f000001或http://0x7f.0x0.0x0.0x1。2. 省略部分或全部点号有些解析器允许省略点号将IP视为一个长整数。例如http://127.1可能被解析为127.0.0.1因为127.1等价于127.0.0.1中间缺失的部分补0。同理http://127.0.1也指向127.0.0.1。更极端的http://2130706433十进制本身就没有点号。3. 添加多余的点号或特定端口http://127.0.0.1.末尾加点在某些解析场景下可能被接受。http://127.0.0.1:80evil.com或http://127.0.0.1#evil.com。这里的关键是利用URL中的和#。在URL中用于分隔认证信息#是片段标识符。有些粗糙的过滤器可能只提取或#之前的主机部分而实际请求的库如curl可能会以不同的优先级解析。例如curl对于http://127.0.0.1:80evil.com可能会连接到evil.com但某些自定义的过滤器可能错误地认为主机是127.0.0.1。这一点需要结合具体环境测试并非总是有效。注意并非所有应用程序或网络库都支持这些非标准格式。例如Python的socket.inet_aton()函数能解析很多怪异格式如127.1但更现代的ipaddress库或一些严格的校验函数可能就不行。实战中需要模糊测试。3.2 利用IPv6与IPv4的混合及封装IPv6提供了更广阔的变形空间并且常被内网过滤规则忽略因为传统内网多用IPv4。1. IPv6本地地址直接使用IPv6的环回地址::1对应IPv4的127.0.0.1。尝试http://[::1]或http://[::1]:80。很多只过滤了IPv4地址的防御会漏掉这个。IPv6的内网链路本地地址fe80::/10或唯一本地地址fc00::/7也可能被用于访问内网服务。2. IPv4映射的IPv6地址这是将IPv4地址嵌入IPv6地址的一种标准格式。例如127.0.0.1可以表示为::ffff:127.0.0.1或::ffff:7f00:1十六进制。URL中写作http://[::ffff:127.0.0.1]。甚至可以用缩写的IPv6格式如http://[::ffff:7f00:1]。过滤器可能只匹配点分十进制对这种格式束手无策。3. 利用DNS解析的“巧合”注册一个域名将其A记录指向127.0.0.1。例如假设你控制evil.com将其解析到127.0.0.1。然后提交http://evil.com。如果过滤器只检查IP是否属于内网段而对域名进行DNS解析后的IP结果检查不严或者只在过滤时解析一次且你控制了解析结果就可能绕过。这引向了更高级的DNS重绑定攻击。为了更直观地对比这些方法我们可以看下面的表格绕过手法示例URL利用原理可能失效的场景十进制整数http://2130706433IP本质是32位整数支持直接访问目标服务器网络库不支持八进制格式http://0177.0.0.01利用前导0表示八进制过滤器对IP进行规范化后再比较省略点号http://127.1解析器自动补全缺失的八位组为0使用严格的IP地址验证库IPv6环回http://[::1]过滤规则只针对IPv4服务器不支持IPv6网络栈IPv4映射IPv6http://[::ffff:127.0.0.1]IPv6格式伪装IPv4地址应用层在发起请求前将地址规范化域名指向http://localhost.evil.com(A记录为127.0.0.1)过滤器检查域名而非最终IP服务器在过滤时主动解析域名并检查IP4. 利用URL解析歧义与缺陷绕过URL标准RFC 3986看似明确但在实现中不同的解析库如浏览器、curl、libcurl、各语言内置的HTTP客户端可能存在细微差别。攻击者可以利用这些差别“欺骗”过滤器。4.1 URL编码与双重编码这是利用了解析阶段的不同。过滤器可能在解码URL一次后进行检查而实际请求的库可能解码两次或者对URL的不同部分进行解码。对IP地址部分编码将点号.编码为%2e将数字编码为十六进制。例如127.0.0.1可以写成%31%32%37%2e%30%2e%30%2e%31每个字符的URL编码。如果过滤器在比较前没有解码或者只解码了一次它可能看不到127.0.0.1这个字符串。但后端请求库在发起请求前可能会完全解码最终连接到本地环回地址。对整个URL或主机名部分进行双重编码例如点号.的URL编码是%2e。%2e中的%字符本身可以再编码为%25。所以.可以变成%252e。如果过滤器解码一次看到的是%2e认为不是点号而请求库解码两次最终还原为.。这种手法常用于绕过一些WAFWeb应用防火墙的简单规则。4.2 利用和#的歧义如前文简要提及URL的通用格式是scheme://[user:password]host[:port][/path][?query][#fragment]。符号用于分隔认证信息用户名密码和主机。http://foobar.com表示以用户foo无密码访问bar.com。关键在于之前的内容是认证部分之后是主机部分。如果过滤器错误地从之前提取“主机”例如一些蹩脚的正则如^(http://)?([^/])它可能会把foo当作主机而实际请求的库如curl会正确地将bar.com作为主机。因此构造http://127.0.0.1evil.com蹩脚的过滤器看到的是127.0.0.1黑名单而curl默认会去连接evil.com。重要补充现代浏览器和curl的默认行为是如果前没有有效的认证信息格式如user:pass它们可能会将整个127.0.0.1evil.com尝试解析为主机名这通常会解析失败。因此为了让生效通常需要提供一个密码即使是空的。例如http://127.0.0.1:80evil.com或http://a:evil.com这里a:是认证信息。这需要根据目标使用的具体HTTP库来测试。#符号片段标识符不会发送到服务器。http://evil.com#127.0.0.1。一些简单的过滤器可能会截取#之前的内容作为URL即evil.com看起来是合法的。但某些库在解析时可能会因为URL编码或解析顺序问题产生不同的结果。不过单纯用#绕过在现代库中比较困难。4.3 利用不完整的URL或畸形Host头省略协议如果参数直接拼接到一个基础URL后面可能会形成奇怪的解析。例如后端代码可能是$url http:// . user_input;。如果用户输入evil.com最终成为http://evil.com。某些解析器可能会将前空白的认证信息忽略最终访问evil.com。利用Host头覆盖在HTTP请求中Host头部字段指示服务器的域名。有些服务器端脚本特别是PHP在获取请求目标时可能会优先使用$_SERVER[‘HTTP_HOST’]即HTTP请求头中的Host而非URL中解析出的主机。如果过滤器只检查了URL参数但实际请求的代码使用了Host头那么攻击者可以在提交恶意URL参数如http://allowed-external-site.com的同时在HTTP请求中修改Host头为127.0.0.1。这需要能控制发送的原始HTTP请求常见于结合CSRF或使用Burp Suite等工具手动构造请求的场景。5. 通过跳转与协议切换进行绕过当直接变形和解析歧义都无法绕过时我们可以考虑“曲线救国”让请求先到达一个“合法”的地点再由那个地点转发到我们真正想去的“非法”目的地。5.1 302/307跳转绕过这是非常经典且有效的方法。其原理是服务器端的过滤器只检查了用户直接提供的URLA这个URL是合法的例如一个攻击者控制的外网服务器evil.com。服务器程序去请求AA返回一个HTTP 302或307状态码并携带一个Location响应头指向真正想要访问的内网地址B如http://192.168.1.1。此时服务器程序或其使用的HTTP库会自动跟随这个跳转去请求B从而成功访问到内网资源。整个过程中过滤器只看到了A而实际请求发向了B。成功的关键在于服务器端的HTTP客户端配置为自动跟随重定向这是很多库的默认行为如curl、requests。过滤器在第一次请求A之后没有对跳转后的目标B进行第二次检查。很多初级的防御方案都会忽略这一点。实操步骤准备一个攻击者可控的Web服务器如VPS或利用GitHub Pages、云函数等。在该服务器上编写一个简单的脚本PHP/Python/Node.js均可当接收到请求时立即返回302跳转到目标内网地址。PHP示例?php header(Location: http://192.168.1.1/admin); ?Python Flask示例from flask import Flask, redirect app Flask(__name__) app.route(/) def redirect_to_internal(): return redirect(http://192.168.1.1/admin, code302)将可控服务器的URL如http://your-evil-server.com/redirect.php提交给存在SSRF漏洞的参数。观察服务器响应如果成功你可能会看到来自内网192.168.1.1的响应内容。心得302跳转绕过的成功率很高尤其是在CTF比赛中。在真实环境中一些安全意识较强的系统可能会禁用HTTP客户端的重定向跟随或者对重定向目标进行二次校验。此时可以尝试307跳转临时重定向要求方法和消息体不变有时能绕过一些简单的重定向禁用策略。5.2 利用非HTTP/HTTPS协议SSRF漏洞的“请求”并不局限于HTTP。很多网络库支持多种URL协议Scheme。如果过滤器只检查了http://和https://或者只对这两种协议进行主机名/IP检查那么使用其他协议就可能直接绕过。file://协议用于访问本地文件系统。file:///etc/passwd可以读取服务器本地的文件。这是SSRF用于读取敏感文件的经典方式。它完全绕过了网络层的IP限制因为请求根本没有发往网络。gopher://协议一个非常古老但强大的协议它可以构造任意格式的TCP数据包。通过gopher可以攻击内网中的Redis、Memcached、MySQL、FastCGI等服务甚至能发起POST请求。例如gopher://127.0.0.1:6379/_后面跟上特殊格式的Redis命令可以攻击未授权访问的Redis服务。由于gopher协议在现代浏览器中已基本不支持但许多服务器的后端网络库如libcurl仍支持它因此它成了SSRF攻击的“大杀器”。dict://协议用于查询字典服务器但它可以用于探测端口。dict://127.0.0.1:6379/info可以向Redis服务的6379端口发送一个INFO命令如果端口开放且服务响应我们就能看到返回信息从而确认服务存在。ftp://、ldap://、tftp://等这些协议也可能被利用取决于服务器环境和支持的库。协议利用的关键点探测支持协议首先需要探测目标服务器后端支持哪些URL协议。可以通过报错信息、延时差异盲SSRF或尝试访问已知协议来测试。注意协议格式不同协议URL的格式差异很大。例如gopher协议需要将TCP数据流进行特殊编码后放在URL路径中。防御视角最安全的做法是白名单机制只允许http和https协议并严格校验主机。但要注意即使只允许HTTP302跳转和DNS重绑定依然可能构成威胁。6. DNS重绑定攻击时间差的艺术DNS重绑定DNS Rebinding是一种更高级、更难防御的绕过技术。它利用了“域名解析结果可以变化”这一DNS的基本特性。6.1 攻击原理攻击流程如下攻击者注册一个域名如evil.com并完全控制其DNS服务器。为该域名设置一个非常短的TTL生存时间例如0秒或1秒。攻击者向存在SSRF漏洞的服务器提交URLhttp://evil.com/。服务器端的过滤器或第一次解析对evil.com进行DNS查询。此时攻击者控制的DNS服务器返回一个合法的、外网的IP地址例如1.2.3.4一个攻击者拥有的无害服务器。过滤器检查这个IP发现不在黑名单内于是允许请求。服务器程序开始向evil.com发起HTTP请求。由于TTL极短服务器的DNS解析器会重新查询evil.com的IP。此时攻击者瞬间将evil.com的DNS记录修改为目标内网IP地址例如192.168.1.1。服务器的DNS解析器拿到了新的IP192.168.1.1并基于这个IP建立了TCP连接发送了HTTP请求。由于这个连接是在DNS解析之后才建立的因此请求成功发往了内网地址。攻击者收到来自内网服务的响应可能需要通过外网服务器1.2.3.4进行中转或者在某些场景下直接能看到响应。6.2 成功条件与难点DNS重绑定攻击的成功需要多个条件同时满足服务器DNS解析器行为必须遵守TTL并且在每次建立新连接或连接池中的连接过期后时重新解析域名。有些客户端或操作系统会有DNS缓存可能不理会极短的TTL。过滤时机IP过滤必须在第一次DNS解析时进行并且不对后续实际的Socket连接所使用的IP进行再次校验。如果过滤逻辑集成在HTTP客户端库中并且在发起TCP连接前再次获取IP则可能失败。攻击者控制DNS需要有一个可以快速修改DNS记录的域名服务器。尽管条件苛刻但在云原生、微服务架构下由于服务实例生命周期短、DNS查询频繁DNS重绑定攻击的可行性在增加。一些公开的在线工具如rbndr.us提供了用于测试的DNS重绑定服务简化了攻击过程。6.3 防御思路从防御者角度看应对DNS重绑定需要在获取IP地址后立即使用并禁止在同一个会话中因DNS更新而切换IP。有些编程语言或库提供了禁用DNS缓存的选项但这可能影响性能。对解析出的IP进行持续校验不仅在请求发起前检查在建立TCP连接时确保连接的IP与之前解析的IP一致。但这需要更底层的网络控制。使用白名单域名而非IP直接信任特定的域名只允许访问这些域名从根本上避免依赖动态的IP解析。这是最有效但灵活性最差的方法。使用应用层代理或网络层防火墙所有出站请求必须经过一个代理该代理具有固定的DNS解析策略和严格的出口过滤规则。7. 实战场景与综合技巧理论需要结合实践。下面我们模拟几个经典场景看看如何综合运用上述技巧。7.1 场景一CTF题目中的经典绕过假设一个CTF题目提供了一个Web接口输入URL会返回该URL的内容但过滤了127.0.0.1、localhost、192.168.*、10.*等字符串并且检查URL是否以http://或https://开头。尝试步骤基础测试输入http://example.com正常返回。说明功能可用。IPv6测试输入http://[::1]/。如果返回了本地服务的信息如“Internal Server Error”或本机Web服务的默认页则绕过成功。进制转换输入http://2130706433/127.0.0.1的十进制。或者尝试http://0177.0.0.01/八进制。域名重定向如果上述都不行考虑302跳转。在自己的VPS上部署一个跳转脚本指向http://127.0.0.1/flag.php然后提交VPS的URL。非HTTP协议尝试file:///etc/passwd。如果题目允许任意协议且后端支持file可能直接读到文件。结合符号如果题目允许http和https但黑名单过滤很严可以尝试http://foobar.com127.0.0.1。这里需要理解解析顺序可能因库而异。更可靠的是利用URL编码http://%6c%6f%63%61%6c%68%6f%73%74即localhost的每个字符的URL编码。7.2 场景二真实环境中的内网探测与攻击假设在一个渗透测试中你发现了一个SSRF漏洞但目标服务器对请求地址做了严格过滤只允许访问*.target-company.com的子域名。攻击思路子域名接管检查是否有target-company.com的闲置子域名如dev.target-company.com、staging.target-company.com可以被你接管例如通过未删除的CNAME记录指向你的云服务。如果成功接管你就可以在该子域名上部署302跳转脚本将请求导向内网。利用已知服务如果目标内网有服务如Confluence、Jenkins存在XSS漏洞你可以构造一个URL通过SSRF让服务器去访问这些内网服务上的XSS页面。该XSS页面可以执行JavaScript将敏感数据回传这需要内网服务允许执行JS且能出网。这是一种“SSRFXSS”的组合拳。DNS重绑定尝试如果条件允许可以尝试DNS重绑定。将evil.target-company.com假设你通过某种方式注册或欺骗了一个近似域名的DNS记录先指向一个合法IP待SSRF过滤器通过后迅速重绑定到内网网关IP192.168.1.1尝试访问其管理界面。协议降级与端口探测即使主机名被白名单限制但协议可能没限制。尝试dict://assets.target-company.com:6379/info来探测该子域名主机上是否开放了Redis端口。因为dict协议可能不受HTTP主机白名单逻辑的约束。7.3 工具与自动化测试手动尝试所有变形效率很低。可以使用一些自动化工具来辅助Burp Suite的 Collaborator用于检测盲SSRF。将Collaborator生成的域名插入到可能的SSRF参数中如果目标服务器发起了请求Collaborator会收到通知从而确认漏洞存在。ffuf、gobuster等模糊测试工具可以用于快速枚举和测试各种IP变形、URL编码等payload。自定义脚本编写Python脚本使用requests或aiohttp库批量发送各种变形后的URL根据响应时间、长度、内容来判断是否成功。例如如果访问一个不存在的内网IP通常会快速超时或连接拒绝而访问到真实服务则会有不同的响应。8. 防御措施与安全开发建议了解了攻击手法作为开发者我们应该如何构建更坚固的防御统一解析与校验使用权威的URL解析库如Python的urllib.parseJava的java.net.URI来解析用户输入的URL并从中提取hostname。不要使用正则表达式手动解析URL极易出错。对提取出的hostname进行DNS解析获取其所有对应的IP地址可能是IPv4和IPv6。严格的IP地址过滤将解析得到的所有IP地址与内网IP段黑名单进行比较。黑名单应覆盖IPv4环回127.0.0.0/8IPv4私有地址10.0.0.0/8,172.16.0.0/12,192.168.0.0/16IPv4链路本地169.254.0.0/16IPv4多播224.0.0.0/4IPv6环回::1/128IPv6私有地址fc00::/7,fe80::/100.0.0.0和localhost域名重要必须将IP地址规范化后再比较。例如将0177.0.0.01先转换为标准的127.0.0.1。使用标准的IP地址处理库如Python的ipaddress来完成这个工作。协议白名单只允许业务必需的协议通常是http://和https://。明确拒绝file://、gopher://、dict://、ftp://等危险协议。禁用重定向跟随或对重定向目标进行二次校验配置HTTP客户端禁止自动跟随重定向如curl的CURLOPT_FOLLOWLOCATION设为0Pythonrequests的allow_redirectsFalse。如果业务必须允许重定向那么必须在每次重定向发生时对新的目标URL重复执行上述的解析、DNS查询和IP过滤流程。应用层出口过滤在服务器网络层面配置严格的出站防火墙规则限制服务器只能访问必要的公网IP和端口。即使SSRF漏洞存在请求也无法到达内网敏感系统。这是最后一道也是最有效的防线之一。使用网络隔离与认证将存在SSRF风险的服务部署在独立的安全区域DMZ与核心内网严格隔离。内网服务不应仅依赖IP白名单而应具备强身份认证如API密钥、双向TLS即使请求来自“内部IP”没有合法凭证也无法访问。安全意识与代码审计在代码审查中对所有从用户输入获取URL并发起网络请求的地方保持高度警惕。使用安全的默认配置。例如许多HTTP客户端库默认跟随重定向应在初始化时显式关闭。SSRF的攻防是一场关于“解析”和“信任”的博弈。攻击者不断寻找解析链条中的薄弱环节而防御者需要确保从用户输入到网络套接字建立的每一步都经过一致且严格的安全检查。没有一劳永逸的银弹唯有深入理解其原理结合白名单、规范化解析、网络层隔离等多重手段才能有效缓解SSRF带来的风险。在实际漏洞挖掘中面对一个SSRF点多角度尝试、耐心测试往往就能发现那些被开发者忽略的“模糊地带”从而打开内网渗透的大门。
