Exercise 1: PoC vs. Full Exploitation for a Confirmed SQLi Login Form — Possible Solution ==================================================================== THE SCENARIO ------------------------------ A pentest1-6 candidate confirmed a SQL injection point in a login form. WHAT A PROPER PROOF-OF-CONCEPT LOOKS LIKE ------------------------------ Per this chapter's own table, the proof-of-concept for a SQLi candidate is "a UNION-based query extracting one non-sensitive row (e.g. a database version string)." Applied to a login form specifically, this means demonstrating that the injection point allows a UNION-based query to return a single piece of otherwise- inaccessible information — for example, the database's own version string, or bypassing the login logic itself for a single test/known account, without going further than that single demonstration. WHAT WOULD CROSS INTO UNNECESSARY FULL EXPLOITATION ------------------------------ Per this chapter's own table, unnecessary full exploitation for a SQLi candidate would mean "extracting an entire customer table, or modifying/deleting real data." Applied here, that would mean using the confirmed injection point to dump the entire user credentials table, log into arbitrary real customer accounts beyond the single demonstration account, or alter/delete real records in the database — none of which is required to PROVE the vulnerability exists. WHY THE PoC ALONE IS SUFFICIENT ------------------------------ Per this chapter, "once a vulnerability is confirmed exploitable in principle... extracting every row or every session isn't 'being more thorough.' It adds no additional evidentiary value: the PoC already proved everything the client needs to know." A single successful UNION-based extraction (or a single successful auth bypass on one account) already demonstrates conclusively that the injection point is real and exploitable — the client now has everything they need to understand the severity and fix it. Extracting the full customer table would not make the vulnerability "more proven"; it would simply add unnecessary exposure of real customer data with zero additional proof value, which per this chapter's own warn-box, a signed authorization does not automatically cover. WHY THIS WORKS AS AN ANSWER ------------------------------ It applies the chapter's own table entry for SQLi directly to the login-form scenario, and explains the "no added evidentiary value" principle specifically rather than just restating the general rule.