OWASP Top 10 2021 News (III)

After discussing in the first post of the series some details about the new version of OWASP Top 10, and in the second one the new category A08, software and data integrity flaws, in this third and last post we are going to analyze the category A10: Server-Side Request Forgery (SSRF), as well as the possibilities of mitigating these types of vulnerabilities.

A10: (Server-Side Request Forgery, SSRF)

SSRF attacks are possible when an application allows a remote resource to be obtained without validating the URL provided by the user. This type of attack can bypass the protection provided by the firewall, VPN or access controls.

For example, when an application allows you to specify a URL to which the initial request will be redirected, if we do not filter the URL to which it will be redirected, the attacker could take advantage of this to enter a random address.

Attacks could consist of requests such as:

or

So if the redirection URLs are not filtered and the resources are not protected, they would allow the attacker to access them.

One of the causes of these attacks is the application code that allows access from the application to addresses that should not be accessed, so that the attacker can send requests from the application to both internal and external resources and receive the responses.

SSRF attacks are increasing due to cloud services and the progressive increase in architecture complexity.

Mitigation of these attacks can be carried out on several fronts:

• From the network layer.
• From the application layer.
• At the general level.

2.1 Mitigation from the network layer

The following are some ways to mitigate these attacks from the network layer.

• Segmenting networks. Using for example VLANs, to avoid spreading the attack in one part of the network to other parts of it. It would be the same principle used in a ship with compartments; this allows that if a waterway occurs and cannot be bailed out, the water does not invade the other compartments.

Watertight compartments and bulkheads. Source: https://www.fao.org/3/i0625s/i0625s02c.pdf

• Always deny by default. The firewall should block all intranet traffic, letting only explicitly allowed traffic through.
• Log network traffic when a request is accepted or denied. This way we could go to the logs to see what is happening, in an ideal situation, we should also be able to create alerts to warn us of suspicious behavior.

2.2 Mitigation from the application layer

Listed below are some forms of mitigation that can be carried out from the application layer.

• Sanitize and validate user input data, which is mandatory in this and other situations, as it is one of the reasons for injection attacks.
• Use whitelists to allow only the URL, port and destination schemes that we decide will be accessible. Whitelisting allows only what is specified in the whitelist and denies everything else.
• Deshabilitar las redirecciones HTTP si no son estrictamente necesarias, ya que se debe incluir la funcionalidad que realmente se necesite, y el resto de funcionalidad deshabilitarse. Disable HTTP redirects if they are not strictly necessary, since only the functionality that is really needed should be included, and the rest of the functionality should be disabled.
• Avoid using deny lists or regular expressions as they can be avoided and would not be of much use.

2.3 Mitigation at a general level

The following are some of the ways to mitigate these attacks, although now, at a general level.

• Controlling localhost traffic, since its security is usually somewhat neglected, as it is not directly accessible from the LAN or Internet. With this attack we have seen that this must also be taken into account.
• Provide VPN access as far as possible to the users of our organization. This limits the exposure of our services to external networks or the Internet, by granting access only to our users from the local network. In addition, we can more accurately log access to services, and detect suspicious patterns of behavior.
• Verify the response when performing the redirection. We must verify that the response is as expected. For example, if we redirect to a page on the source code repository server, we should check that the page to which we will redirect the request belongs to the server and is not another page.
• Disable unused URI schemes, as in other risks where the recommendation is to disable elements that are not being used or needed. In this risk we should recommend that unused services and ports be restricted, allowing access only to those that are needed or must be accessed, specifying them explicitly with whitelists. For a list of URI schemes, see RFC 3986. Uniform Resource Identifier (URI): Generic Syntax: https://datatracker.ietf.org/doc/html/rfc3986.

A list of examples compiled from the referenced RFC of URIs that we may not need would be:

Note that in addition to the domain, you should also check that the scheme is allowed. For example: https://example.com and ftp://example.com share the example.com domain, but they differ in their scheme, https or ftp respectively.

Thank you very much to all of you.