The SSRF error occurs whenever the web application fetches a remote resource without validating the user-supplied URL. It allows an attacker to force an application to send a specially crafted request to an unwanted destination, even when protected by a firewall, VPN, or network access control list (ACL) type. As modern web applications provide end users with convenient functionality, fetching a URL is becoming a common scenario. As a result, the incidence of SSRF increases. Furthermore, the severity of SSRF is increasing due to cloud services and architectural complexity.
Similar to Cross-Site Request Forgery that use a web client, such as a web browser, in the domain as a proxy for attacks; an SSRF attack uses an insecure server in the domain as a proxy. SSRF vulnerabilities occur when an attacker has full or partial control over the request sent by a web application. In a typical SSRF attack, an attacker can trick a server into establishing connections to internal services only within an organization’s infrastructure. In other cases, they can force the server to connect to arbitrary external systems, which carries the risk of leaking sensitive data such as authorization credentials.
SSRF can be used to scan ports, attack internal/external web applications, read files from local web server using file:///protocol handler.
Types of SSRF:
- Basic SSRF
In this attack, the response is displayed to the attacker. The server retrieves the URL requested by the attacker and returns a response to the attacker.
- Blind SSRF:
In this attack, the response is not sent back to the attacker. Therefore, the attacker must find a way to confirm this vulnerability.
SSRF attack
Basic SSRF against the local server:
- Go to a product, click “Check Stock”, intercept the request in Burp Suite and send it to the Burp Repeater.
2. Change the stockApi parameter URL to http://localhost/admin. This will bring up the admin interface.
- Read the HTML code to determine the URL to delete the target user, namely:
http://localhost/admin/delete? username = carlos
4. Send this URL in the stockApi parameter, to launch the SSRF attack.
Key points to check for SSRF vulnerability:
- Always make sure that you make requests on behalf of the public server to the main server and not from the browser.
- To retrieve server data, try http://localhost/xyz/ with http://127.0.0.1/xyz.
- The server may have firewall protection, always try to bypass the firewall if possible.
- Make sure that the request is coming from the server and not from your local host.
How to prevent
- From the network layer:
• Segment remote resource access functionality into separate networks to reduce the impact of SSRF
• Apply “deny by default” firewall policies or network access control rules to block all internal network traffic except essential traffic.
- From the Application layer:
• Sanitize and validate all input data provided by the client
• Enforce URL scheme, port and destination with active whitelist
• Turn off HTTP redirects
