Test what you understood — not what you memorized.
QUESTION 01 OF 05
What makes SSRF in a cloud environment significantly more dangerous than in an on-premises deployment?
Correct — the AWS/GCP/Azure instance metadata endpoint is accessible from within the instance and returns temporary IAM/service account credentials. In an on-premises deployment, SSRF can reach internal services and read local files — serious, but bounded. In a cloud deployment, SSRF can reach 169.254.169.254 and return credentials that give the attacker the same cloud permissions as the application itself — potentially access to all data the app role can touch, across all services, from anywhere on the internet. This is why SSRF was added to the OWASP API Top 10 in 2023.
Not quite — the core reason is the instance metadata endpoint. Every major cloud provider (AWS, GCP, Azure) exposes a special endpoint at a fixed link-local IP that returns the instance’s cloud credentials. SSRF lets an attacker make the server fetch this endpoint and return the credentials. In Capital One’s case, this one URL provided access to 100M+ customer records across 100+ S3 buckets.
QUESTION 02 OF 05
An API validates that a user-supplied URL hostname is not an internal IP address. An attacker registers “attacker.com” which initially resolves to a public IP, then changes the DNS to resolve to 10.0.0.1. Why does this bypass the validation?
Correct — this is DNS rebinding. The validation and the fetch are two separate DNS lookups. If the attacker controls the DNS record and sets a very short TTL, the record can change between the two lookups. The validation checks the public IP (passes), but by the time the HTTP client makes the connection, DNS returns 10.0.0.1. The fix: resolve the hostname once, validate the resulting IP, then make the HTTP request directly to that resolved IP — not to the hostname again. This guarantees the IP that was validated is the IP that receives the connection.
Not quite — this is DNS rebinding. The key is that DNS resolution happens twice: once during the check (returns public IP) and once when the HTTP connection is made (now returns internal IP). With a short DNS TTL (e.g., 1 second), the attacker can control which IP is returned at each moment. The fix is to resolve DNS once, validate the IP, then connect directly to the resolved IP — skipping the second DNS lookup entirely.
QUESTION 03 OF 05
An import API validates that user-supplied URLs don’t point to internal IPs. An attacker supplies a URL from a legitimate domain that returns a 302 redirect to http://169.254.169.254/. The SSRF succeeds. What was missing?
Correct — redirect-based SSRF bypass is one of the most common ways to circumvent IP validation. The validation passes on the original URL (legitimate domain). The HTTP client follows the 302 redirect automatically. The redirect destination (169.254.169.254) is never validated. Fix: disable automatic redirect following entirely, OR apply the same IP validation to every redirect destination before following it. Disabling redirects is simpler and safer for most use cases — if the feature doesn’t genuinely need to follow redirects, don’t.
Not quite — the issue is that the HTTP client follows redirects automatically without validating the redirect destination. The original URL passes the IP check (it resolves to a legitimate public IP). The 302 redirect sends the client to 169.254.169.254 — but this destination is never checked against the IP validation rules. The fix is to disable automatic redirect following (MIT 03), so the redirect is never followed, or to validate each redirect destination before following it.
QUESTION 04 OF 05
Why is returning raw server responses to API clients a problem specific to SSRF, even if the URL-fetching itself was already blocked or failed?
Correct — MIT 04 (don’t return raw responses) is a defense-in-depth layer. Even if SSRF occurs and the server successfully fetches the metadata endpoint, the attacker can’t steal the credentials if the response is never returned to them. The server fetches the credentials, fails to parse them as the expected data format (e.g., the JSON isn’t a valid product catalog), and returns “import failed” — without including the raw response. The attacker learns the import failed, but gets nothing useful. This doesn’t fix SSRF — it limits what the attacker can do with it.
Not quite — the core issue is data exfiltration. SSRF is most dangerous when the attacker can read the response. If the server fetches the metadata endpoint but only returns “import failed, invalid format” without the response body, the SSRF occurred but the attacker got nothing. Many SSRF exfiltrations work specifically through error messages: “Failed to parse JSON: [response body here]” — the credentials are in the error message. Sanitizing error messages and never returning raw responses prevents this exfiltration path.
QUESTION 05 OF 05
In the Capital One breach, the blast radius was 100M+ records across 100+ S3 buckets. What non-SSRF factor made the damage this large?
Correct — SSRF was the entry point, but IAM over-permissioning determined the blast radius. The EC2 role’s credentials, once stolen, granted access to every S3 bucket the role could touch. If the role had been scoped to only the specific buckets and prefixes the application actually needed — least privilege — the breach would have been much smaller. This is a general security principle that compounds SSRF: the damage from credential theft is bounded by what those credentials can do. Tight IAM policies limit the damage even when SSRF succeeds.
Not quite — the amplifier was IAM over-permissioning. The EC2 instance role had access to far more S3 data than the application needed to function. When SSRF stole those credentials, the attacker inherited all of those permissions. The principle of least privilege — granting each role only the minimum permissions it requires — is not an SSRF defense itself, but it is the primary control that limits SSRF damage when credential theft occurs. Minimum IAM scope + SSRF prevention = defense in depth.