A transit UNION-based SQL injection could return citizen PII. How should the tester demonstrate impact responsibly?
Select an answer to reveal the explanation.
Short Explanation
You can show the door opens without carting out every citizen’s file cabinet. Pull the smallest safe proof, redact in the report where you can, and leave the bulk PII alone. Read-only does not mean consequence-free when the data is people.
Full Explanation
UNION-based SQL injection that could return citizen PII should be demonstrated with the minimum sensitive rows needed for evidence, avoiding unnecessary PII exposure. Transit assessors prove exploitability and impact class without exporting entire directories of riders—data minimization is part of ethical municipal testing.
Exporting the entire citizen directory to cloud storage is unjustified exfiltration. Emailing raw PII to unvetted peers leaks protected data. UNION queries being read-only does not make PII exposure harmless.
Exam caveat: impact proof ≠ bulk data theft. CPTS reporting should show capability with redaction and minimal samples under RoE and privacy rules.
Operational check: select a single low-sensitivity proof field or synthetic indicator where possible, redact screenshots, avoid cloud dumps of PII, and recommend parameterized queries plus least-privilege DB accounts for the transit app. Note data-minimization choices in the transit report methodology section to show sponsors that impact was proven without bulk PII export. Redact rider identifiers in UNION proofs before screenshots enter the transit report archive. Cite the control owner in the civic remediation plan.