Skip to main content
A Server-Side Request Forgery (SSRF) vulnerability occurs when an attacker manipulates a server-side application into making HTTP requests to a domain of their choice, exposing the server to arbitrary external or internal requests.

Capturing SSRF Interactions

The first step is capturing an SSRF interaction you generate. Use tools such as:

Whitelisted Domain Bypasses

SSRF is often restricted to whitelisted domains. Common bypass techniques:

Supported Protocols

Directly access local files:
Access DICT protocol servers:
Send raw TCP bytes to any service. Useful for attacking Redis, SMTP, internal APIs:
Use Gopherus to generate Gopher payloads for:
  • MySQL, PostgreSQL, FastCGI, Redis, Zabbix, Memcache

SSRF via Special Headers

SSRF via TLS AIA CA Issuers (Java mTLS)

Some TLS stacks auto-download missing intermediate CAs using the Authority Information Access (AIA) → CA Issuers URI inside the peer certificate. In Java, enabling -Dcom.sun.security.enableAIAcaIssuers=true makes the server dereference attacker-controlled URIs during the TLS handshake, before any HTTP logic runs.

Misconfigured Proxy SSRF

Cloud SSRF Exploitation

In cloud environments, SSRF can access metadata endpoints:

Blind SSRF

When you cannot see the response:
Check timing of server responses to determine if a resource exists:
  • Requests to existing internal hosts may respond faster or slower.
  • Use timing differences to map internal networks.

HTML-to-PDF Renderers as Blind SSRF Gadgets

Libraries like TCPDF and html2pdf automatically fetch URLs present in HTML while rendering a PDF:

DNS Rebinding CORS/SOP Bypass

DNS rebinding can be used to bypass CORS/SOP restrictions when exfiltrating content from local IPs:
  1. Victim visits attacker’s page
  2. Attacker changes DNS to point to internal IP (TTL=0)
  3. Subsequent requests from victim’s browser go to internal service
  4. Content is exfiltrated
Tool: Singularity of Origin

SSRF to RCE Chains

Tools