API-07 Server Side Request Forgery

Skip to Primary Menu Skip to Utility Menu Skip to Main Content Skip to Footer

Get a Demo

Katie Paxton-Fear

Another new one to the API Top 10, Server Side Request Forgery (SSRF) isn’t actually all that new, shared with the OWASP Top 10 community survey, but while this isn’t an exclusive API security issue it can be very common. SSRF vulnerabilities happen when one server makes a request to another resource without any validation on that request.

Commonly in APIs this is an endpoint which fetches data from another server, such as a storage bucket for storing avatars. Why is this a problem? Well the request comes from the server rather than the user, and servers are commonly placed on corporate networks, meaning that if the user can edit the URL, they can ask it to fetch from internal network resources rather than a remote storage server. As APIs often have more limited validation than traditional web applications you can see why this makes the cut.

Suzy has been running her social network Suzy’s Social on a single server in her home, but storage has gotten expensive as users upload videos, images and avatars so she purchases some storage. Adam, the attacker is casually viewing Suzy’s Social and realises the way the API fetches avatars has changed, curious he tries to upload a new avatar and view the process in real time. He realises the change Suzy has made. Now he supplies a new URL to the avatar change API endpoint, and when he views his profile he realises that the website is loading from that new URL. He tries some other URLs, looking for local files, local web servers and ports, he finds the debug version of the website hosted at 127.0.0.1:8080, a file injection using the file:// URI schema, and he can even pivot to 192.168. and access Suzy’s router and office computer! While Suzy’s firewall was in place to block external traffic, by using the SSRF vulnerability Adam can bypass that external firewall as the server is on the same network and is a local device.

APIs are at their core fundamentally web applications and it’s important to not forget standard web application security, the SSRF flaws tells us why – APIs are unique assets, but a failure to account for basic security flaws can be fatal!

How do we fix these vulnerabilities? We should never allow an endpoint to fetch from user supplied data to external resources without first performing some validation. While we could force the user’s browser to make the request, rather than the server, this can cause other injection type issues such as cross site scripting. By using allowlists to known providers, we can block any access to external resources. We can also isolate web servers from internal networks or use cloud infrastructure but this doesn’t necessarily resolve this flaw.

APIs making external requests aren’t new to API design, but do you know what requests it’s making?