Top 25 Server-Side Request Forgery (SSRF) Bug Bounty Reports

(Photo by Taylor Vick on Unsplash)

In this article, we will discuss the Server-Side Request Forgery (SSRF) vulnerability, and present 25 disclosed reports based on this flaw.

What is Server-Side Request Forgery?

SSRF is when you, as an attacker, successfully make the application triggering arbitrary requests.

Server-Side Request Forgery (SSRF) is basically correlated with other vulnerabilities a lot of times, for example:

XXE with SSRF:

<?xml version="1.0"?>
<!DOCTYPE foo [  
<!ELEMENT foo (#ANY)>
<!ENTITY xxe SYSTEM "http://localhost">]><foo>&xxe;</foo>

Host Header Injection with SSRF:

GET / HTTP/1.1
Host: localhost

HTML Injection with SSRF:

<iframe src=http://localhost></iframe

ImageMagick SSRF in HLS Processing:

#EXTM3U
#EXT-X-MEDIA-SEQUENCE: 0
#EXTINF:10.0,
http://localhost
#EXT-X-ENDLIST

Why is that dangerous?

Let’s assume you are hosting an application on port 80/443 externally, and the administrative panel is being hosted on port 8008 internally. Through SSRF, you can send arbitrary requests to the administrative panel hosted internally

Different Types of Server-Side Request Forgery

There are mainly 3 different types of Server-Side Request Forgery (SSRF) that you must be aware of:

• Normal Server-Side Request Forgery (SSRF): You can see the response of the SSRF request in your browser/interceptor.
• Blind Server-Side Request Forgery (SSRF): You cannot see the response of the SSRF request directly as in a normal SSRF, but you will be able to execute actions blindly. In order to validate a blind SSRF, it would be recommended to set up a listener and firstly send the SSRF payload as your listener address, and check if it catches something.
• Time-based Server-Side Request Forgery (SSRF): The application will respond with an observable discrepancy within response time for requests going to existing or not existing internal resources.