Welcome SSRF! Take a Look at the New Member of OWASP Top 10!
This blog post was published on PurpleBox website on Oct 13th, 2021.
What is SSRF?
Server-Side Request Forgery (SSRF) attack is a type of attack where the attacker can abuse functionality on the server to read or update internal resources.
In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization’s infrastructure and read server configuration such as AWS metadata, connect to internal services like HTTP-enabled databases or perform POST requests towards internal services that are not intended to be exposed. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.
New Member of the OWASP Top 10 Family
As most of you know, OWASP updated the 10 most important security vulnerabilities recently. In the new list, there are some major and minor changes. The new A10 element of the OWASP Top 10–2021 list is SSRF.
The data reveals a low incidence rate and above-average testing coverage, as well as above-average Exploit and Impact potential ratings. SSRF represents the scenario where the security community members are informing OWASP that this is important, even though it’s not illustrated in the data at this time.
Types of SSRF
Based on how the victim server responds to the request, SSRF can be divided into two categories as Basic SSRF and Blind SSRF:
1. Basic SSRF
This is the type of SSRF in which the victim server returns data to the hacker. When they perform an SSRF attack, a hacker is sending a request to a victim server. Basic SSRF is when the victim server sends back some data after the crafted request is made. A hacker would use Basic SSRF when they want to get data from the server or want to access unauthorized features.
2. Blind SSRF
As the name indicates, in this type of SSRF, hackers don’t get data back from the server. You see this commonly when the request is just to trigger some action on the victim server without returning anything back to the requesting server. Hackers use this type of SSRF when they want to make some changes using the victim server because they don’t need to see results for the activity.
SSRF Impact
If the user-supplied URL is processed and the back-end response is not sanitized, then the attack can lead to several impacts like:
- Port scanning: A user can scan the port of a particular website through the vulnerable web application which is processing the user’s URL.
- Fingerprinting intranet.
- Attacking internal or external web applications.
- Reading local web server files using the file:/// protocol handler.
- In some cases, a successful SSRF attack can even lead to Remote Code Execution (RCE).
Internal Recon
To decrease the attack surface from external networks, it’s a common security practice to minimize the number of public servers. All the rest of the servers are for internal communication. Hackers can use SSRF to learn about the internal network by running scans. This information would be helpful after a hacker gets unauthorized access to the server to attack other servers in the network.
Denial-of-Service (DoS) Attack
The number of requests coming to the internal servers is usually less than the traffic to public servers. Hence, they’re configured to have less bandwidth. Hackers can use SSRF to send multiple requests to internal servers to eat up their bandwidth, resulting in a DoS attack.
Apart from these common attacks, hackers can use SSRF to execute unauthorized or malicious actions, plant malware, etc. The more we know about such risks, the scarier it gets.
Data Exposure
Hackers use SSRF to query internal services that can only be accessed through trusted servers. If the server is in such isolation, it’s needless to say that it contains something valuable. You would also see bastion hosts in the network to add an extra layer of protection. Hackers can use SSRF to bypass such restrictions and gain access to sensitive information.
Remote Code Execution (RCE)
Some modern services are meant to be completely interfaced with using HTTP queries. Unrestricted control of the URL can thus let the hacker manipulate such services and lead to anything, up to and including remote code execution on the underlying server (Redis is one of such famous examples).
How to Prevent an SSRF Attack?
- You generally use HTTPS, or occasionally HTTP, requests to servers. So, if you know that only these protocols are used, block requests with ftp://, gopher:// because we know this isn’t supposed to happen. You can also block files :// to prevent attackers from fetching files. This is like allow listing but focuses on the protocols used.
- Use a whitelist of approved domains and protocols through which remote resources can be acquired by the webserver.
- User input should always be sanitized or validated.
- One must verify that the server response received is as planned to avoid response data leakage to an attacker. The raw response body of the request sent by the server should not be delivered to the client under any circumstances.
If you want to read more on this topic, feel free to check out the PurpleBox Blog Section.
