SSRF attacks are used to target internal systems behind a firewall that are not accessible from the external network.
What is SSRF?
Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing
A web application may have the functionality to import data from a URL, and import it into its page. Attackers could potentially change the request to and manipulate the URL. The server then gets the request, the code on the server side reads the new URL and tries to read data to it. By selecting target URLs the attacker might be able to read data form internal services such as:
- Cloud server meta-data (AWS, Google Cloud, …)
- Databases such as MongoDB, NoSQL have a HTTP interface
- files (internal files could be read with
SSRF be like:
SSRF can lead to lots of other vulnerabilities:
- It often results in unauthorized actions or access to internal data. Either data in the web application or in other back-end systems.
Example – Use URL schemes to read hidden data (
- Reflected XSS can be achieved.
Example – Fetch a file from an external site which hosts a malicious payload.
- In some cases it may even lead to Remote Code Execution.
Example – After scanning the internal structure by using a SSRF you find an outdated system with a known exploit.
Common SSRF Types
With basic SSRF an attacker will request a manipulated URL and the server will send the response back to the attacker.
For example look at a shopping application that lets the user see the amount of available items left in the store. The server gets its data from an API using the id from a specific product. A request from this application looks like the following.
POST /items/stock HTTP/1.13D4
The server requests the amount of items left in the stock from a specific URL and returns it to the user. An attacker can abuse this by modifying the URL to an internal address:
POST /items/stock HTTP/1.1
Blind SSRF is a bit harder to detect. We use the term blind SSRF when an attacker provides a URL to the application but the response is not reflected on the front-end. To verify blind SSRF attacks an attacker must use DNSBin, Burp Collaborator or a similar tool.
The impact of blind SSRF is usually less severe because no sensitive data can be exposed this way.
Similar to blind SSRF, semi-blind SSRF does not show a response to the attacker. However some data or error messages is returned, which is enough to confirm that the application is vulnerable to SSRF.
Portswigger has a great course on SSRF to learn about this type of vulnerability or to test your skills.
How To Prevent SSRF?
There is no surefire way to protect against SSRF. The best approach depends on the type of the application. We listed some of them.
- Whitelist values and IP addresses that your application need to access.
- Disable unused URL schemes (ex:
- Use authentication on internal services
Still not enough?