Welcome to the 8th post in our weekly series on the new 2023 OWASP API Security Top-10 list, with a particular focus on security practitioners. This post will focus on API7:2023 Server Side Request Forgery (SSRF).
In this series we are taking an in-depth look at each category – the details, the impact and what you can do about it. To see previous posts you might have missed, click here.
An API that fetches a remote resource, such as URL, without sufficient controls can be made to fetch a different resource by an attacker.
The Internet is full of resources! So it’s no surprise that applications aren’t monolithic repositories of every piece of data they need to run. When an application needs something from another location, it might fetch it with a URL or some other kind of resource locator. When an attacker can manipulate that resource locator, and the API blindly follows the manipulated instructions, you have Server Side Request Forgery (SSRF). The manipulated resource could be something like an external, malicious file, or an internal file containing sensitive data.
The proliferation of cloud service providers has actually increased the popularity of SSRF attacks. Standardization of infrastructure and services means that an attacker is more easily able to guess at resources that might be available in a given environment.
It’s important to think of SSRF attacks in terms of repeated attempts or sequences. At best (for the attacker) SSRF leads directly to an objective, but more often it’s simply a means of accessing resources that aren’t otherwise available. Secondary attacks or more information might be necessary to actually reach an objective.
For example, SSRF can be used as a port scanning tool where an attacker can repeatedly try requests to different ports and judge whether they’re open or not based on the timing of responses. Alternatively, the internal resource to which the attacker now has access, in this case another application, may be vulnerable, and the next step is to exploit that vulnerability.
Regardless of the details of the specific attack, the key is to understand that SSRF is about redirecting a request from one resource to another.
We’ve noted some of the possible impacts above, but let’s enumerate a few more.
It’s ideal if you can apply restrictions directly to the resource fetching mechanism in the application. If it’s designed to retrieve only external resources, then limit it to only external access. If it’s designed to retrieve images, then validate that the requested resource is really an image. Basic input sanitization goes a long way here.
If the SSRF vulnerability is in code you don’t control or can’t fix immediately, then you can apply similar controls at the network layer to prevent the most egregious examples. If you can apply controls at the application layer, or employ a tool that specifically blocks SSRF attacks, then that’s a great strategy.
Wallarm detects and blocks SSRF attacks. Wallarm’s inline nodes analyze traffic, detect SSRF attacks and block them based on customer configuration. For Server Side Request Forgery, Wallarm offers a simple and effective solution.
Come back next week as we dig into the details of another category of the new 2023 OWASP Top-10 API Security Risks list – or click here to see previous posts you might have missed.
In the meantime, here are some other resources which might help on your journey to end-to-end API security:
Wallarm End-to-End API Security solution provides comprehensive protection against the OWASP API Security Top-10 threats. And in 2023, we’ve made it even easier for you!
The Wallarm 2023 OWASP API Security Top-10 Dashboard provides you with complete visibility into the security state of your APIs, easy identification of your most critical security risks, and ability to immediately apply protective measures.
If you are interested in learning more about how we can help you protect your APIs, please schedule a demo with one of our security experts today!