Exercise 3: Remediation Sourcing and Why Only Confirmed Findings Belong in the Report — Possible Solution ==================================================================== WHY A SQLI FINDING'S REMEDIATION SHOULD POINT TO SQLI1 SPECIFICALLY ------------------------------ Per this chapter, "this is where this course's own 'toolkit' chapters (pentest1-6) pay off a second time, now applied to the defensive side rather than the offensive matching side: a SQL injection finding's remediation should point specifically at sqli1's own parameterized- query material." pentest1-6 already established that sqli1 is the authoritative, in-depth source on this exact vulnerability class on this site — it doesn't just explain how SQL injection happens, it specifically teaches the correct fix (parameterized queries) in real depth, including why string-formatting approaches that only look like a fix don't actually solve the underlying problem. Pointing the report's remediation guidance at that specific, already-existing material is more useful to the engineers who need to fix the issue than a generic "sanitize your inputs" instruction, since sqli1 explains the CORRECT, complete fix in detail, not just that a fix is needed. WHY ONLY PENTEST1-7-CONFIRMED FINDINGS BELONG IN THE REPORT ------------------------------ Per this chapter's own warn-box, "everything in the report should trace back to something actually confirmed via proof-of-concept in pentest1-7 — not an unverified candidate from pentest1-6's own pattern-matching phase that was never actually tested." pentest1-6 itself already warned that a pattern match produces a CANDIDATE, not a confirmed finding — a login form matching the "shape" of a weak-auth vulnerability might already be protected by rate limiting or MFA, for example. If the report treats every pentest1-6 candidate as though it were a proven finding, without pentest1-7's own proof-of-concept confirmation, the report risks including things that aren't actually real vulnerabilities at all. WHY THIS DISTINCTION MATTERS PRACTICALLY ------------------------------ Per this chapter, "reporting an unconfirmed candidate as though it were a proven finding risks sending a client to fix something that may not actually be exploitable, while genuine findings compete for the same limited attention." A client's remediation resources are finite. If unconfirmed candidates are mixed in with genuinely proven findings, the client can't tell which fixes are truly urgent and which might turn out to be false alarms — undermining the credibility of the report as a whole and potentially diverting effort away from the real, confirmed risks. WHY THIS WORKS AS AN ANSWER ------------------------------ It connects the remediation-sourcing question back to pentest1-6's own stated authority on the topic, and explains the warn-box's own reasoning by tracing the "candidate vs. confirmed" distinction all the way back to pentest1-6's original warning, rather than treating the two chapters as unrelated.