Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you haven't received our response, please do the following:
check your Spam/Junk folder and click the
"Not Spam" button for our message.
This way, you won't miss messages from our team in the future.
Server-Side Request Forgery is a security vulnerability that allows an attacker to send requests on behalf of a compromised server.
For example, an SSRF attack can occur if an application uses unverified external data to generate requests. Attackers can induce an application to send malicious requests to resources that are not directly accessible but are available to the server.
Another variant of an SSRF exploit is request masking. An attacker "hides" behind a vulnerable (intermediary) server to make requests to another server (target). In this case, the target server assumes that an intermediary induces all the requests.
It's worth noting that an XXE attack can cause SSRF.
Every year, the severity of SSRF is becoming higher due to several factors. Nowadays, developers are trying to provide users with more convenient functions. That's why, getting a user-provided URL becomes more popular. Cloud services are also developing rapidly. Architectures become more complex. This makes it difficult to create an effective protection against this attack.
In OWASP ASVS 4.0.3, SSRF is associated with 5.2.6 and 12.6.1 positions. In the OWASP Top Ten 2021 list, it belongs to the A10:2021 — Server-Side Request Forgery (SSRF) category. In Common Weakness Enumeration, this vulnerability corresponds to CWE-918.
To better understand SSRF, let's consider the following example:
void ServerSideRequestForgery()
{
var url = Request.QueryString["url"];
WebRequest request = WebRequest.Create(url);
WebResponse response = request.GetResponse();
using (Stream stream = response.GetResponseStream())
{
using (StreamReader reader = new StreamReader(stream))
{
....
}
}
response.Close();
}In the code fragment above, the user creates the URL to request the corresponding resource.
Here's an example of a server request to delete a user:
http://website/admin/delete?username=testSSRF
The server is expected to execute such requests only from itself or from trusted devices. If an attacker tries to send a request to delete a user directly (in the form presented above), the server will not process it.
However, an attacker can form a request in a different way:
http://localhost/admin/delete?username=testSSRF
Based on the passed address, the server addresses the request to itself. In this case, the request will be executed, and the user will be deleted.
Also, to prevent SSRF, you should not use block list validation or regular expressions. Attackers can easily bypass these restrictions. For example, they can use redirection. In this case, an attacker creates an external resource that redirects to another URL as a response. Also, to bypass the restrictions, attackers can use alternative representations:
http://2130706433/ = http://127.0.0.1
http://0x7f000001/ = http://127.0.0.1
An example of SSRF prevention with the help of data verification:
string ServerSideRequestForgery()
{
var url = Request.QueryString["url"];
if (!wList.Contains(url))
return "Forbidden URL";
WebRequest request = WebRequest.Create(url);
....
}In this case, only allowed addresses will receive the request. If such a solution is not suitable for some reason, then you should change the application logic. For example, if an image is required, a developer should request not the URL, but the file itself.
0