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.
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.