SSRF on an's security blog

Blind SSRF with Shellshock exploitation | Expert

Wed, 22 Jul 2026 13:59:16 +0800

The lab’s problem statement hints that the site fetches whatever inside the Referer header as analytics whenever a product page is loaded. But will it accept arbitrary domains? Let’s try spoofing the Referer header to one of our Burp Collaborator subdomains and see what’s up: Interestingly, the server approves this request and makes two DNS callbacks as well as one HTTP callback to our Collaborator subdomain! Notice that in one of the HTTP callback, notice that User-Agent is also included. This will be our entry point.

SSRF with filter bypass via open redirection vulnerability | Practitioner

Wed, 22 Jul 2026 09:26:16 +0800

This lab has a stock check feature which interestingly fetches data from an internal system, here is an example of an intercepted stock check request:

Let’s try inserting something arbitrary into the stockApi param to see whether it still honors our request or not: Looks like the filter is a lot more rigorous this time, in fact if it doesn’t start with /product, the server will block our request. Seems like they only allow the stock checker to access the local application only, so maybe we can look elsewhere for an open redirection vulnerability.

SSRF with blacklist-based input filter | Expert

Tue, 21 Jul 2026 16:42:16 +0800

Similar to this problem, there is an SSRF vulnerability in the stock check feature, and our desired endpoint is http://localhost/admin.

Let’s try inserting some arbitrary stuff (yes literally) inside stockApi param to see what’s up:

Interesting. Rather than a blacklist, this app utilise a whitelist that only accepts stock.weliketoshop.net. Otherwise, the request is dropped. This seems impenetrable on paper, but not so in practice.

I’ve tried all kinds of bypass I could think of, like:

SSRF with blacklist-based input filter | Practitioner

Tue, 21 Jul 2026 14:51:16 +0800

This lab has a stock check feature which fetches data from an internal system, below is how the intercepted request looks like:

The lab hints that there is an admin interface at http://localhost/admin, and that there are two anti-SSRF defenses in place which we must bypass. And indeed there is a filter in use, straight up requesting for localhost/admin will result in the request being blocked. This is also the case for only http://localhost: