PortSwigger Lab Write-up: SSRF with Blacklist-Based Input Filter

Lab Overview

• Lab name: SSRF with blacklist-based input filter
• Difficulty: Practitioner
• Category: Server-side request forgery (SSRF)

What the lab asks:

This lab has a stock check feature which fetches data from an internal system. To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

Where the flaw is:

As the lab title indicates, the lab may have an ssrf flaw with the blacklist input filter mechanism. The developer thinks that making a blacklist of common ssrf hostnames like 'localhost' and '127.0.0.1', or sensitive URLs like '/admin', can protect the app from ssrf attacks, but that's not true — there are other methods to trick the mechanism.

How I exploited it

To make things clear, I made a checklist of methods that I could use to spoof the backend blacklist mechanism, in order of simplicity. The list is this:

1 .use an alternative representation of the loopback IP address (127.0.0.1), like 2130706433, 017700000001, 127.1 2.obfuscate blocked strings, i.e. localhost and 127.0.0.1, using URL encoding or case variation

#Proof

To make sure the backend mechanism blocked the hostnames and sensitive URL, I intercepted the stock check request on Burp Proxy and sent the request to Burp Repeater, and I changed the URL to http://localhost/admin. As I expected, I got a response error; it said 'External stock check blocked'.

#Attempt 1: So, based on the checklist, I changed the hostname to alternate IP representations combined with the /admin page.

But I got the same error as the proof request, so to isolate which part was blocked, I sent the alternate IPs without the /admin page, and it wasn't blocked this time. This indicates the IPs are not blocked, but the /admin is, so I checked off this item on the list and moved to the next one.

#Attempt 2: In the second attempt, I needed to change the blocked strings using URL encoding and case variation, so I started with the simpler option and changed the case of the string admin to /ADMIN, trying it across all the alternate IPs. This time I got a 200 response with the admin page. This means I bypassed the blacklist mechanism successfully. The reason I bypassed it is because the blacklist only matched the lowercase string 'admin', so changing the case of the path avoided matching the blocklist entirely.

#Final Exploitation: Because I could access the admin page, I sent a request to delete the user carlos using this payload: http://127.1/ADMIN/delete?username=carlos