PT0-002 Attacks and Exploits Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Accessing the AWS metadata endpoint at 169.254.169.254

  Why this is correct

  Accessing the AWS metadata endpoint at 169.254.169.254 is a textbook SSRF technique because this link-local address is reachable only from within the cloud environment and provides IAM security credentials, user-data, and instance configuration when queried. By making the vulnerable server request this IP, an attacker can steal cloud role credentials and pivot into the target's AWS account. This usage directly demonstrates SSRF's core characteristic: the server is tricked into fetching an internal resource on the attacker's behalf.

• ✓

  Scanning internal IP addresses and ports

  Why this is correct

  Scanning internal IP addresses and ports leverages SSRF to turn the vulnerable web server into a proxy for reconnaissance. The attacker can send requests to internal CIDR blocks and determine open ports by analyzing response codes, content length, or timing differences, effectively bypassing network segmentation filters. This internal probing is a primary exploitation path in SSRF scenarios, distinguishing it from client-side or database-focused vulnerabilities.

• ✗

  Crafting a JavaScript payload for XSS

  Why it's wrong here

  Crafting a JavaScript payload for XSS is incorrect because XSS executes in the victim's browser, not on the server, and cannot cause the server itself to initiate arbitrary outbound HTTP requests. SSRF requires the server to make a request; a client-side script has no direct control over the server's network stack unless combined with a separate server-side vulnerability. Therefore, while XSS may steal tokens or cause authenticated actions, it is not a method for performing SSRF.

• ✗

  Injecting SQL queries into the URL

  Why it's wrong here

  Injecting SQL queries into the URL targets the database layer and directly manipulates SQL statements, whereas SSRF exploits the server's ability to fetch a URL supplied by the attacker. SQL injection reads or alters database content; SSRF exfiltrates cloud metadata or probes internal networks through the server's HTTP client. These are distinct vulnerability classes with different payloads, endpoints, and remediation strategies, so SQLi is not a valid SSRF technique.

• ✗

  Forcing the server to send a POST request

  Why it's wrong here

  Forcing the server to send a POST request is not a core SSRF technique because SSRF is about controlling the destination URL or host, not the HTTP method; in most cases the server-side framework fetches the provided URL using a GET request as part of an image, webhook, or API integration. An attacker could, in theory, influence the method if a vulnerable endpoint forwards a raw request, but that is an unusual edge case rather than the standard SSRF reconnaissance or metadata access approach. Thus, focusing on the POST method does not align with common SSRF exploitation patterns.

Go deeper

Related to this question