Exercise 3: Why IMDSv2's PUT Requirement Blocks Typical SSRF Attacks — Possible Solution
====================================================================

A typical SSRF (server-side request forgery) vulnerability lets an
attacker trick a vulnerable application into making an HTTP request
to a URL of the attacker's own choosing -- but the attacker is
working through the application's own existing request-making
behavior, not directly controlling every aspect of it. Most real SSRF
exploits can manipulate a request's own URL or headers, but they are
constrained by whatever HTTP method and request pattern the
vulnerable application already uses -- typically a simple GET
request.

IMDSv1 required nothing more than exactly that: a single, simple,
unauthenticated GET-style request was enough to read metadata,
including IAM role credentials -- making it directly reachable
through this kind of manipulated request.

IMDSv2 requires a genuinely different, separate first step: an
explicit PUT request must be sent to establish a session and obtain a
secret token, and only THEN can that token be used in a header on
subsequent GET requests to actually read metadata. A typical SSRF
vulnerability that can redirect or manipulate an existing GET request
usually cannot also fabricate an entirely separate PUT request from
scratch -- that specific request type is rarely something the
vulnerable application's own normal behavior would ever construct on
the attacker's behalf.

ANSWER: IMDSv2 is harder to exploit via typical SSRF because stealing
credentials now requires two genuinely different steps -- an initial
PUT request the attacker usually cannot forge through a manipulated
GET-based vulnerability, followed by a token-authenticated GET request
-- rather than IMDSv1's single, simple, unauthenticated GET request
that a manipulated request could satisfy directly.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the SPECIFIC mechanical reason the two-step
design defeats a typical SSRF exploit (the request-type mismatch, not
just "it has a token now"), matching the chapter's own real, cited
technical reasoning that a PUT-then-token design is structurally more
effective than requiring only a static header.