HTB CWPE: Server-Side Request Forgery (SSRF) and File Inclusion

What this domain tests

SSRF and File Inclusion tests whether you can make the server fetch or read resources it should not. Expect URL parsers, allowlists, redirects, cloud metadata, PHP wrappers, log poisoning, and path traversal.

Core rules and concepts

• SSRF begins with a full URL parser. Test scheme changes (http, https, file, gopher), userinfo tricks, decimal/octal/hex IPs, and DNS names that resolve to internal addresses.
• Allowlist bypasses often use redirects, @ in authority, trailing dots, or a domain you control that resolves to 127.0.0.1.
• Cloud metadata is a priority target: http://169.254.169.254/latest/meta-data/iam/security-credentials/ on AWS-style instances.
• LFI requires path normalization tests (../, encoded %2e%2e, double encoding) and wrapper knowledge: php://filter/convert.base64-encode/resource=index.php.
• LFI to RCE commonly uses log poisoning, session file inclusion, or upload plus include.
• Compare parser behavior between the validator and the HTTP client; mismatches are the exploit.

Worked example

An image importer accepts url=https://cdn.example/pixel.png. You try url=http://127.0.0.1:80/ and get a connection error, but url=http://127.1/ returns the internal admin page. The reasoning is that the validator blocks the literal string 127.0.0.1 but the HTTP client normalizes 127.1 to loopback. You then request http://169.254.169.254/latest/meta-data/ and confirm metadata access from the response body.

Traps that cost marks

• Calling blind SSRF a failure without testing DNS or HTTP callbacks.
• Forgetting that file:// may be blocked while php://filter works.
• Reading only the first metadata path and missing IAM credentials.
• Assuming traversal is blocked because ../ is stripped once; try nested and encoded forms.