Pour obtenir une clé
d'essai remplissez le formulaire ci-dessous
Demandez des tariffs
Nouvelle licence
Renouvellement de licence
--Sélectionnez la devise--
USD
EUR
RUB
* En cliquant sur ce bouton, vous acceptez notre politique de confidentialité

Free PVS-Studio license for Microsoft MVP specialists
To get the licence for your open-source project, please fill out this form
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

I am interested to try it on the platforms:
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

Votre message a été envoyé.

Nous vous répondrons à


Si vous n'avez toujours pas reçu de réponse, vérifiez votre dossier
Spam/Junk et cliquez sur le bouton "Not Spam".
De cette façon, vous ne manquerez la réponse de notre équipe.

>
>
>
Server-Side Request Forgery (SSRF)

Server-Side Request Forgery (SSRF)

17 Fév 2022

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.

An example of vulnerability

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.

Preventing SSRF

At the server-level configuration

  • Divide the network into segments and restrict access to resources outside of them to reduce the impact of SSRF.
  • Ensure "default deny" in the firewall policy to filter traffic.

At the code level

  • Input validation of data supplied by a user.
  • Use the URL schemas, port, and destination with allow list validation.

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.

Additional links

Comments (0)

Next comments
Unicorn with delicious cookie
Nous utilisons des cookies pour améliorer votre expérience de navigation. En savoir plus
Accepter