In theory, SSRF is a really simple vulnerability class – you can make requests to arbitrary locations. In practice, however, it’s often more complex.

Where to look for SSRFs?

What parameters are most likely to be vulnerable?

Do we actually need all those complex payloads with octal encoding or unicode characters?

I wanted to know the answers to that questions. Hence, I extracted 361 SSRF reports from the web, filtered them out and categorised them to learn how people are actually making money with SSRFs.

Here’s the table of contents of what I ended up with:

1. Case study methodology
2. What functionalities are vulnerable to SSRFs?
3. Vulnerable parameters
4. Which payloads actually work?
5. How are people showing the impact of SSRFs?
6. Conclusions – how to look for SSRFs today?
7. The database with 315 reports

While most of this article is for BBRE Premium subscribers, behind the paywall, I also included the steps I took to create this article. Thus, if you can’t or don’t want to spend $10 for monthly access or $99 for yearly access to BBRE Premium, feel free to spend the time yourself and repeat the study.

Case study methodology

The study was split into 3 phases: gathering the reports, labelling them and the analysis.

Gathering results

I mainly used two sources for gathering the reports. First, I scraped data from Pentester Land’s list of writeups and then, from Googling SSRF reports on HackerOne.

Next, I imported them all to my Notion where I fixed the data. Some rows with “&” were handled incorrectly, some bounties were in different currencies and there were a few other similar problems that I had to repair.

Also, I had to filter results from Pentester Land by reports with SSRFs.

This left me with 361 records. I narrowed my study to only those with a bounty. This left me with about 160 reports.

Labelling

Then, I started labelling every single report. I had to open it, read it and mark the data that I wanted to extract.

Namely:

• the vulnerable functionality
• the vulnerable parameter name
• the address bypass method used
• if the SSRF allowed reading responses or not
• the impact

For all of these, I created labels in the Notion database. In the beginning, I was creating very detailed labels but the deeper I got, the better I knew which of them made sense, which were too specific and which too general.

Also, while browsing reports I found out that some of them were only partially disclosed. I tried to extract some information from the report summary but it wasn’t always possible. Moreover, I ignored any reports that weren’t bugs in web applications and a few false positives.

This left me with 124 reports.

Analysis

It was really challenging to maintain the detail level but at the same time create general labels that are actually useful. After the first round of labelling, I revisited labels that had few results and aggregated some of them into more general categories.

Then, I exported results to a Google Sheet to create charts. Let’s get to the actual analysis.

What functionalities are vulnerable to SSRFs?

The first label was the functionality. The question I wanted to answer was simple – where are we most likely to find SSRFs?

App-specific/unknown, 34 reports

These are functionalities that were very specific to the app or the functionality wasn’t mentioned in the report.

Import by URL, 22 reports

The most common functionality vulnerable to SSRFs is importing resources from URLs. In many cases these were images. It shouldn’t be a surprise – I think most of us check for SSRFs when we see this functionality.

Out of these 22, only 7 gave the attacker full-read of the response.

File upload, 17 reports

File uploads were the second most popular. Out of these 17 reports, 7 were XXEs and 6 ffmpeg CVEs. Other ones included processing files like SVGs, PDFs or Office documents.

Headless browser / HTML rendering, 9 reports

Out of 9 reports affecting headless browsers, 7 were full-read SSRFs. It means that if you find an SSRF in a functionality that renders an HTML on the backend, usually for the purpose of PDF or image generation, you will get a good bounty.

Webhooks / checking server status, 8 reports

These functionalities are also quite obvious places to look for SSRFs. Out of them, the highest bounty was $31,337 for an SSRF that I covered on my channel: $31,337 Google Cloud blind SSRF + HANDS-ON labs

Proxy, 8 reports

Another popular functionality vulnerable to SSRFs was proxying – there were 8 reports like this. Over half of them used the url parameter.

Security mechanism / library bug, 7 reports

This group includes bugs in libraries and security mechanisms rather than specific applications. These 7 include my report to Stripe about smokescreen and two reports from other hunters with bypasses for the same functionality.

File storage integration, 7 reports

These bugs were in integrations with services like Google Drive or Amazon S3. The one with the highest bounty was reported last year to Dropbox and I also covered it on my channel: An overlooked parameter leads to a critical SSRF in Dropbox bug bounty program

Sentry integration, 4 reports

There were as many as 4 reports about an SSRF in Sentry integration. I was surprised because I don’t know exactly how this attack works. However, these were reported in 2018 and 2019 so I suppose they no longer work but maybe it’s worth trying to find something similar in 2022.

Routing bug, 3 reports

This group includes bugs where the application took the path parameter from the user and made a request on the backend using that input. It’s sometimes referred to as secondary context path traversal but in this case, hunters were able to go one step further and get SSRFs.

Host header, 2 reports

There were two reports where the application made the request using the host header. Both of them were blind and reported in 2018.

Email configuration, 2 reports

There were also two reports where the hunter could configure email domains and use that to get blind SSRFs.

First request line, 1 report

Finally, there was 1 report about an SSRF using the first request line. Normally, I tried to exclude or aggregate functionalities with only 1 report but I left this one because:

• the bounty was $8,600
• I wrote about why this works in the previous issue of BBRE Premium: RFC-induced SSRF

Did you enjoy this? It was only 1/3 of the whole case study!

The rest of the case study:
3. Vulnerable parameters
4. Which payloads actually work?
5. How are people showing the impact of SSRFs?
6. Conclusions – how to look for SSRFs today?
7. The database with 315 reports

Is only available for BBRE Premium members. You can join BBRE Premium here:

:::: JOIN BBRE PREMIUM ::::