If you’ve been around the information security space for a while, it’s likely that you might have heard about Cross-Site Request Forgery. Cross-Site Request Forgery, or CSRF for short, is the silent beast we have covered in one of our previous articles about security on the web; However, some of you might also be aware that CSRF has a brother aside from the aforementioned Cross-site Scripting attack: there’s also a very similar attack differing by one word – we’re talking about Server-side Request Forgery, or SSRF for short.
What is Server-Side Request Forgery?
To put it simply, a SSRF attack is such an attack that lets a nefarious party to abuse functionality existing on the server in order to access or modify assets on that server. It might sound simple, but it differs from Cross-site Request Forgery in a couple of aspects:
- SSRF attacks aren’t limited to a specific user, while CSRF attacks are.
- Also, SSRF attacks might be a little less dangerous than CSRF attacks simply because of the fact that a nefarious party can simply make a server act in malicious ways by sending HTTP requests.
Think of such attacks in the sense of control – if an attacker can control the URL to which an application makes a request, he can forge an attack. In other words, the goal of an attacker in this scenario is to make an application on the server perform requests to a location chosen by the attacker.
A SSRF attack will be successful if the attacker possesses the following information:
- An application that allows data to be manipulated with via URL (think of GET or POST requests that request something from an URL);
- Knowledge that an application reads data from the URL.
The aforementioned two things are everything that’s necessary to mount such an attack because of its nature – if the server-side code reads data from the URL that has been manipulated, the attack will be successful. Hence the name – Server-side Request Forgery.
The consequences of such an attack can be various depending on the server that is being attacked – cybercriminals can leak data, they might be able to perform some reconnaissance on the server in question, or combine the vulnerability with another exploit – say, Remote Code Execution (RCE) or the like.
Stopping SSRF
As bad as SSRF might sound, though, there are ways to stop any attack – and stopping SSRF might be easier to accomplish than we thought. Here are a couple of ways to counter such an attack:
- Enforce application-level controls – either use a Web Application Firewall (WAF), whitelist some commands and block all others, or make a blacklist of some of the possible commands related to SSRF.
- Avoid sending (displaying) “raw” responses – even if an application is vulnerable to SSRF, a raw response sent by the server could indicate something to an attacker. While such a way is certainly not the best to protect against attacks like SSRF and the like, it will become an additional barrier of entry to any potential attacker.
- Last but not least, consider disallowing input via URL – if possible, avoid importing anything from a URL from both POST and GET requests. If you must do that, consider employing a whitelist of allowed values. That should do the trick!
Protecting Yourself From Other Threats
While protecting your web applications against SSRF might sound like a simple task to do, you have more things to worry about – one of them being related to the protection of your team members and the staff of your organization.
No web application firewalls will save you from human error – we can tell you this, though: a single search using our search engine might reveal more about the dark future that might await your accounts on the web: run a search and it will tell you whether you’re at risk of identity theft or not, consider employing the API capabilities to protect your team from identity theft at work, and until next time.
Summary
While Server-side Request Forgery, or SSRF for short, might be a frightening beast for some, it’s really not that difficult to deal with. Having a couple of tricks up your sleeve will help – a couple of basic measures is usually everything that’s required. If you’ve enjoyed reading this article, consider reading other articles such as the one about CSRF, educate yourself on other matters such as phishing, make sure to employ defense-in-depth principles in order to protect against SSRF and other prominent threats, and until next time!