Summer’s over — what’s your move? Join Pro for 50% off using code [MAKEITHAPPEN](https://www.codecademy.com/checkout?periods=year&plan_id=proGoldAnnualV2&discountCode=MAKEITHAPPEN)


This lesson will explore a small application demonstrating the danger of Server-Side Requests Forgery.



Identify and Prevent Server-Side Request Forgery

In the last example, we saw how we could access a "protected" endpoint by exploiting a server-side request forgery (SSRF). Let's look at a safer app version with the SSRF vulnerability removed. While the `/admin` endpoint still uses the localhost IP for access control, by removing the SSRF we reduce the overall risk of authorized users accessing the protected endpoint. 

Looking back at the `/ssrf` endpoint, we see several new lines of code added to the method call. Below the `url` parameter component, we now have an array called `safe_host`. This array contains an entry for a predetermined host, which we have deemed safe. We also have a `safe_content_type` parameter which defines a list of content types we have chosen to allow in the request responses. From here, we can use these features, in this case, just the `safe_host` list, to determine if a requested URL is allowed. 

By implementing an allow list, we can help ensure that the requests our server sends do not go to unexpected and potentially dangerous places, such as the `/admin` endpoint. It is worth noting here, however, that this safety measure may not be enough in some situations. For example, if the application was set to follow redirects, and an open redirect vulnerability was uncovered in the "safe" host, it may still be possible to make arbitrary requests to a dangerous location!

Overall, SSRF is an incredibly dangerous vulnerability, which generally requires a layered approach for protection. When securing your application against SSRF, we should consider the following solutions:

- Apply an allow list to restrict arbitrary requests.
- Ensure "protected" assets have robust access controls spanning past just IPs.

Server-Side Request Forgery Patched

A microscope scanning or searching for vulnerabilities on a computer.

Modern applications rarely exist as their own unit in today's connected world. Instead, a single application may be compromised of multiple services, expanding across different networks and machines. Large databases generally operate on their own systems, while the application logic happens on another. Now, with the widespread adoption of cloud services, certain components may be operated not only on different networks and machines but by entirely independent organizations. 

Given this, it is not uncommon for applications to offer capabilities that allow them to generate requests and retrieve data from separate systems. While this operation can be used to access and initiate complex processes on a cloud service provider, it can also provide users with basic features designed to improve the overall application experience. 

Think, for example, a profile picture. We could ask users to download a picture they like and upload it to our application. However, if it's already on the web, why not just let them give us a URL? With careful tuning, we can create an easy-to-use feature to streamline user customization!

However, as with everything application-wise, we need to be conscious of the security of such functions. What happens if a user makes a request to a file that isn't a picture? What happens if they enter a URL designed to access a restricted resource such as an administrative panel? 

If we're not careful, we can easily introduce a server-side request forgery (SSRF) vulnerability within our application. SSRF is an incredibly serious vulnerability that occurs when an attacker can force a server-side application to make arbitrary requests on our behalf. Depending on how an application is configured, the impacts can range from wasted bandwidth to a full system compromise!

In the coming examples, we'll see the potential impact of such issues and several basic solutions we can use to prevent this vulnerability within our software.

Introduction

Let's look at an application designed to illustrate the potential issues associated with SSRF. This application contains three endpoints: `/`, `/admin`, `/ssrf`.

The `/` endpoint provides users with a simple form containing only a button. When the button is clicked, a *GET* request is sent to `/admin`, the other endpoint. This endpoint accepts a *GET* parameter named 'url' and sends a HTTP request to the provided URL. In the previous form, found at `/`, the 'url' parameter is set to a site that returns the current time. 

The `/ssrf` endpoint is designed only to be accessible from the *localhost (127.0.0.1)*. While not as common as it used to be, this was a standard way to "secure" an endpoint in the past. The idea behind restricting access to *127.0.0.1* is that it would only be accessible to a user with access to the server's operating system. However, as we'll soon see, this method should never be trusted.

If we look at the code for the `/ssrf` endpoint, we can see several interesting components:

1. The "url" parameter is sent directly to the `requests.get()` resulting in `requests.get(url)`. Leveraging this, we can force the server to send HTTP *GET* requests to arbitrary locations by simply changing the "url" parameter! This, by definition, is a perfect example of an SSRF!

2. Because we can send an HTTP request from the scope of the application, we can access the `/admin` endpoint!

Server-Side Request Forgery Vulnerability

Through our past exercises, we've been introduced to the basics of SSRF. In recent years, this vulnerability has increased in severity and notoriety, even gaining its own place in the 2021 OWASP Top Ten!

While there may be many reasons to provide users with a means to send requests from the server, these instances must be carefully controlled. When sending requests, the following should be considered:

- Apply an allow list to restrict arbitrary requests.
- Ensure "protected" assets have robust access controls spanning past just IPs.
- Apply an allow list to restrict requests and their responses based on content types.
- Avoid trusting user input when possible. 

A microscope scanning or searching for vulnerabilities on a computer.

