A municipal app shows no verbose SQL errors, yet responses consistently change between true-looking and false-looking conditions for crafted inputs. How should that theme be classified?
Select an answer to reveal the explanation.
Short Explanation
No stack traces does not mean no SQLi. If the page quietly nods yes or no based on your crafted condition, that is boolean blind territory. Same injection family — just answered with behavior instead of error text.
Full Explanation
Consistent true/false response differences for crafted inputs without verbose SQL errors suggest boolean-based blind SQL injection class behavior. A municipal app that stays silent on errors can still disclose logic through response patterns; controlled testing remains warranted under RoE because blind classes can still expose or alter data affecting resident services.
Silent apps can absolutely have SQL flaws. Response differences do not always mean XSS. This pattern is not a pure CSRF finding without data-layer involvement.
Exam caveat: blind SQLi still needs throttled, hypothesis-driven tests—not blind faith that “no errors means safe.” CPTS taxonomy should name boolean/time-based blind classes accurately.
Operational check: confirm differential responses with minimal true/false probes, avoid destructive payloads, limit evidence to what proves the class for the county report, and recommend parameterized queries and error hardening. Parameterize the silent municipal queries even when errors are hidden—blind classes prove the data layer remains reachable without verbosity. Blind classes still justify parameterized-query remediation on silent municipal apps. Cite the control owner in the civic remediation plan.