Server-Side Request Forgery and Deserialization Vulnerabilities
SSRF and deserialization
SSRF occurs when the server fetches a user-controlled URL. Test allowlist parsing with decimal/octal IPs, IPv6, DNS rebinding, redirects, and URL schemes (gopher://, file://, dict://). Target cloud metadata at 169.254.169.254/latest/meta-data/ and internal services. Deserialization is language-specific: Java readObject with gadget chains (ysoserial), PHP unserialize and phar://, Python pickle, .NET BinaryFormatter, Node node-serialize. Look for magic methods (__wakeup, __destruct) and POP chains.
Worked example
An image importer takes url= and returns a thumbnail. Request url=http://127.0.0.1:80/admin; a different response confirms SSRF. Then request http://169.254.169.254/latest/meta-data/iam/security-credentials/ and retrieve temporary credentials. For PHP deserialization, a cookie contains base64 TzoxMjoiVXNlciI6...; decode it, change is_admin to true, re-serialize, and send it. The reasoning is to prove outbound reachability, then target the most valuable internal endpoint or object property.
Traps
Assuming SSRF is blocked because localhost is filtered; missing redirect-based bypass; not URL-encoding payloads; testing deserialization without a known gadget; forgetting that phar:// needs a file function; overlooking blind SSRF callbacks.