SSRF stands for Server Side Request Forgery. It is a type of web application vulnerability that allows an attacker to send a crafted request from the vulnerable server to other internal or external systems. It’s a server side attack that leads to sensitive information disclosure from the back-end server of the application. SSRF attacks can result in the disclosure of sensitive information, data tampering, or even remote code execution on the vulnerable server.
The vulnerability arises when an application takes user-controlled input, such as a URL, and uses it to make a request to another server without properly validating or sanitizing the input. An attacker can exploit this by crafting a malicious request that targets internal or external systems that the vulnerable server has access to, which could include sensitive resources such as databases, APIs, or internal networks.
To prevent SSRF attacks, developers should ensure that all user input is properly validated and sanitized before being used in requests to other systems. Additionally, network-level protections such as firewalls and access controls can be put in place to limit the exposure of sensitive resources to potential attackers.
How to identify SSRF possibility
Identifying SSRF vulnerability involves looking for ways an attacker can influence the URLs the application is accessing or the parameters being sent to the application.
Input Validation: Look for any input validation or sanitization issues in the application. If the application fails to properly validate user input, it may be possible to inject malicious URLs or parameters.
External Hostnames: Look for any instances where the application is accessing external hostnames. If the application allows users to specify the hostname or IP address of the external resource being accessed, it may be vulnerable to SSRF.
DNS Resolution: Look for any instances where the application is performing DNS resolution on user-supplied inputs. If the application performs DNS resolution on understood user inputs, an attacker could cause the application to resolve a malicious domain name.
HTTP Requests: Look for any instances where the application is sending HTTP requests based on user-supplied inputs. If the application sends HTTP requests based on user inputs, an attacker could manipulate the requests to send arbitrary requests to internal or external resources.
URL Redirections: Look for any instances where the application is redirecting the user to a different URL. If the application allows user-controlled data to influence the destination URL, an attacker could redirect the user to a malicious URL.
Bypassing Network Access Controls: Look for any instances where the application is bypassing network access controls to access internal resources. If the application does not properly enforce network access controls, an attacker could exploit this to access internal resources.
These are some ways to identify the possibility of SSRF vulnerability in a web application. It’s important to note that a thorough security review should be conducted to identify all possible vulnerabilities and attack vectors.
Example
SSRF lab in PortSwigger
It’s a shopping website, You see that there’s a product the description of the product and then there is a check stock feature. That allows you to check if this product is in stock so let’s click on that and again should be intercepted and burped and send this to repeater.
Over there that in the stock track functionality there is a parameter called stockApi. That is send and it looks like it’s a URL. It is a URL encoded. Select the URL and ctrl+shift+u to decode it.
And look at the URL
http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=1
It’s running on port 8080.
Path to the stock check feature is /product/stock/check and product.
So anytime you see a URL in the application you definitely need to test for SSRF.
The next thing, there’s an application running on localhost of course if this is not vulnerable to SSRF the request shouldn’t be accepted so let’s try first local host hit send and check the responds.
http://localhost
The responds is positive, so it tells this is vulnerable to SSRF.
The server is running on, we’re able to access the admin panel as if we’re logged into the server itself.
If we go to raw in response section and search for the word admin you could see it’s running on the path /admin
We are going to add that to our request.
Send it then we should see the admin interface
The admin interface allows you to delete users and in this case these two users over here in order to delete the users you go to click on the delete button.
Let’s do a search on “Carlos” in repeater and see what path is in order to delete the user Carlos.
http://localhost/admin/delete?username=carlos
Again in order to perform this attack we have to go through the vulnerable parameter and perform another SSRF attack. Let’s copy the path and put it in stockApi URL section and sent it. Let’s go back and access the admin interface.
Successfully deleted the user “Carlos”.
We successfully completed the exercise by manually exploiting SSRF vulnerability. In order to access the admin interface that was available on the application running locally on the server and deletes the Carlos user.
Impacts
Data Disclosure: An attacker can use SSRF to access sensitive data that is not intended to be publicly accessible. For example, an attacker could use SSRF to read files from the server or access sensitive information from a database.
Data Manipulation: An attacker can use SSRF to manipulate data on the server, leading to unauthorized changes to the application’s data. This could result in data integrity issues or even data loss.
Application Compromise: SSRF can be used as a stepping stone for other attacks, such as remote code execution or injection attacks. Once an attacker has access to the internal network of an application, they can potentially compromise the entire application.
Network Access: SSRF can be used to access resources on the internal network that are not intended to be publicly accessible. This could include sensitive resources such as databases or network devices.
Denial of Service: An attacker can use SSRF to initiate requests to external resources that consume excessive resources on the server. This can lead to a denial of service (DoS) condition, rendering the application unavailable to legitimate users.
These are just a few examples of the potential impacts of SSRF. The severity of the impact depends on the nature of the vulnerability and the resources available to the attacker. It’s important to take measures to prevent SSRF vulnerabilities in web applications to protect against these impacts.
Prevention and mitigation strategies
Here are some prevention and mitigation strategies for Server Side Request Forgery (SSRF) vulnerabilities:
Input Validation: Implement proper input validation and sanitization techniques to prevent user inputs from being used to construct HTTP requests. Validate input parameters to ensure they are well-formed and meet expected patterns.
Whitelist Valid Hostnames and IPs: Implement a whitelist of allowed hostnames and IP addresses to prevent access to internal resources. This can be done by enforcing strict access control policies on external resources and implementing network segmentation.
Restrict External Access: Limit external access to only those resources that are absolutely necessary. Implement proper firewall rules and network access controls to prevent unauthorized access to internal resources.
Use Safe Protocols: Use safe protocols like HTTPS instead of HTTP, and restrict access to specific HTTP methods like HTTP POST, PUT, and DELETE, which can be used to modify data or execute arbitrary commands.
Use URL Whitelisting: Implement URL whitelisting to ensure that requests are only sent to pre-approved URLs. This can be done by maintaining a list of approved URLs and rejecting all requests that do not match the list.
Use Server-Side Request Filtering: Implement server-side request filtering to detect and block malicious requests before they can be executed. This can be done by using specialized tools or libraries that are designed to detect SSRF attacks.
Conduct Regular Vulnerability Assessments: Regularly assess your web application for SSRF vulnerabilities and other security issues to ensure that your application remains secure over time. This can be done by conducting penetration testing or using automated security testing tools.
Implementing these prevention and mitigation strategies can help protect your web application against SSRF vulnerabilities and mitigate their potential impact. However, it’s important to note that no single measure can guarantee complete protection against all SSRF attacks, so a comprehensive approach to security is required.
Mutual Authentication: In the context of SSRF, mutual authentication can be used to prevent attackers from exploiting vulnerable APIs or services that do not properly validate user input. By requiring mutual authentication, the server can verify the identity of the client making the request, which can prevent attackers from impersonating a legitimate client and accessing resources they should not have access to.