PHP SSRF漏洞的根本原因是服务端直接使用未过滤的用户输入发起网络请求，且未严格校验协议、域名、IP、端口及重定向，导致攻击者可诱导服务器访问内网或敏感资源。
PHP SSRF 漏洞的根本原因是：服务端在发起网络请求时，直接使用了用户可控的输入（比如 URL 参数），且未对目标地址的协议、域名、IP、端口等关键字段做严格校验和限制。
这导致攻击者能“借刀杀人”——让服务器代替自己去访问本不该被外部触达的资源，比如内网服务、本地文件、云平台元数据接口等。
核心成因拆解
-
用户输入未过滤就进请求函数
常见危险函数如file_get_contents()、curl_exec()、fopen()、get_headers()、SoapClient等，一旦传入未经处理的$_GET['url']或$_POST['target']，就极易触发 SSRF。
例如：$url = $_GET['url']; echo file_get_contents($url); // 攻击者传 http://127.0.0.1:6379/ 即可打 Redis
-
URL 校验逻辑存在盲区
很多开发者用parse_url()提取 host 后做白名单判断，但忽略了：-
parse_url()不解析短格式 IP（如127.1→127.0.0.1） - 不处理 DNS Rebinding（同一域名反复解析出不同 IP）
- 未校验最终解析出的 IP 是否属于内网或敏感段（如
10.0.0.0/8,127.0.0.1,169.254.169.254）
-
协议支持过于宽泛
PHP 默认支持http://、https://、ftp://、gopher://、dict://、file://等多种协议。
攻击者利用gopher://可构造 Redis、MySQL、FastCGI 等协议载荷；用file://可读取/etc/passwd等敏感文件。重定向未被拦截
服务端请求若允许 30x 跳转，而校验只发生在初始 URL，攻击者可通过跳转绕过白名单。
比如先访问一个合法域名，再 302 到http://192.168.1.100/admin。
典型触发条件（三要素缺一不可）
- 用户能控制请求的目标地址（如通过表单、API 参数、回调 URL）
- 服务端用该地址发起网络请求（非前端 JS，是后端真实发包）
- 请求发出前，没有对目标做协议、域名、IP、端口、重定向的全链路校验
只要其中一环松动，SSRF 就可能落地。
一句话总结
SSRF 不是 PHP 本身的缺陷，而是开发过程中对“谁在发请求、往哪发、发什么”缺乏敬畏心 —— 把本该由服务端自主决定的事，交给了不可信的输入。
立即学习“PHP免费学习笔记（深入）”；
