An online security hole called Server-Side Request Forgery, or SSRF, enables an attacker to compel a server-side application to submit HTTP requests to any domain they want.
When a web application downloads a remote resource without first verifying the user-supplied URL, an SSRF problem occurs. Even when a software is shielded by a firewall, VPN, or another sort of network access control list, a hacker can still force it to submit a forged request to an unexpected location.
This category illustrates a situation in which members of the security community advise us that something is crucial even though it isn’t shown in the statistics.
The server-side code detects the altered URL and tries to read data to it when the corrupted request is sent to the server. The attacker may be able to read data from services that are not immediately exposed on the internet by choosing target URLs:
- Metadata from cloud servers Cloud services such as AWS provide a REST interface on http://169.254.169.254/. This allows for the extraction of crucial configuration and occasionally even authentication keys.
- HTTP interfaces for databases – NoSQL databases like MongoDB offer REST interfaces over HTTP ports. Authentication may be deactivated and the attacker may be able to extract data if the database is solely intended to be used internally.
- Files – Using URIs, the attacker might be able to read files.
In order to get around input validation, the attacker might exploit this functionality to import untrusted data into code that only expects to read data from reliable sources.
Impact of Server-Side Request Forgery
- Unauthorized activities or access to data within the business may arise from a successful SSRF attack, either on the vulnerable application itself or on other back-end systems that the application can interact with. The SSRF vulnerability could, under certain circumstances, give an attacker the power to execute any command.
- Malicious forward attacks that seem to come from the company hosting the susceptible application could occur from an SSRF exploit that establishes connections to external third-party systems.
- An attacker can use this approach to learn about ports, IP addresses, and servers that are running a reverse proxy, among other information.
Remedy to Server-Side Request Forgery Vulnerability includes :
- Whitelist Domains in DNS
- Enforce URL Schemas
- Enable Authentication on All Services
- Sanitize and Validate Inputs
- Accept IP addresses only in their intended format (IPv4 or IPv6).
- Use the IP address value from the method/output library when compared to the allow list.
CWE List for Server-Side Request Forgery
References To Get More Understanding of Server-Side Request Forgery
This will be all for the Day 14 post and the end of OWASP Top 10 2021. Hope you enjoyed every bit of it. Kindly let me know in the comments section if you did. Be sure to check out other blog posts of interest or come back tomorrow for the next day’s post, which will cover different topics or lab solutions.