SSRF(Server-Side Request Forgery)

Hi, I’m gopi mukka I work on a variety of security topics, including Application Security, Cloud Security, and DevSecOps. Additionally, I enjoy participating in bug bounty programs as a way to stay sharp and learn about new vulnerabilities.

In the world of web application security, one vulnerability that can often be overlooked is Server-Side Request Forgery (SSRF). This vulnerability occurs when an attacker is able to manipulate a web application into making requests on their behalf, potentially allowing them to access sensitive data or services that should be restricted. In this article, we’ll take a closer look at what SSRF is, how it works, and some common techniques for finding it in web applications.

Methodology:

If you want to check video tutorial of this, you check that here…

Step 1: Subdomain Enumeration

The first step in finding SSRF vulnerabilities is to perform subdomain enumeration on the target web application. This involves identifying all the subdomains associated with the application, which can help in discovering hidden attack surfaces and potential vulnerabilities.

There are a variety of tools and techniques that can be used for subdomain enumeration, including:

Once you have a list of subdomains associated with the web application, you can start to look for potential SSRF vulnerabilities on each of them.

Step 2: Find Live Domains

Once you have a list of subdomains associated with the web application, the next step is to identify which ones are actually live and responsive. This can be done using tools like HTTPX, which can quickly test a large number of domains for responsiveness and HTTP status codes.

To use HTTPX, simply pass it a list of domains to test and it will return a list of responsive domains along with their HTTP status codes. You can then filter out any domains that return error codes or are not responsive, leaving you with a list of live domains that you can test for potential SSRF vulnerabilities.

catall-domains.txt | httpx > all-live.txt

Step 3: Identify All URLs

Once you have a list of live domains associated with the web application, the next step is to identify all the URLs associated with each of them. This can be done using tools like gauplus, which can crawl a website and identify all the URLs associated with it.

To find all the urls associated with the domains, perform this command.

catall-live.txt | gauplus -subs -b png,jpg,gif,jpeg,swf,woff,gif,svg -o allUrls.txt

Step 4: Injection Burp Collaborator URL in Parameters

Once you have a list of all the URLs associated with the live domains, the next step is to identify any parameters in the URLs that may be vulnerable to SSRF attacks. One way to do this is to grep for URLs that contain = in them, as this is often an indication of a parameter.

And, after finding all the URLs with parameter we need to replace them with burp collaborator url with the help qsreplace tool.

So the whole command will look like.

catallUrls.txt | grep “=”| qsreplace http://troupga5ke78yjdu4hv12s1v2m8dw3ks.oastify.com > ssrf.txt

Now in the file ssrf.txt we have all the urls with parameter replaced by burp collaborator link.

Step 5: Test for SSRF Vulnerabilities

Once you have injected a Burp Collaborator URL into the parameters of the URLs, the next step is to test each of them for potential SSRF vulnerabilities. One way to do this is to make a request to each of the URLs with follow redirects enabled, using a tool like httpx.

catssrf.txt | httpx -fr

If any url vulnerable to SSRF will be show in burp collaborator.

Step 6: How to check which URL is vulnerable

Once you confirmed that ssrf.txt file contains a URL which is vulnerable to SSRF.

Divide the File in multiple files with the following command

split-l 10 ssrf.txt output_file_prefix

The above command going to create 10 different file.

Clear the Burp Collaborator first.

Check each file with the same command mentioned in step 5.

If any interaction shown check each URL manually. (If this file is big, again split it)

That’s all. You get your SSRF vulnerable URL.