php-ssrf-audit

PHP SSRF Audit (php-ssrf-audit)

Analyze PHP project source code and identify SSRF risks: user-controllable URL/host/path entering network request or read-type functions, and lacking controls such as protocol allowlist, DNS/IP intranet denial, and port restrictions.

Grading and numbering

• See:shared/SEVERITY_RATING.md
• Vulnerability number:{C/H/M/L}-SSRF-{序号}

SSRF Sink (required)

Identify at least the following network/address access points:

• curl_setopt(CURLOPT_URL, $url) / curl_exec
• file_get_contents($url) / readfile($url) / fopen($url, {value})
• stream_get_contents($stream) / fsockopen / pfsockopen
• get_headers($url) / dns_get_record(when combined with address resolution) Dangerous patterns:
• URL/Host/Port/Path comes from user input and is controllable
• Protocol unrestricted (allows file://、gopher://、php:// , etc.)

Required security checkpoints

• Protocol allowlist: only allow http/https(if necessary)
• Intranet CIDR blocking after DNS/IP resolution: deny 127.0.0.1/::1/10.0.0.0/8/172.16.0.0/12/192.168.0.0/16 , etc.
• Port restriction: deny high-risk intranet ports (determined by project policy)
• Redirect handling: restrictions on following redirects (e.g. CURLOPT_FOLLOWLOCATION）
• Redirect and final address validation: even if the initial URL passes the allowlist, the same blocking and protocol validation must still be performed on the "final URL after redirection"
• DNS rebinding protection: when allowing domain access, the final resolution must be performed before actually initiating the request, or a secure resolution strategy must be used to avoid "external first, then intranet"
• URL normalization: for encoded host/path (double encoding, letter case, userinfo segment user:pass@host), normalize first before performing allowlist judgment

Conditions for triggering tracer

• URL is concatenated from multiple fields (schema + host + path + query)
• There are multiple layers of function calls or encoding/decoding/replacement
• Security judgment depends on string normalization (the real final URL must be traced)

Report output

{output_path}/vuln_audit/ssrf_{timestamp}.md

Vulnerability entry template (mandatory)

Same structure as php-sql-audit , but in the data flow chain it must cover:

• The source and concatenation process of the URL/Host/Port variables ultimately used to initiate the request
• Branch evidence for protocol selection and intranet blocking judgment

Evidence reference (mandatory: from php-route-tracer)

Each suspected SSRF vulnerability must item by item reference in the trace output ## 9) Sink Evidence Type Checklist the SSRF linescorresponding evidence points (it is prohibited to only write "possible"; the status may be pending verification, but the evidence reference must exist):

1. EVID_SSRF_URL_NORMALIZATION: URL normalization step (corresponding to the evidence point in the SSRF lines)
2. EVID_SSRF_FINAL_URL_HOST_PORT: the final URL/Host/Port before initiating the request (corresponding to the evidence point in the SSRF lines)
3. EVID_SSRF_FINAL_REDIRECT_URL: if redirection/following redirects exists: evidence of the final address after redirection (corresponding to the evidence point in the SSRF lines)
4. EVID_SSRF_DNSIP_AND_INNER_BLOCK: evidence of DNS/IP resolution and intranet blocking judgment (corresponding to the evidence point in the SSRF lines)

Handling of missing tracer evidence (mandatory)

• If any of the above key evidence points 1~4 cannot be found in the trace: the status of this vulnerability can only be marked as ⚠️待验证, and ✅已确认可利用。

PoC (mandatory)

• An executable request must be provided (HTTP code block)
• The PoC URL must use the real route and be replaced with the real controllable field names