Server-Side Request Forgery(SSRF)

Server-Side Request Forgery (SSRF) is a security vulnerability that allows an attacker to make unauthorized requests to internal or external resources on a server. This type of attack occurs when an application does not properly validate or sanitize user-supplied input and allows the attacker to manipulate the input to fetch data from unintended sources.

Here’s how SSRF typically works:

1. **User Input**: The attacker finds a web application that takes user-provided input, such as a URL or file path, and uses it to make requests to other resources.

2. **Manipulating Input**: The attacker manipulates this input to point to internal resources or external servers of their choice. They can use techniques like URL encoding, double URL encoding, and various protocols to craft malicious requests.

3. **Request to Internal Resources**: If the application doesn’t properly validate or restrict the input, it may make requests to internal resources, such as database servers, internal APIs, or even local files. This can lead to data leakage or unauthorized access to sensitive information.

4. **Request to External Resources**: The attacker can also use SSRF to make requests to external servers. This can be used for various purposes, including proxying requests through the vulnerable server, scanning for open ports on internal networks, or conducting attacks on third-party systems using the server as a pivot point.

SSRF attacks can have serious consequences, as they can lead to data breaches, unauthorized access, and potential lateral movement within a network. To prevent SSRF attacks, developers should:

- Validate and sanitize user input, especially when it’s used to construct URLs or make network requests.
- Implement proper access controls and permissions to restrict which resources the application can access.
- Use allow-lists instead of deny-lists to define what resources are accessible.
- Isolate the server from the internal network to limit potential damage if an SSRF attack is successful.

Additionally, it’s essential for organizations to educate their development and operations teams about the risks associated with SSRF and implement security testing and scanning tools to detect and mitigate SSRF vulnerabilities in their applications and systems.

POC 1:

In Burp Suite, I checked for some different redirection parameter other than URL=, and in the search field, I’ve tried with various parameters. By using this parameter of , I’ve captured the request of the particular path and had sent it to the repeater.

Request is captured from the search file in the repeater, and here in file feed, a .jpg file is available. Now, I had removed the file and entered a third party URL on file Redirected URL: https://www.expressvpn

Once I click on Go to capture response, the response is changed to expessvpn.com and you can see the IP of the testphp.vulnweb.com. But in the render page, you can see the expressvpn.com site getting loaded as follows:

PREVENTION FROM SSRF:

• Generic error messages should be displayed to every client, as unhandled responses might end up in revealing sensitive information or data leakage about the server, when any other raw response or different parameter is used.
• URL schemes other than HTTP and HTTPS should be blacklisted. Instead, these two mentioned protocols should be whitelisted thereby blocking different schemes which are not in use like file:///, direct://, feed://, touch:// and FTP://, which might prove to be dangerous for SSRF.

Thanks for taking out time to read this! Do Clap if you liked it. See you next time!

Till then do connect with me on Linkedin.