从请求链到证据链：SSRF 漏洞的审计、复现与加固实践

服务端请求伪造（SSRF）并不只是“让服务器代替用户发起一次请求”。在实际项目中，它往往和 URL 解析差异、重定向、DNS 解析、代理配置以及内网服务信任边界叠加出现。单纯增加一个“是否以 http 开头”的判断，通常只能拦住最简单的输入，无法形成可靠的防护。本文以代码审计和本地隔离实验为主线，整理一次 SSRF 问题从发现、确认到修复的完整思路。示例只针对本地测试服务和自有环境，不涉及访问真实云环境元数据或未授权内网系统。一、先明确 SSRF 的风险边界典型场景是后端提供了“抓取远程图片”“导入 Webhook”“检测 URL 是否可访问”“生成网页预览”等功能。用户提交一个 URL，服务端通过 HTTP 客户端访问该地址，再将响应内容返回或交给后续处理。风险通常来自三个方面：服务端网络位置比普通用户更接近内网，可能访问用户无法直接访问的管理面板、调试接口或内部 API。服务端携带了额外身份信息，例如内部请求头、环境凭据或代理认证信息。URL 解析和网络连接之间存在差异，应用层判断的目标地址与实际连接地址可能并不一致。因此，审计时不能只问“这个参数是否可控”，还要继续追踪：输入如何解析、是否发生 DNS 解析、是否允许跳转、请求使用了哪些凭据、响应最终流向哪里。二、代码审计：从输入点追踪到出网点第一步是寻找所有可能触发服务端出网请求的代码路径，常见关键词包括 requests.get、http.Client、HttpURLConnection、axios、fetch、WebClient 以及项目自定义的下载器。以 Python 为例，下面的代码看似只允许 HTTP 和 HTTPS，但仍然缺少目标地址限制、重定向控制和响应大小限制：from urllib.parse import urlparse
import requests

def fetch(url):
parsed = urlparse(url)
if parsed.scheme not in (