Testing for Server-Side Request Forgery
Web applications often interact with internal or external resources. While you may expect that only the intended resource will be handling the data you send, improperly handled data may create a situation where injection attacks are possible. One type of injection attack is called Server-side Request Forgery (SSRF). A successful SSRF attack can grant the attacker access to restricted actions, internal services, or internal files within the application or the organization. In some cases, it can even lead to Remote Code Execution (RCE).
- Identify SSRF injection points.
- Test if the injection points are exploitable.
- Asses the severity of the vulnerability.
How to Test
When testing for SSRF, you attempt to make the targeted server inadvertently load or save content that could be malicious. The most common test is for local and remote file inclusion. There is also another facet to SSRF: a trust relationship that often arises where the application server is able to interact with other back-end systems that are not directly reachable by users. These back-end systems often have non-routable private IP addresses or are restricted to certain hosts. Since they are protected by the network topology, they often lack more sophisticated controls. These internal systems often contain sensitive data or functionality.
Consider the following request:
You can test this request with the following payloads.
Load the Contents of a File
Access a Restricted Page
Use the loopback interface to access content restricted to the host only. This mechanism implies that if you have access to the host, you also have privileges to directly access the
These kind of trust relationships, where requests originating from the local machine are handled differently than ordinary requests, are often what enables SSRF to be a critical vulnerability.
Fetch a Local File
HTTP Methods Used
All of the payloads above can apply to any type of HTTP request, and could also be injected into header and cookie values as well.
One important note on SSRF with POST requests is that the SSRF may also manifest in a blind manner, because the application may not return anything immediately. Instead, the injected data may be used in other functionality such as PDF reports, invoice or order handling, etc., which may be visible to employees or staff but not necessarily to the end user or tester.
In some cases, a server may convert uploaded files to PDF format. Try injecting
<script> elements, or CSS
url() functions pointing to internal services.
<iframe src="file:///etc/passwd" width="400" height="400"> <iframe src="file:///c:/windows/win.ini" width="400" height="400">
Common Filter Bypass
Some applications block references to
127.0.0.1. This can be circumvented by:
- Using alternative IP representation that evaluate to
- Decimal notation:
- Octal notation:
- IP shortening:
- Decimal notation:
- String obfuscation
- Registering your own domain that resolves to
Sometimes the application allows input that matches a certain expression, like a domain. That can be circumvented if the URL schema parser is not properly implemented, resulting in attacks similar to semantic attacks.
- Using the
@character to separate between the userinfo and the host:
- URL fragmentation with the
- URL encoding
- Combinations of all of the above
For additional payloads and bypass techniques, see the references section.
SSRF is known to be one of the hardest attacks to defeat without the use of allow lists that require specific IPs and URLs to be allowed. For more on SSRF prevention, read the Server Side Request Forgery Prevention Cheatsheet.
- swisskyrepo: SSRF Payloads
- Reading Internal Files Using SSRF Vulnerability
- Abusing the AWS Metadata Service Using SSRF Vulnerabilities
- OWASP Server Side Request Forgery Prevention Cheatsheet
- Portswigger: SSRF
- Portswigger: Blind SSRF
- Bugcrowd Webinar: SSRF
- Hackerone Blog: SSRF
- Hacker101: SSRF
- URI Generic Syntax