Server-side request forgery is an attack carried by an attacker exploiting the vulnerability/weakness in an application to submit HTTP requests to internal systems. What’s the need for that? Information can be gathered from internal systems through this attack. Even attackers can control the internal systems. Yes, this is a serious one to deal with.
Let me keep as simple as it is to explain this vulnerability and attack. In a classic attack, the attacker will try to make a vulnerable site connect to the internal system within the network. Even external connections can be made in some cases to make a constant flow of data from the attacker machine to an internal machine. These are all based on the level of weak configuration.
How and when this attack is carried by an attacker?
If a web application has an option to read data from a URL or import data from a URL, and it is not controlled internally to validate the input from the client, then an SSRF attack is possible.
Code Snippet:
Got a vulnerable code to explain it in a better way (https://www.fatalerrors.org/a/ssrf-of-java-audit.html)
The highlighted is the place to look for us here. In this snippet, the first highlighted place where the value for URL is requested from the client. Then the same URL is passed in the code to open the connection. The third highlighted area is where the application is allowing the add HTML content from the passed url.
URL example 1: www.example.com/ssrf?url=http://www.socinvestigation.com
In the above URL, the request is submitted to load the contents of our blog into the vulnerable site. It will load if the connection is made to our blog from the vulnerable site. In this way, we can first confirm that the requested URL connection is successfully made.
URL example 2: www.example.com/ssrf?url=http://www.subdomain.com
By, confirming the first test. We can try to load internal systems or subdomains in the same network to load. That will reveal all the information onto the screen. Now, comes the tricky part of the SSRF attack. Internal systems are hard to access from the internet since it is protected behind a firewall and restricted by network perimeters. But, the internet-facing vulnerable website is allowed in WAF rule and network perimeter. Thus, the attacker’s call to internal subdomains or systems will go as a legitimate request through the allowed vulnerable site and bring valuable information to an attacker.
Also Read: Remote File Inclusion Prevention
Some impacts of SSRF vulnerability are:
- Unauthorized access to sensitive information (we seen it in above example)
- Port scanning can be done using this weakness to find unsecured services running in the system.
- Chain attack can be made possible.
- At times malicious request will be circulate in wild using organization domain which question organization reputation and security.
Prevention:
- First have authentication to all internal system to system communication.
- Validate the received input from client as expected or not. If it’s not as expected, pass violation error to the client.
- In validating received input have strong regex matching, there are attacks performed in a way by encoding values to confuse the validation rule. So, have such test cases in prior to test this functionality.
- Blacklisting and whitelisting are always not considered to be safe strategy against SSRF attacks. Detailed considerations to be taken during fixing this vulnerability on all the OSI layers.
For more use cases on preventions refer to OWASP SSRF Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html