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.

• ✗

  Out-of-band SQL injection

  Why it's wrong here

  Out-of-band SQL injection is incorrect because it requires the tester to trigger the database to make an external network call (e.g., DNS or HTTP) to an attacker-controlled server to exfiltrate data. This technique is used when the application does not return query results or error messages in any form, and it depends on specific database features and unrestricted egress traffic. In this scenario, the tester is relying on observable behavior changes in the application response, not an external channel, so it does not fit.

• ✓

  Blind SQL injection

  Why this is correct

  Blind SQL injection is correct because the tester is exploiting the vulnerability without seeing actual query results or database errors in the application response. Instead, they infer database behavior by observing differences in application responses — either boolean outcomes (e.g., ' AND 1=1 vs ' AND 1=2 causing different page content) or time delays (e.g., SLEEP or WAITFOR DELAY). These indirect signals allow the tester to extract data piece by piece, which aligns with the scenario of exploiting a SQL injection in a low-information environment.

• ✗

  UNION-based SQL injection

  Why it's wrong here

  UNION-based SQL injection is wrong because it requires the application to display the results of the injected SELECT statement directly within its response. The technique depends on matching the original query's column count and data types, then rendering the UNIONed rows visibly. If the application does not display query output — for instance, showing only a success or failure indicator — the injected data would never be visible, making this technique impossible in a blind context.

• ✗

  Error-based SQL injection

  Why it's wrong here

  Error-based SQL injection is incorrect because it relies on the database generating verbose error messages that the application displays to the user. The attacker crafts payloads (like extractvalue or updatexml) that force the database to include exfiltrated data in an error string, such as a duplicate-key error. This approach fails when the application suppresses error details or returns generic messages, so it cannot be used when only behavioral differences are observed rather than error content.

Go deeper

Related to this question