Server-side request forgeries (SSRF) occur when the web application sends a request to the web server, and the webserver retrieves the requested content. However, the webserver does not ensure that the request is sent to an appropriate destination.
In other words, this vulnerability allows a malicious party to get a server-side application to make HTTP requests to the domain of the malicious party’s choice.
Using SSRF attacks, a malicious party could cause the server to:
- Connect to services that should not be available to external users
- Connect to external systems, leaking sensitive information like access tokens/keys, authorization credentials, etc.
There are several different ways malicious parties can execute an attack using SSRF, and attack surfaces are typically easy to find due to the extensive use of URLs:
- Modifying requests from the server to access other server-side/back-end systems. These systems would typically be inaccessible to end-user, but because the request “originates” from a known and trusted server, the malicious party can bypass security systems protecting the back-end.
- Modifying a request to a URL local to the server. Because the request originates from the server, someone can bypass the need for admin credentials. For example, visiting an /admin URL will yield nothing without proper authentication. However, the same request from the server probably won’t be blocked.
To help protect your application against SSRF attacks:
- Sanitize all user input that is used in URLs and other requests and avoid sending raw responses from the server-side to the client-side
- Use an allowlist to enforce the available ports/destinations to which URLs can call
- Disable HTTP redirections
- Use firewall policies or network access control rules to block all unnecessary traffic
CWE-919, or server-side request forgeries (SSRF), occurs when malicious parties can induce a server to make requests that help them gain access to internal infrastructure, sensitive data, and more. The attack surface for SSRF can easily be identified via the use of URLs. They can be difficult to deal with, though sanitization and allowlists are some of the more powerful tools available.