CodePark/ questions / Injection attacks
START PRACTICINGPRACTICE
Backend question · Auth & security › Injection attacks

What is SSRF, why is it especially dangerous in the cloud, and how do you defend a feature that fetches user-supplied URLs?

SSRF (server-side request forgery) happens when your server fetches a URL that the user controls. Common features that do this:

  • a webhook target
  • an image import from a URL
  • a PDF renderer that loads a page

The attacker points the URL at places your server can reach but the attacker can't:

  • the cloud metadata endpoint at http://169.254.169.254/, which can return credentials
  • admin panels on localhost
  • internal services

This is why SSRF is so dangerous in the cloud: one request can leak the server's cloud credentials. SSRF is A10 in the OWASP Top 10 2021.

Defences:

  • Allowlist the destinations when you can.
  • Otherwise, allow only http and https.
  • Resolve the hostname to an IP, then block private, loopback, link-local and metadata ranges.
  • Connect to the same IP you checked. This stops DNS rebinding, where the attacker's DNS returns a safe IP for the check and an internal IP for the real request.
  • Don't follow redirects blindly, because a redirect can point to an internal address.
  • At the network level, limit egress (outgoing traffic) from the services that fetch URLs.
  • On AWS, require IMDSv2, the metadata service version that needs a session token.
  • Never return the raw response or detailed errors to the user.
  • SSRF makes the server send requests to URLs the attacker chooses.
  • Common targets are the cloud metadata endpoint, localhost and internal services.
  • Use an allowlist, and block private and link-local ranges after DNS resolution.
  • Handle redirects and DNS rebinding by connecting to the IP you checked.
  • Add network egress controls, and require IMDSv2 on AWS.