OWASP Top 10 API security risks: Server side request forgery

Number seven on the Open Worldwide Application Security Project® (OWASP) Top 10 API Security Risks for 2023 is server side request forgery (SSRF).

SSRF is a nefarious tactic, allowing attackers to abuse server functionality to access areas that should not be available directly. Attackers can make arbitrary outbound requests from a server, gather information from internal systems that are not publicly accessible, or query metadata endpoints.

Attack vectors

SSRF exploits occur when attackers find an API endpoint that can access a uniform resource identifier (URI) provided by the user. In a basic SSRF attack, attackers probe endpoints looking for responses that contain information they can use for exploitation. For example, analysis of HTTP status codes. A blind SSRF attack does not elicit direct feedback but allows an attacker to infer information that can be used to trick servers into providing access.

OWASP rates server side request forgery attacks as easy.

Security weaknesses

Improper validation of URIs is common, but also fairly easy to detect. Routine API requests and analysis of the resulting response can uncover potential information that attackers could use. Detecting security weaknesses in APIs from blind SSRF attacks is a little more challenging.

Modern practices in the way applications are developed are more common and more dangerous, according to OWASP. Developers typically access external resources based on user input. Cloud providers, Docker, or Kubernetes, however, can expose management and control on predictable paths, making them an easy target for such an attack if proper protections are not put in place.

Because of the way applications are connected, it can be challenging to limit outbound traffic. As such, the risk of an SSRF attack is always there.

Business impacts

OWASP rates the business impacts from SSRF attacks as moderate, although they can lead to substantial problems.

For example, attackers may use the information gained for port scanning or to uncover internal services that can be used to bypass firewalls or other security systems. This can provide threat actors with access to sensitive data or allows them to conduct denial of service (DoS) attacks. Servers also can be used as proxies to hide malicious activity.

How server side request forgery attacks work

Server side request forgery occurs when an API is fetching a remote resource but is not requiring the validation of the URL supplied by the user. This allows attackers to force the application to send a response to an unexpected destination, even if it is protected by a VPN or firewall.

A typical attack might work like this:

• Attackers look for user-input fields or parameters that are used to make HTTP requests.
• A malicious request is sent to manipulate the vulnerable parameters.
• By specifying internal IP addresses, local hostnames, or private network ranges, attackers induce the server into making requests for what should be restricted resources.
• Attackers then gain access to sensitive or proprietary data.
• Once access is granted, attackers may be able to move laterally within systems or launch attacks on other network systems.

SSRF attacks may also be able to access external resources. For example, attackers might specify the URL of third-party APIs.

OWASP provides an example of how SSRF attacks might work in the real world. Social networks allowing users to upload profile pictures can trigger an API call for an image’s URL. Attackers can send a malicious URL and initiate port scanning on the internal network using the API’s endpoint to uncover open ports.

Detecting server side request forgery vulnerabilities

Detecting SSRF attacks requires a combination of automated tools and manual testing, including:

• Source code review to identify potential attack vectors where user-supplied input makes HTTP requests.
• Manual testing, providing URL variations, IP addresses, and protocols in input fields to see if they are processed correctly or deliver unexpected results.
• Testing for local file inclusion to attempt access for files on local servers containing sensitive data. This should include network probing to see if requests for internal IP range or restricted segments allow for access to unauthorized resources.
• Regular log reviews to look for unexpected patterns of requests, such as requests to internal resources or unusual destinations.

Web application scanning tools and automated SSRF testing frameworks can automatically crawl APIs and test applications for security issues.

Preventing server side request forgery vulnerabilities

Preventing server side request forgery vulnerabilities requires deploying foundational cybersecurity practices, including enforcing the principle of least privilege (POLP) and Zero Trust. Don’t allow user input without first validating it, regardless of where it comes from.

You should never assume that internal resources are protected when they are not directly exposed to the internet. Once attackers gain access to your network, any security gaps may allow them to access non-connected resources. As such, it is strongly recommended that you isolated the resource-fetching mechanism in your network. Typically, these features are used to retrieve remote resources and not internal ones.

Wherever possible, restrict traffic to allow lists for:

• URL schemes and ports
• Media types for specific functionalities
• Downloading resources

You should also disable HTTP redirections and, as always, ensure you stay current with software patches and updates and use a web application firewall.