• Home
  • Blog

Finding a SSRF can be a pretty tough task ! So the climbing the Everest ! But people do climb ! What do they do? They climb in steps ! That’s exactly what we are gonna do. We will learn SSRF in steps!

Introduction To SSRF

So, SSRF abbreviation of Server Side Request Forgery is type of vulnerability that tries to gain access of internal resources of system which then gives ability to attacker to read, update internal resources. It has so many potential risks such as port scanning, arbitrary command injection, reading and updating internal resources etc.

Types Of SSRF

Blind SSRF : Blind SSRF occurs when an application is making a request to a back-end server due to some reasons but the response is not shown on the front-end. 

Full Response SSRF : It is the most critical vulnerability. In this vulnerability data can be fetched from internal service using arbitrary URI

Limited Response SSRF(Semi-Blind) : In this vulnerability, only some data is displayed.

Blind SSRF

Blind SSRF occurs when you never get any information about a target service from the initial request. Typically, an attacker will provide a URL, but data from this URL will never be returned to the attacker. To confirm a vulnerability in this case, an attacker must use Burp Collaborator, DNSbin, or a similar tool. Blind SSRF is easy to validate, but difficult to exploit.

Steps To Perform Blind SSRF

You have to search search for such part in website that interacts with external sources and resources of website. One example can be file, image upload functionality via link. 

1.Find functionality which interacts with external resources

2.Turn on burp collaborator, copy payload and click on poll now

3.Enter burp collaborator payload with http or https in particular input

4.Go in burp collaborator and wait for http response

5.If you get http response then, copy the ip address from response

6.Go to https://who.is/ and paste the ip address and see if the address is of that particular organization of which the website is.

7.If it is then probably you have got internal ip address through blind SSRF !

Further it can be exploited using shellshock exploitation. Here’s portswigger lab that you can solve to learn about it : https://portswigger.net/web-security/ssrf/blind/lab-shellshock-exploitation

Full SSRF Steps

Here you have to find vulnerable input parameters and have to check on case by case basis if it is vulnerable to SSRF using different payloads and comparing different response.

  1. You can use tools like Gau, Wayback URLs, Internet Archive, Paramspider to find endpoints and parameters to test for.
  2. Next, You have use different types of payloads such as

 <?php header("location:"); ?>

Now, Here you can use various bypassing techniques like,

By Using Local Host

Local File Read Payloads


Bypass localhost with [::]

http://[::]:25/ SMTP
http://[::]:22/ SSH

Bypass localhost with a domain redirecting to localhost

https://xyz.com — ->>
http://mail.ebc.apple.com redirect to == localhost
http://bugbounty.dod.network redirect to == localhost

Bypass using a decimal IP location

http://2130706433/ =
http://3232235521/ =
http://3232235777/ =

Bypass localhost with CIDR

Bypass using malformed urls


Bypass using rare address


Bypass using bash variables

curl -v “http://evil$google.com”
$google = “”

Bypass using enclosed alphanumerics

http://ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ = example.com

Bypass filter_var() php function


Bypass Using Weak Parser


3.After bypassing these protections you would be getting different responses varying from execution os command like whoami to local file read.

Local File Read
Metadata of cloud

Semi-Blind SSRF

In Semi-Blind SSRF some data is exposed not all. It can also give some error messages through which data is leaking at some extents. Also it can show you metadata. Using semi-blind SSRF, you can prove the existence of vulnerability but information you retrieve is always not serious.

Risks :

Sensitive Data Exposure

Port Scanning

Internal IP leak

Local File Read

OS command injection

Mitigations :

Use Of Proxies

Create separate proxy when users will make request from application/software. Using different proxy will save organization from attackers accessing companies main intranet. Further you can also configure rules out there.

Use Of Firewall

Using firewall is always a better option. By using statefull firewall we can reduce the risk of SSRF to great extent.

Network Segmentation

People don’t always need to connect with companies intranets so, Network Segmentation is also a great option to keep organization safe from SSRF attack.

Checking security issues in third party services

Mostly application/software fetching or using third party services is likely to vulnerable for SSRF. Cause, we don’t always check if third party service is vulnerable or not. If the rules for URL are set properly or not. So checking these things also can help to reduce risk of Server Side Request Forgery

Conclusion :

So, basically SSRF is very high impact vulnerability if exploited properly but if we make every effort and combine most of the mitigation techniques together then we can make it difficult for attacker to get successful exploitation of SSRF vulnerability.

Thanks for your valuable time!

Leave a Reply

Your email address will not be published.