Written By: Austin Miller
And here we are – the final installment of SecPro’s OWASP Top Ten overview. Having started with the Broken Access Control two months ago, we are ending with Server-Side Request Forgery attacks (SSRFs). And despite this sitting on the bottom rung of the official OWASP Top Ten, the Community poll actually put this at #1! It just goes to show you that even the lower ranking threats on this list are all too capable of destroying businesses with poor cybersecurity practices.
Because SSRFs are generally all very similar in how they are executed, the OWASP team has identified this section as likely not to survive into the next iteration of the OWASP Top Ten. So, before the team behind this series rolls up
What is SSRF?
SSRFs can be kind of complex. They require the adversary to exploit a function in an application where a request can be replaced without the internal servers validating it. If you would like to practice running an SSRF attack, use OWASP’s Webgoat tool to “steal the cheese”! If not, here’s a quick run through:
Find an exposed request
Black hat hacking is a crime – using this methodology against a computer or server that you do not own can lead to serious legal repercussions. All links in the following section are fictional. Any resemblance to real links is coincidental.
When we interact with web services, applications make requests to servers. In a secure application, these requests are sanitized and validated to ensure there are no injection attacks or request forgeries. Sometimes, those defenses aren’t in place.
Let’s say we look at a PDF downloader on an unsecured website. The download link may look like this:
www.website.com/centralserver/resources/document1.pdf
Manipulating the link
An attack can change the URL so that the downloader contacts another repository on /centralserver, such as:
www.website.com/centralserver/admin
Instead of downloading the PDF, now the attack may have access to the central server with admin rights.
Data exfiltration
Obviously, it’s not quite that easy – they would still need to find a way to access the server, but the forgery is complete. At this stage, particularly vulnerable servers could send sensitive files stored in the same place as document1.pdf to the adversary or even allow full remote code execution privileges.
Want to find out more about SSRF attacks? Check out this video guide by hacker Rana Khalil.
Are SSRF attacks common?
It is common to find SSRFs in the banking and finance sectors. Without proper care, these industries are one rogue link away from transferring large amounts of money to somewhere it shouldn’t be. But one of the most (in)famous examples of an SSRF attack came through a hacker finding a weakness in a web application that linked onto AWS.
Paige Thompson, a former AWS employee, found that a web application used by Capital One allowed for an SSRF attack. Launching an attack against the vulnerability, Thompson soon found that she could exfiltrate 100 million records. Among the records were credit card details, 120,000 social security numbers, and 77,000 bank numbers.
When this payload was dumped onto GitHub, it wasn’t long before the authorities were able to track down and arrest Thompson for computer fraud and abuse for an intrusion on stored data.
How can I tell if there are SSRF vulnerabilities in my web application?
Because an SSRF attack requires there to be an SSRF vulnerability in the system, there are few tell-tale signs that your application is at risk. Generally, we find SSRF vulnerabilities in applications that fetch a remote resource without validating the user-input data. In essence, the internal server and the internal server’s firewall are not properly configured.
For a simple checklist, here are the five most common areas you will find an SSRF vulnerability:
- Webhooks are particularly prone to SSRFs as end-users can often insert their own endpoint and hostname.
- PDF generators are prone to injections and CSS url() requests made against internal servers.
- Document parsers can be exploited to expose the way the external resources are referenced.
- Link expansion can be exploited, as showed by Mark Litchfield.
- File downloader replacement can be exposed by sending a different URL to the server – if it starts the download, there is a potential SSRF vulnerability.
For a full breakdown on how to create a practice SSRF-prone server, check out this guide by HackerOne.
How do I stop SSRF attacks?
OWASP breaks down proper defensive action against SSRF attacks into two categories:
- At the Network layer, level 3 in the OSI model
- At the Application layer, level 7 in the OSI model
Network level defenses
Clever data management and effective firewall policies are key to implementing network level SSRF defenses.
- Segmenting remote resource access stops potential SSRF attacks from accessing sensitive data.
- Firewalls should all have deny by default policies.
- Firewall network access control lists (ACLs) should block all incoming internet traffic unless it is essential
Application level defenses
Unlike network level defenses, application level processes should focus on what you are doing with the data.
- All client-supplied input data must be sanitized and validated.
- URL schemas, ports, and destinations must agree with a positive allow list.
- Unprotected, raw responses to clients are highly vulnerable.
- Redirections over HTTP must be disabled.
- Pay special attention to avoid attacks from DNS rebinding and time of check, time of use (TOCTOU) race conditions.
And that’s it! We’ve covered the OWASP Top 10, 2021 edition from AO1: Broken Access Control to A10 in this issue. Hopefully you have all found ways to make your applications more secure and avoid the most common vulnerabilities that software developers and DevSecOps teams face daily. I hope you’ve enjoyed it and learned a few ways to defend your systems!
){kind=link}