This is part 1 of 3 in the OWASP Top 10 Series

1. Introduction to Server Side Request Forgery (SSRF)
2. Introduction to Cryptographic Failures
3. The Risks in Vulnerable and Outdated Components

One of the most important accessories for a successful cyber attack is good enough access. In an application where security is decently taken care of, an external user typically would not have enough access to do harm. In such cases, attackers can try a different approach. Instead of trying to gain enough access and play around to get enough permissions, they can try to manipulate an entity of the application that already has enough access and authorization such as a server. 

Server Side Request Forgery (SSRF) is one such attack where an attacker tricks a server to make unintended requests. So how do attackers trick a server? What happens after? We’ll explore more of this in this post. But before that, let’s try and understand server side request forgery more in detail.

What is Server Side Request Forgery?

Modern applications are generally distributed in nature and have started to depend more on cloud services. Although this makes developing, testing, and troubleshooting the application convenient, it increases the complexity of architecture and adds challenges. One of these challenges is to make sure different components of the application have got enough access and permissions to perform their functions smoothly. But when we don’t consider the scope of this access and possible threats, it might cause a server side request forgery vulnerability. 

Source: Vaadata 

Server side request forgery is a web application vulnerability that allows an attacker to send malformed requests to the components of the application or to communicate with an external arbitrary system. 

Typically, the internal components of the application are configured in a way that they’re inaccessible from the outside world. For example, a server behind a firewall or a server that can only be accessed from a bastion host. Therefore, an attacker can abuse an SSRF vulnerability to attack the internal components of the application. 

So, what makes server side request forgery so dangerous that bagged it a spot in Owasp Top 10? 

What is the impact of Server Side Request Forgery?

Some of the common impacts of an SSRF attack are:

• Sensitive Data Exposure or Cryptographic Failures. 
• Arbitrary Code Execution (ACE).
• Inducing non-existing vulnerabilities to exploit later in time. 
• Gaining intelligence on the internal architecture of the application.

And in some cases, an SSRF vulnerability can also lead to an application’s complete takeover. A successful SSRF attack can result in business losses, lawsuits, damage to reputation, etc. That’s how server side request forgery affects businesses. It all depends on how the application is built. To make this easier for you to understand, let’s look into some examples of SSRF attacks. 

Examples of Server Side Request Forgery

What one can do with an SSRF vulnerability depends on the application’s architecture and the attackers’ creativity. However, there are some approaches that are most commonly used by attackers. We’ll cover these common approaches in this section:

• Server SSRF
• Back-End SSRF
• SSRF via File upload

Server SSRF Attacks

The vulnerability server side request forgery (SSRF) already has the term “server” in it. Then what’s with the prefix of another “server”? This is a type of an SSRF attack that represents that the SSRF attack is on the server itself. 

Let’s consider an e-commerce application. The application would generally have 2 kinds of users:

• Customer/Normal user
• Admin

So when a user logs into the application, the user would authenticate using their credentials. And based on that, the server would give them either customer access or admin access. Once the user is authorized, communication happens using HTTP requests. In an ideal world, this setup looks good. But we don’t live in an ideal world.

Let’s look into how this setup can be dangerous if the application was vulnerable to SSRF. 

If a customer looks for a product, let’s say an iPhone, then the application would send a request to get details for that product. The request might look something like

http://myshop.net:8080/getData/id/1234

What you need to observe here is that this request can be manipulated by the attacker. An attacker can modify the request to access the admin page of the application through the loopback interface. 

http://localhost:8080/adminportal

The server would trust the request because it’s coming from itself and the request would go through. And because this attack is on the server itself, it’s called a server SSRF attack. 

Back-End SSRF attacks

The Back-end SSRF attack is similar to server SSRF with the difference that the target component is a back-end system. So instead of sending the request to the same server, the attacker sends the request to another back-end system. 

These back-end systems are mostly accessible only within the application’s network and are cut off from the outside world. And due to this, in some scenarios, the back-end servers are not as secure as the public servers. If we consider the previous example, and say the back-end system with the IP 192.168.1.10 has the admin portal, then the malformed request would be something like this:

http://192.168.1.10/adminportal

This type of SSRF abuses the trust between the internal components of the application. So, when the request to the back-end system comes from a server that it trusts, it processes the request. 

SSRF via File Upload

As the name suggests, this type of SSRF happens via the file upload feature of the vulnerable application. The idea is to embed the malicious code in a file (ex: HTML or SVG), upload the file to the application, and then trick the application into executing the code. 

For example, you can have the following code in a .svg file:

<svg style="width:100%;height:100%;">

xmlns="http://www.w3.org/2000/svg"

xmlns:xlink="http://www.w3.org/1999/xlink">

  <script type="text/javascript">

    // <![CDATA[

      var xmlHttp = new XMLHttpRequest();

      xmlHttp.open( "GET", http://192.168.1.10/adminportal/deleteuser?id=3, false ); 

      xmlHttp.send( null );

      return xmlHttp.responseText;




   // ]]>

  </script>

</svg>

Assuming that the code is valid for the application, when you upload the SVG file and open it, it would make an HTTP request to delete a user with id=3. 

This is how different variants of SSRF attacks can do harm to the application. So far, we’ve looked at SSRF from an attacker’s perspective. Now let’s turn the table and look at it from the defender’s perspective. 

How to Prevent Server Side Request Forgery?

There are various ways to prevent server side request forgery. It’s important that you take all the generic measures but also apply measures specific to your application. 

Whitelisting and DNS Resolution

If you have a predefined list of requests, you can use whitelisting to allow only those requests to execute. If it’s difficult to whitelist the request, then you can use whitelisting for endpoints. For example, allow requests only to the following endpoints from a server:

• orderHistory
• productDetails

You can also use a whitelist for hostnames and IPs that your application needs access to or use an access control list (ACL). Although you can use DNS resolution to verify a domain, it can still be exploited. So, you need to be careful how you implement this. 

Alternatively, you can use blacklisting to block potentially malicious requests. For example, you can blacklist requests to localhost and 127.0.0.1 to avoid server SSRF.

Authentication on Internal Services

As per the architecture, you might have placed the internal systems behind firewalls and added more security to the public server. But since SSRF exploits the trust between the components of the application, it is also important to add security layers between them. This will not only make it difficult for the attacker but also slow down the process and give you enough time to act on it. Therefore, it is recommended to use authentication for communication between internal systems.

Preventative Secure Coding

This is more of a practice that you need to implement as you start building the application. The idea of preventive secure coding will place security measures in various places of the application as and when you develop it. And this will add more resistance to the attacker. 

A common cause for an SSRF attack is fetching links without validating the user-supplied URL. Therefore sanitizing and validating user-controllable data can be one of the first things to take care of as a security measure. 

Penetration Testing

You might have studied all preventive measures available and implemented all of them. But you need to remember that every application is unique. Therefore, even with all those measures, you need penetration testing to have a custom assessment of your application’s security. And this will help you fill in any gaps you might have missed. And if you didn’t find anything from a penetration test, you can take a moment and be proud of what you’ve accomplished. Either way, it’s a win-win situation. 

Conclusion

The hard truth in cybersecurity is that one can never be fully secured. So it’s important to continuously assess and improve security. Server side request forgery is on Owasp’s Top 10. And if something has made it to this list even once, then it’s dangerous enough for you to prioritize and act on it. 

We’ve gone through what SSRF is and looked into some examples of SSRF attacks. The mitigations covered in this post are simple and are the basic preventive measures against SSRF attacks. But that’s just the first step. Attackers are getting creative by the day. And if you want to stay ahead of them, just implementing generic measures is not enough. You need to have regular assessments, penetration testing, and monitoring in place.