SSRF是服务器端请求伪造，攻击者诱使服务器发起恶意请求，核心成因是未校验用户可控URL的协议、IP范围及端口；防御需白名单协议、禁用内网地址、限制端口并二次解析DNS。
SSRF（服务器端请求伪造）和 CSRF（跨站请求伪造）是两种完全不同的攻击类型。你标题里写的“服务器端请求伪造”，对应的是 SSRF，但所有提供的知识库内容全部围绕 CSRF（客户端发起的伪造请求），没有一条提及 SSRF 防护机制、配置或代码实践。
ThinkPHP 官方文档与生态中，不存在内置的 SSRF 防御模块、中间件或配置项。框架本身不解析、不限制、也不校验你在控制器里调用的 file_get_contents、curl_exec、file()、simplexml_load_file 等函数所访问的 URL —— 这些行为完全由开发者控制，框架不介入。
所以结论很直接：
ThinkPHP 不防范 SSRF，也从不承诺防范 SSRF。你得自己拦。
为什么 ThinkPHP 项目容易出现 SSRF 漏洞
常见于以下几种硬编码或参数直传场景：
立即学习“PHP免费学习笔记（深入）”；
- 用户提交一个
url参数，后端直接拿它去curl_exec请求（比如“远程图片上传”、“API 聚合代理”、“Webhook 回调地址验证”） - 用
file_get_contents(input('get.src'))加载外部资源并渲染 - 调用第三方 SDK（如微信 JS-SDK 签名生成、OSS 回调校验）时，把用户可控的域名拼进请求地址
- 未过滤协议头，允许
ftp://、gopher://、data://、php://filter等危险协议
如何在 ThinkPHP 里手动防御 SSRF
没有银弹，只有逐点加固。关键不是“加个中间件”，而是守住每个出站请求入口：
-
禁止协议白名单外的 scheme：只允许
http和https。用parse_url($url, PHP_URL_SCHEME)提取协议，严格比对 -
禁止私有 IP 和内网地址：解析出 host 后，用
ip2long+filter_var($host, FILTER_VALIDATE_IP)判断是否为 IPv4；再用filter_var($host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)排除127.0.0.0/8、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、100.64.0.0/10等范围 -
禁止端口非标开放：限制 port 只能是
80、443，或显式白名单（如8080、8443）；避免用户传http://x.com:22或:6379 -
禁用 DNS 重绑定绕过：不要只校验一次 host，而应在发起请求前再次解析——因为 DNS 可能在你校验后、请求前被篡改。更稳妥做法是用
gethostbyname($host)获取 IP 后立即校验 -
避免使用用户输入拼接 URL：优先用固定域名 + 用户 ID/Token 查询后端服务，而不是让用户填完整 URL。例如，把
/api/proxy?url=https://xxx改成/api/proxy?service=wechat，再由后端查配置表映射真实地址
ThinkPHP 场景下特别容易踩的坑
这些不是 ThinkPHP 的 bug，而是开发者忽略上下文导致的误用：
-
input('get.url')直接喂给curl_init()—— 没做任何协议/域名/IP 校验 - 用了
Request::instance()->domain()或request()->root()拼接跳转地址，但没意识到攻击者可通过 Host 头污染这些值（尤其 Nginx 配置不当或启用了proxy_set_header Host $host） - 在命令行（CLI）模式下调用接口时，
$_SERVER['HTTP_HOST']为空，导致某些“只校验 Host”的逻辑失效，却仍执行了外呼 - 日志中间件里记录了原始
input('post.')，如果其中含 URL 字段，且日志系统支持渲染链接，可能触发服务端 HTML 解析（极少见但存在）
真正难的从来不是写几行校验代码，而是识别出哪一行是你项目的 SSRF 入口点。它不会出现在路由定义里，也不会报错提示，往往藏在某个“功能正常”的业务方法深处。现在就去 grep 你的代码：curl_、file_get_contents、file_put_contents、simplexml<em>load</em>、json_decode(file_get_contents(、include http://……
每一个都得人工确认输入是否可控、是否经过上述四层校验。
