A library stakeholder wants SQLMap run against production with full crawl and unrestricted dump options. What automation judgment should the tester apply?
Select an answer to reveal the explanation.
Short Explanation
SQLMap on production with “crawl everything and dump it all” is a lawnmower in a china shop. Dial the scope tight, add delays, and take only the proof you need. Defaults and max threads are not a safety plan.
Full Explanation
Automation against production SQL injection must tighten scope, throttle requests, and limit extraction to disciplined evidence needs. When a library stakeholder wants SQLMap with full crawl and unrestricted dumps, the tester’s judgment should protect patron data and service availability while still proving the issue—not maximize tool flags.
Full crawl plus dump is not mandatory evidence for every SQLi. Maximum threads with no delays on production is reckless. Unchanged default configs do not make production automation safe.
Exam caveat: tools amplify both proof and damage; CPTS professionalism is configuring them down for civic production, not up. Prefer manual confirmation plus minimal automated checks.
Operational check: restrict hosts/parameters to the vulnerable civic endpoint, set delays/threads conservatively, disable unbounded dump options, extract only non-sensitive proof rows if any, and stop on availability alarms. Prefer a short, reviewer-approved SQLMap profile stored with the library RoE over ad-hoc full-crawl flags under production pressure. Production SQLMap profiles for libraries should default to off for dump and high thread counts. Cite the control owner in the civic remediation plan.