The scheme is the protocol prefix that selects which handler resolves a URL. SSRF defenses concentrate on http and https, but a URL library services whatever handlers its runtime registers, and each one reaches a different target. Supplying an unexpected scheme is often the difference between a blind HTTP fetch and a direct file read or a raw-byte write to an internal service.
The pages group by what the handler buys an attacker:
- Local data: File reads the filesystem through
file://. - Raw TCP to internal services: Gopher writes arbitrary bytes to a TCP port, which smuggles crafted protocol payloads (Redis, SMTP, HTTP) and is the most powerful scheme when available.
- Service-specific reach: DICT, LDAP, SFTP, and TFTP speak to their named services and double as interaction and port probes.
- HTTP itself: HTTP and HTTPS is the baseline scheme, reaching internal web services and the metadata endpoint, and pairs with Port for scanning.
- Runtime-specific handlers: JAR and Netdoc are Java URL handlers that extend reach on JVM stacks.
Probing which schemes resolve#
Before building a scheme-specific payload, confirm the handler exists. Point each scheme at an attacker-controlled listener or an obviously invalid target and watch the error or interaction: a connection attempt, a protocol-specific error, or a timeout each distinguish a registered handler from one the library rejects outright. The handler set depends on the language, the URL library, and its configuration, so enumeration precedes exploitation.
Tools#
- SSRFmap: automated SSRF exploitation across internal targets with per-scheme modules.
- Gopherus: crafts gopher payloads for Redis, FastCGI, and SMTP via SSRF.
- Burp Collaborator: out-of-band interaction detection for blind SSRF.
- curl: manual probing of which schemes a handler resolves.