上周做了一次授权评估客户有个在线PDF生成器业务场景是把指定网页转成PDF后提供下载。开发需求描述很简单让用户提交一个URL服务端去抓取内容再渲染成PDF。听起来是常规功能但我当时心里咯噔一下——这不就是典型的SSRF入口吗果然提交一个http://127.0.0.1/internal响应直接带出了内网管理页面的标题。从发现到利用前后不到十分钟。SSRFServer-Side Request Forgery服务端请求伪造之所以在漏洞榜上常年靠前不是因为它原理多深而是因为它把“本应可信的服务端出口”变成了“攻击者的跳板”。打点的时候一个能被构造的服务器请求往往比一个能直接执行命令的接口更隐蔽也更难防御。这篇文章适合三类人做渗透测试的兄弟需要理解SSRF如何从探测内网一路打到端口利用写业务代码的开发想搞明白为什么“获取远程图片”这种功能会翻车还有CTF选手想把协议利用和绕过思路串起来。接下来的内容会围绕漏洞成因、内网探测、端口扫描利用、绕过技巧和修复方案展开全程不整虚的。1. 先搞清楚SSRF到底怎么来的1.1 从“获取远程图片”功能说起很多Web应用都有这类功能用户提交一个URL服务端代替用户去请求然后把结果返回或处理。比如富文本编辑器上传图片时支持“远程图片URL”运营后台需要一个“网页快照生成”或者接口里有个callback参数用于回跳验证。从产品角度这是给用户提供便利从安全角度这就是在给攻击者开“内网侦察窗口”。我见过一个比较典型的实现后端用file_get_contents($_GET[url])直接读取URL然后把内容当图片返回。测试时传http://127.0.0.1/页面出现了本机默认站点内容传file:///etc/passwd连系统文件都读出来了。这里的关键点是请求是由服务端发起的不是用户浏览器发起的。所以它可以访问离开内网的设备才能访问的资源可以访问云环境里的元数据地址甚至可以用gopher://这种协议直接跟内网服务的TCP端口“对话”。生活里类比一下就是前台替你取快递你告诉她“去12号柜拿一个黄色包裹”这是正常功能。但如果你说“去财务室抽屉里拿一份文件”前台也会照做因为她没有判断这个取件地址是否属于她该去的地方。SSRF就是让服务端这台“前台”失去了对目标地址的边界判断。1.2 漏洞成因功能需求与信任边界失控SSRF的根因是代码把“用户可控的URL”直接交给了服务端网络请求函数且没有做足够的约束。拆开看一般有三个层面的缺失未限制协议只开放了业务需要的http/https但实际代码允许file、dict、gopher、ftp等协议。未限制目标地址没有对内网IP、保留IP段、云元数据地址做拦截。未处理重定向即使第一层URL校验了白名单服务端如果跟随重定向攻击者用一个外部域名跳到内网IP照样绕过。从代码上看最简单的漏洞模型就是这样的$url $_GET[url]; $content file_get_contents($url); echo $content;而Python同样常见import requests url request.args.get(url) resp requests.get(url) return resp.text问题不在函数本身而在于$url完全来自用户且file_get_contents或requests.get默认支持多种协议和重定向。一旦“用户输入”被当成了“可信的服务端调度参数”信任边界就失控了。不同语言和库还有一些小差异。curl扩展如果不显式设置CURLOPT_FOLLOWLOCATION默认不跟随重定向requests库默认会跟随重定向PHP的file_get_contents对http://重定向的处理和老版本有关。这些差异在绕过场景里会非常有意思也是后文要展开的。1.3 SSRF的分类和危害按回显情况SSRF可以分成三类有回显服务端请求的内容直接返回到页面上。这是最好利用的一类可以直接读文件或访问内网Web应用。无回显盲SSRF请求确实发出去了但页面不展示响应内容只能通过DNSLog、时间延迟或响应状态差异判断。部分回显不返回完整内容但会根据目标端口开放情况返回不同的错误信息。比如Connection refused代表端口关闭Connection reset说明有服务在监听这类也算可利用。危害层面轻则探测内网端口重则直接拿内部服务器。常见利用路径包括扫描内网存活主机和端口、读取本地文件、访问未授权的内网管理后台、攻击Redis/MySQL等TCP服务、读取云厂商元数据中的临时密钥。这些不是理论很多授权测试场景里都真实出现过。一个“URL转缩略图”的功能最后拿到内网服务器权限这种事在漏洞报告里也不算新鲜。2. 探测内网SSRF利用链的入口2.1 怎么判断目标是否存在SSRF判断SSRF其实不难关键是找到能触发服务端请求的参数。常见参数名有url、link、src、target、proxy、callback、redirect、imageUrl等。拿到参数后先做最基础的验证http://127.0.0.1/ http://127.0.0.1:80/ file:///etc/passwd dict://127.0.0.1:6379/info如果页面返回了127.0.0.1上的页面内容或者返回了root:x:0:0:这类系统文件内容说明存在有回显的SSRF而且协议过滤很可能没做。若是无回显还可以利用时间差提交一个公网可达的URL比如http://example.com记录响应时间。提交一个内网不存在的IP比如http://192.168.250.250/如果目标环境对不存在IP直接返回Connection refused响应会很快。提交一个内网可能存在的IP比如http://192.168.1.1/如果防火墙丢弃请求响应时间会明显拉长。通过多组对照就能反推目标是否在内网发出过连接。这里有个小技巧同时观察返回状态码和响应体。有些网关设备或内网Web服务即使拒绝HTTP请求也会返回特定的Server头或错误页面这些细节都是判断依据。2.2 内网网段探测与存活主机识别确认存在SSRF后下一步就是确定内网网段。如果没有任何情报先从RFC1918私有地址开始猜10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。很多企业内部网络会按部门或区域划分C段所以从一个已知IP的C段开始扫命中率会高很多。比如源站IP是192.168.10.5那么内网其他机器大概率在192.168.10.0/24附近。手工测试存活主机时可以直接构造URL观察响应差异http://192.168.10.1/ http://192.168.10.2/ http://192.168.10.3/如果某台机器开放了HTTP服务响应体里会返回页面内容如果只开放了SSH目标服务器发的HTTP请求过去返回的可能是“Connection reset by peer”或“400 Bad Request”如果机器不存在网络层面可能迅速返回“Connection refused”也可能一直超时。利用这种差异就能画出一个粗糙的内网存活清单。大规模扫描建议写脚本自动化但一定要控制并发和速率。我自己测试时会把线程数限制在10以内超时时间设成3秒左右然后逐C段推进。你可以参考一个简单的思路先把要测试的IP列表生成好用线程池发起请求记录每个IP的状态码和响应时间再根据结果筛选。脚本本身不复杂但一定要先确认授权范围别把业务的网络出口打满。如果目标支持file://协议且有回显另辟蹊径的办法是读取/etc/hosts有时候内网主机名和IP直接列在里面省去扫描的工夫。当然这要看目标是不是Linux环境、PHP代码是否允许file协议。2.3 无回显场景下的确认手段无回显SSRF最常用的确认手段是DNSLog。在自己的DNSLog平台拿到一个子域名然后提交http://随机子域名.dnslog.cn/如果平台上立刻收到解析记录说明服务端确实发起了请求且能够访问外网。这里要特别说明DNSLog只能证明请求能出网不能直接用来扫内网IP因为内网IP不会通过外部DNS解析。所以无回显情况下的内网探测更多还是依赖时间差和业务侧表现。还有一种思路是利用目标服务向外部HTTP平台发起回调。比如搭建一个临时监听端口当SSRF请求过来时能看到完整路径、User-Agent等信息。这种“反连”方式在盲SSRF里非常实用既能确认漏洞也可以尝试外带一些信息。如果目标只能访问内网、不能访问外网那就老老实实用时间差和协议差异来判断不要过度依赖DNSLog。3. 端口扫描利用如何把SSRF变成内网侦察神器3.1 端口扫描的原理与响应差异SSRF能做端口扫描本质上是服务端代替我们完成了TCP连接尝试而连接结果会通过状态码、响应时间、错误信息反映出来。这和普通端口扫描的原理一样只是扫描源变成了目标服务器。常见的响应差异可以归纳成四类端口状态表现判断依据开放且是HTTP服务返回200/302/500等响应体可能有页面内容状态码、Server头、标题开放且是非HTTP服务返回400 Bad Request、Connection reset或连接后无响应错误信息、耗时关闭快速返回Connection refused响应时间短错误明确防火墙丢弃长时间超时响应时间明显拉长手工扫端口时我会直接用一个“探测字典”的URL集合。比如dict://192.168.10.20:22/ dict://192.168.10.20:3306/ dict://192.168.10.20:6379/ dict://192.168.10.20:9200/ dict://192.168.10.20:11211/dict协议的好处是请求发出后会返回服务端的响应方便区分端口开放与否。有些端口还会直接暴露banner比如dict://192.168.10.20:6379/info如果Redis未授权甚至能把版本信息和服务器信息都带出来。用curl -w看每个请求的耗时也很方便curl -w %{time_total}\n http://target/ssrf?urldict://192.168.10.20:6379/info端口的选择也有讲究。别只盯着常见端口内网里真正值钱的目标往往在8080、7001、8161、9200、11211这类端口上。扫描思路应该是“先找开放HTTP服务的端口再找未授权访问较高的中间件端口最后再考虑数据库和缓存”。3.2 常见内网服务利用扫到端口只是第一步真正让SSRF产生大危害的是后续利用。下面几个场景在授权测试里遇到得最多。Redis未授权访问算是最经典的一条路。很多内网Redis为了部署方便既没设置密码又绑定了0.0.0.0。如果SSRF支持gopher://协议就能直接构造Redis命令。比如用Gopher序列化一段Redis协议数据写入计划任务、SSH公钥或Webshell。一个简单的Redis写文件payload格式类似gopher://192.168.10.20:6379/_*1%0d%0a$8%0d%0aFLUSHALL%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$...实际使用时需要对Redis协议做完整编码。工具有现成的Gopherus生成payload很方便但建议自己也理解一遍协议结构*N代表后面有N个参数$M代表参数长度为M字节后面紧跟CRLF。只要编码对SSRF就能像本地的redis-cli一样发命令。MySQL、Memcached、Elasticsearch也类似。MySQL握手包复杂手动构造比较麻烦一般先确认端口开放和版本信息再走其他漏洞利用链路。Elasticsearch如果存在未授权http://192.168.10.20:9200/_cat/indices直接在SSRF里就能看到索引数据。Memcached可以用dict协议直接读写缓存如果能控制缓存内容甚至能影响业务逻辑。另一个高价值目标是云环境的元数据地址。在云服务器上SSRF请求http://169.254.169.254/latest/meta-data/可能读到实例ID、主机名、RAM角色等阿里云是http://100.100.100.200/latest/meta-data/腾讯云是http://metadata.tencentyun.com/latest/meta-data/。如果拿到了临时密钥威胁范围会直接从一台服务器扩大到整个云账号。这里多说一句不同云厂商对元数据服务的加固程度不同有的还支持IMDSv2强制Token但依然有不少环境直接开放了HTTP根路径。3.3 如何提高利用成功率实际利用过程中最容易翻车的有三个点协议支持、URL编码、目标网络环境。先说协议支持。很多代码只允许http://和https://那gopher和dict就用不了。遇到这种情况可以先用HTTP协议探测内网Web资产比如访问http://192.168.10.20:8080/如果返回了Tomcat管理页面或Spring Boot Actuator也能玩出很多东西。不要一上来就纠结为什么不能打Redis先把能打的点列全。再说URL编码。gopherpayload里包含大量不可见字符和CRLF提交到目标时要经过URL编码。有时候我们按照URL编码提交了但服务端会再做一次解码导致实际到达Gopher协议的数据被二次编码请求就废了。解决办法是多试几次不同层级的编码或者直接在Burp里对比发送前后的数据包确认服务端拿到的是不是原始字节流。最后是网络环境。目标服务器可能位于安全组后只有特定端口能出网也可能出口流量被代理网关记录。所以实战时要小步快跑先用2-3个目标验证响应模型再扩大范围。不要拿一个没有授权的内网段做大量连接也不要在生产环境使用阻塞型命令。4. 进阶绕过与实战技巧4.1 URL解析差异与白名单绕过很多开发者在修复SSRF时第一个想法是“校验URL前缀”或者“校验URL里包含的域名”。但这种校验如果没做彻底绕过方式非常多。最常见的是符号混淆http://allowed.example.com127.0.0.1/URL标准里前面的部分被当作用户名信息实际请求连接的还是127.0.0.1。如果代码只检查字符串里是否有allowed.example.com就很容易被绕过去。还有IP地址的多种写法http://2130706433/ # 十进制的127.0.0.1 http://0x7f000001/ # 十六进制的127.0.0.1 http://0177.0.0.1/ # 八进制的127.0.0.1 http://[::ffff:127.0.0.1]/ # IPv6映射地址这些写法用浏览器或curl请求时都能解析到本地回环地址但字符串校验往往只认127.0.0.1格式看到数字或十六进制就放行了。重定向绕过也很常见。假设白名单允许http://example.com攻击者控制一个域名或短链访问它以302跳转到http://192.168.1.1。如果服务端跟随重定向且不重新校验SSRF就成立了。反过来如果服务端本身不跟随重定向也可以找目标业务里的其他跳转接口或者利用多个重定向叠加把最终的Location指到内网。DNS解析绕过同样值得注意。如果攻击者有一个可控域名先将域名A记录指向正常公网IP等代码用字符串校验域名通过后再改DNS记录指向127.0.0.1。服务端发起请求时重新解析就会拿到内网IP。这种手法依赖服务端是否在每次请求时都做DNS解析但成功率高是白名单校验比较大的克星。4.2 盲SSRF与DNSLog/反连平台盲SSRF没有回显利用难度会上一个台阶但也不是无解。确认漏洞存在后第一件事还是用DNSLog平台建立“外带”通道。提交一个包含唯一标识的URLhttp://唯一标识.dnslog.cn/如果DNSLog收到解析记录说明服务端发出了HTTP请求。这个通道的用处不只是证明漏洞存在还可以配合时间盲判来探测内网。比如我们想让目标去访问http://192.168.1.1:8080/可以同时观察DNSLog是否出现对该域名不行内网IP不经过DNS。所以盲SSRF的内网探测本质上还是靠响应时间差或者靠“请求结果是否触发了业务后续动作”来判断。反连平台则更适合确认“服务端能连到我们控制的机器”。在公网服务器上监听一个HTTP端口提交http://你的服务器IP:端口/path如果监听器收到请求说明目标能出网且我们能看到完整请求头。这为后续可能的外带数据提供了基础。有些场景里盲SSRF还能配合异步功能比如生成PDF报告时服务端会去请求URL我们可以在URL里写入命令注入或数据外带参数。记住一个原则盲SSRF的威力取决于“我们能观察到的旁路信号”。信号越丰富利用越深。4.3 从SSRF到内网横向的路径把前面的技术点串起来一条典型的SSRF攻击链是这样的找到Web应用中的一个URL参数确认存在SSRF。探测内网绘制存活主机和端口清单。发现某台内网主机开放Redis 6379且未授权。使用gopher://构造Redis写文件payload写入计划任务或SSH公钥。通过SSH/shell登录目标服务器实现横向移动。如果是授权测试我在每一步都会保留请求和响应记录因为最后写报告时需要证明“影响链”是完整的。不要只在报告里写“存在SSRF”那样会被开发怼“SSRF又不能证明危害”。你把从SSRF到Redis未授权再到拿到系统shell的完整截图和请求记录摆出来开发才会认真去修。除了Redis内网Web管理后台也是SSRF的常见目标。比如Spring Boot Actuator未授权接口/actuator/env可能泄露配置和密钥Druid监控页面的/druid/websession可能泄露会话Jenkins的/script接口如果未授权甚至可以直接执行Groovy命令。SSRF的价值之一就是把原本只能通过内网访问的这些调试接口暴露出来。5. 修复与防御别只修一个点5.1 服务端代码侧的SSRF防护设计代码层修复的核心原则很简单不信任用户输入的URL不直接把它交给底层请求库。但落在实现上需要注意下面几个点。先解析后校验。拿到URL后先把URL拆成协议、Host、端口、路径再用安全函数解析出Host对应的IP。不要只做字符串判断因为http://127.0.0.1.nip.io这类域名也可能解析到内网。校验IP时建议覆盖以下地址段127.0.0.0/8本机回环10.0.0.0/8、172.16.0.0/12、192.168.0.0/16私有地址169.254.169.254、100.100.100.200、metadata.tencentyun.com等解析出的地址云元数据IPv6的映射地址和链接本地地址协议白名单只放行http和https端口默认只允许80和443如果业务确实需要其他端口再单独加白名单。同时关闭重定向跟随或者每次重定向后都重新执行一遍IP校验。如果业务必须支持重定向可以采用“单跳白名单”策略只允许重定向到授权域名。代码里可以做一个统一出口函数所有服务端请求都必须经过这个函数。函数内部统一处理URL解析、DNS解析、IP校验、端口校验、超时设置、错误信息脱敏。这样开发新业务时就不太容易出现“某处又绕过了防护”的问题。5.2 网络层加固与监控代码修得再好网络层不兜底还是可能出问题。很多SSRF能打到内网本质上是服务器能访问的内网面太大了。所以安全组和防火墙层面建议限制服务器出站流量只放行业务必需的目标IP和端口。尤其对云环境尽量用安全组把“服务器到元数据服务”的访问也控制住。内网服务必须做认证。Redis要设置requirepass并只绑定业务网卡不要直接监听0.0.0.0且无密码MySQL、Elasticsearch、Memcached同理。很多SSRF利用成功靠的就是内网服务“裸奔”。内网不等于安全这句话在安全圈讲了十年但依然有大量内网服务没有认证。监控侧重点有两块。一是日志审计服务器上对外发起的请求都要有日志一旦出现访问file://、gopher://、dict://或者访问内网地址段的异常请求能及时告警。二是WAF规则针对file://、gopher://、dict://、127.0.0.1、169.254.169.254等特征加检测规则虽然容易被绕过但至少能挡掉一部分批量扫描和脚本小子的请求。5.3 修复后的验证方法修复SSRF后不能只submit一个http://127.0.0.1/看到返回空就认为修好了。验证时必须覆盖前面提到的绕过手法IP变体、URL编码、重定向、DNS解析、符号混淆。我一般会准备一个测试用例列表逐条跑一遍比如http://127.0.0.1/ http://2130706433/ http://0x7f000001/ http://[::ffff:127.0.0.1]/ http://allowed.com127.0.0.1/ http://127.0.0.1#allowed.com同时检查错误响应是否泄露了内部信息。修复方案做得好的话用户只会收到一个统一的“请求失败”而不是“GET http://192.168.x.x:6379/ ... Connection refused”这种内部地址和端口信息。信息泄露看着是小问题但对攻击者而言这就是内网拓扑的地图。6. 常见问题与排查技巧实录6.1 SSRF实战中的典型问题速查我在测试和带新人的过程中经常遇到下面这些情况整理成一个速查表现象可能原因排查思路提交http://127.0.0.1没反应无回显SSRF或URL被过滤换DNSLog确认请求是否发出只能使用httpgopher被拦代码做了协议白名单先探测内网HTTP服务报错信息直接显示内网地址有回显且错误信息未脱敏收集错误信息估算内网段内网扫描全部超时出站被防火墙限制或目标网段过大缩小范围从业务依赖的IP开始Redis payload执行失败Gopher协议编码错误核对*N和$M格式及URL编码元数据地址读到但无权限云厂商使用IMDSv2或RAM角色无权限检查是否可用Put方法获取TokenWAF拦截SSRF请求规则匹配到关键字尝试编码、IP变体、重定向绕过请求成功但页面无内容响应被业务层截断看响应状态码、时间差、DNSLog这些问题里最常见的是“无回显不会测”。其实盲SSRF只要耐心好利用DNSLog和时间差也能确认漏洞只是写报告时说服力稍微弱一点。遇到这种情况我会建议补充一条使用一个存在计时差异的payload证明响应时间随目标IP不同而变化这也能作为漏洞存在的证据。6.2 实操心得与报告经验最后分享几条真正来自实战的心得。第一务必拿到授权。SSRF的探测和利用天然带有“扫描内网”的行为如果没有书面授权严格来说就是非法渗透。很多同行最后惹上麻烦不是技术问题而是测试范围没谈清楚。我建议在测试前把内网探测的IP范围也写进授权协议宁可多写也不要事后解释。第二保留完整证据。每个请求的原始报文、响应报文、响应时间都要存好尤其是端口扫描和Redis利用的过程。报告审核人会怀疑“你说Redis未授权证据呢”这时候你甩出一组dict://192.168.10.20:6379/info的请求和响应截图比任何文字都管用。第三控制操作风险。不要在生产环境随便打FLUSHALL不要写一个错误的crontab把目标机器搞挂。能在靶场复现的就先去靶场复现必须在线测试时优先选只读命令比如Redis的INFO、GETElasticsearch的_cat/indices。如果一定要写文件先确认目标路径和权限写一条影响可控的内容。第四报告里把危害讲清楚。很多开发不理解SSRF觉得“不就是服务器帮我访问一下吗”。你要告诉对方这台服务器能访问的每一个内网地址、每一个端口都有可能被外部请求触达可能读到云元数据中的密钥也可能被用来攻击内网数据库。把“影响范围”写成“从Web层到内网层”的完整链路修复优先级自然就上去了。我自己在做项目复盘时越来越觉得SSRF是“最容易漏掉又最容易被低估”的漏洞。它不像SQL注入那样有强烈的报错特征也不像RCE那样一击必杀但它的组合性非常强。一次SSRF能打多远取决于开发者给服务端开放了多大的内网权限也取决于测试者能不能把协议利用和业务逻辑串起来。拿到一个SSRF后不要急着截图收工多花十分钟探测内网往往会有意外发现。