What is Server-Side Request Forgery?
A Server-Side Request Forgery attack or SSRF is an attack where a malicious user could abuse the functionality on a server to read or update internal resources. It is in the same class of vulnerabilities as an RFI (Remote File Inclusion) or LFI (Local File Inclusion). Meaning its’ exploit is very similar and so is the result of a successful exploit.
How is an SSRF carried out?
In a Server-Side Request Forgery attack, an attacker could modify a URL from a Request sent to the server, which the application uses to read data from or post data to. So, when the attacker makes a request, the request is really made by the application server to another server.
Why does an SSRF attack work?
In a secure configuration, typically, an application server should receive input from a Request and process it. If another application or service needs to be invoked (depending on the architecture of the application), the application server should process the request, and fetch or modify information thereafter. However, in a typical SSRF scenario, the application server gets the remote or local resource’s URL from the request, thereby, creating an entry point for the attacker to use the application server to make requests to other servers. Application servers generally have higher privileges over regular users on the application. So, if an application server’s privileges can be used to make requests to other servers, protected resources could be exposed to attackers that other regular users of the application should not have access to.
Let’s look at the following image to better understand how and why an SSRF attack works:
Image Address: https://dpsvdv74uwwos.cloudfront.net/statics/img/blogposts/exploiting_ssrf_vulnerability.png
Image credit: https://www.netsparker.com/blog/web-security/server-side-request-forgery-vulnerability-ssrf/
In the above image the evil hacker does not have direct access to the victim server to request information from. It’s blocked by a firewall. So, even if the hacker has the exact request URL and other parameter values that’s required to make a proper request to the server, it would be blocked by the firewall and thereby dropped.
However, the hacker has access to the web server, and the web server has a trust relationship, i.e., the victim server trusts that all requests coming from the web server are valid, authorized requests and they should be properly executed.
So, the hacker, makes a request to the web server in step 1, which in turn makes a request to the victim server in step 2. The victim server processes the request from the web server and returns a response to the web server in step 3, and the web server displays the response from the victim server back to the hacker in step 4.
Why is Server-Side Request Forgery an Issue?
As mentioned earlier, application servers have privileges that regular users of the application lack. The application servers possess rights to request resources from other remote and local servers. So, even if a regular application user does not have the necessary rights, they could make requests to other servers acting as the application server and retrieve those protected resources. Depending on the kind of request the application server is making to the other server, it may be possible to create, update, or delete data as well. This results in the loss of confidentiality, integrity, and availability of the data, causing a severe impact to the organization.
How to execute an SSRF attack?
Let’s look at a few examples to better understand common entry points to an SSRF attack and how a common attack scenario looks like:
Requesting a Local Resource
In this scenario, there may be protected resources on the application server that a regular user does not have access to due to limitations of the user privilege. However, the application server trusts itself to perform functions for itself. So, if the server itself wants to view the protected resources, it could do so without any restrictions.
Let’s consider an application that lets a shopper view the availability of an item using the following request:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
availabilityQueryApi=http://availability.store.com:8080/item/store/lookup%3Fitem%3D6%26location%3D1
In the front-end request above, it can be seen that the application server is using input from the user to request another server for information on the availability of an item. Once the application server receives the item availability status from the other server, it returns it back to the user.
If the user has malicious intent, they could modify the request specifying a resource that resides on the same server like in the request below:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
availabilityQueryApi=http://localhost/admin
In the example above, it is seen that the malicious user is requesting the admin page from server. Generally, the admin page is restricted to only privileged users of the application. However, the origination of the request for the admin page will be the server itself, therefore, it will be returned in the response even if the user account does not have sufficient privileges to view the admin page, because the server will see that the request is coming from itself.
Requesting a Remote Resource
In this scenario, there may be protected resources on another server that is only accessible by the application server. Therefore, the server holding the protected resources may only trust itself and the application server to serve resources to.
Let’s take the previous example where the front-end request had a backend API URL to fetch item availability information and display it back to the user. If the server with IP address 192.168.0.1 trusts the application server for all requests and renders the responses back to the application server, the attacker could modify the request to contain the URL of a protected resource on 192.168.0.1 and get it back in the response as seen in the request below:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
availabilityQueryApi=http://192.168.0.1/admin
How to protect against an SSRF attack?
There are various methods that attackers may be able to use to bypass blacklist and whitelist URL filtering mechanisms. Therefore, the best option to protect against SSRF attacks is avoiding accepting user input for any function that make requests on behalf of the server.
The School of Information Security is determined to produce quality cyber security experts in the industry with their cutting edge live-online Web Application Penetration Testing training program. As more vulnerabilities arise in the applications such as SSRF, the demand to hire application security experts will continue to rise. The School of Information Security’s job-oriented training program helps individual with the core knowledge along with hands-on labs to be successful in cyber security career.
