SSRF - Server Side Request Forgery (Types and ways to exploit it) Part-1

(Please ignore mistakes if any!)

First things first

What is SSRF?

Server Side Request Forgery (SSRF) refers to an attack where in an attacker is able to send a crafted request from a vulnerable web application.

In a simple way - Attacker asks the server to fetch a URL for him

For example -

GET /?url= HTTP/1.1

Here fetch from its server

Table of Contents

1. Types of SSRF
2. Test Cases
3. Bypass Whitelisting and Blacklisting
4. Live Example
  1. Types of SSRF -

i. The one which displays response to attacker ( Basic )

ii. The one which does not display response ( Blind )

i. Basic -

As mentioned It displays response to attacker, so after the server fetches the URL asked by attacker for him, it will send the response back to attacker

DEMO (using Ruby)
INSTALL the following package and run the code

gem install sinatra

require 'sinatra'
require 'open-uri'

get '/' do
format 'RESPONSE: %s', open(params[:url]).read

The above code runs a server on port 4567 ( Took from Jobert’s Post )

So this just opens the file for us
: http://localhost:4567/?url=contacts will open contact file and display response to frontend
: http://localhost:4567/?url=/etc/passwd will open etc/passwd and response to serve
: http://localhost:4567/?url= will request on server and show response

What can we do with SSRF? -

  • SSRF to Reflected XSS
  • Try URL schemas to read internal and make server perform actions (file:///, dict://, ftp://, gopher://..)
  • We can scan for internal networks and ports
  • If it runs on Cloud Instances try to fetch META-DATA

SSRF to Reflected XSS -

Simply fetch a file from external sites which has malicious payload with content type served as html

Example - http://localhost:4567/?url=

Testing URL schemas -

First thing to do when we find an SSRF is to test all the wrapper which are working


file:// -

File is used to fetch file from the file system

If the server block http request to external sites or whitelist you could simply use below URL schemas to make a request

dict:// -

DICT URL scheme is used to refer to definitions or word lists available using the DICT protocol:$ nc -lvp 1337
Connection from [] port 1337 [tcp/*] accepted (family 2, sport 31126)
CLIENT libcurl 7.40.0

sftp:// -

Sftp stands for SSH File Transfer Protocol, or Secure File Transfer Protocol, is a separate protocol packaged with SSH that works in a similar way over a secure connection.$ nc -lvp 1337
Connection from [] port 1337 [tcp/*] accepted (family 2, sport 37146)

ldap:// or ldaps:// or ldapi:// -

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

tftp:// -

Trivial File Transfer Protocol is a simple lockstep File Transfer Protocol which allows a client to get a file from or put a file onto a remote host nc -lvup 1337
Listening on [] (family 0, port 1337)

gopher:// -

Gopher, is a distributed document delivery service. It allows users to explore, search and retrieve information residing on different locations in a seamless fashion. (host it on
header('Location: gopher://');
?> nc -lvp 1337
Listening on [] (family 0, port 1337)
Connection from [] port 1337 [tcp/*] accepted (family 2, sport 49398)

For more Refer here

Scan for internal networks and ports -

What if they are running some servers in their LAN (Kibana, Elastic Search,MongoDB.. )

Which we can not access from internet directly as firewall blocks them

We use SSRF to access them.

Attacker runs a internal IP and PORT scan and understands more about the target and use it for further exploitation

This can some times lead to Remote Code Execution

Example - Found an internal host running an outdated software which has publicly know RCE, we can use it here to perform code execution and same applies for other vulnerabilities

Cloud Instances -


If you find an SSRF in Amazon Could, Amazon expose an internal service every EC2 instance can query for instance metadata about the host. If you found an SSRF vulnerability that runs on EC2, try requesting :

This will give our juicy information like Aws keys, ssh keys and more

Refer these for POC- #285380, #53088

For example:-

Google Cloud -

Same for google

Further exploiting this can lead to instances takeover

Refer - #341876

Digital Ocean -

Overview about Meta-data

And for other Cloud Instances you can refer Here

./End of part 1