What is SSRF?
SSRF, server-side request forgery, is an attack in which the attacker gets a web application's server to make an outbound request to a destination of the attacker's choosing. The attacker never connects to the target directly. Instead they hand the application a URL, and the server, doing what the feature was built to do, fetches it. What the attacker gains is the server's place on the network: it can usually reach internal services, admin consoles and cloud infrastructure that nobody on the internet can reach.
Where SSRF appears
Any feature that retrieves a URL for the user is a candidate. Common examples:
- turning a submitted web page into a thumbnail or preview
- importing data from a link
- testing a webhook address
- loading a profile picture from an address the user supplies
Rather than an external site, the attacker submits an internal address.
The cloud metadata target
The most famous destination is 169.254.169.254, the instance metadata endpoint in cloud environments. It is a link-local address that a cloud virtual machine calls to learn about its own configuration, and the answers include temporary credentials. If the vulnerable fetch feature can be pointed there, the response can hand those credentials to the attacker:
GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
Watch for outbound requests whose target is a loopback address such as 127.0.0.1, a private range such as 10.0.0.0/8, or the metadata address; those are the indicators. In the 2019 Capital One breach, an SSRF was used to reach cloud metadata and read credentials.
How to prevent SSRF
Defense has two parts: restrict where the server is allowed to go, and make the metadata service ask the caller to prove itself.
- Keep an allow list of destinations the fetch feature may contact.
- Block private and link-local ranges, including loopback and the metadata address.
- Validate the supplied URL and resolve it before making the request.
- Refuse redirects that send an allowed address on to an internal one.
- Harden the metadata service. On AWS, require IMDSv2, which is session-based: a caller has to obtain a token first, and a simple SSRF cannot do that.
SSRF vs. CSRF
The names differ by one letter, and the attacks run in opposite directions. In CSRF the forged request starts in the victim's browser and goes to a site that trusts that browser, so the fix belongs in how the site checks incoming requests. In SSRF the request starts at the server and goes to a destination the attacker picked, so the fix belongs in limiting what the server can reach. When the target of a fetch is an internal IP or the 169.254.169.254 metadata endpoint, the answer is SSRF, even though both names contain the word forgery.
SSRF on the CompTIA Security+ exam
SSRF is an application attack under objective 2.5. Scenario wording about a server being made to request an internal URL, reach a cloud metadata endpoint, or fetch a resource on an attacker's behalf points at it. The distractors are CSRF, when the browser is fooled, and directory traversal, when the payload is a file path. The defenses the exam wants are destination allow lists, blocking private ranges and requiring IMDSv2.