Production-Only Injection and a Lockout Counter
Blackridge Water's customer billing portal is the target. It is a production-only system with no staging copy, and a nightly batch job owns the database from 22:00 to 04:00, so the client has authorized testing 08:00–17:00 only. The login form locks an account after five failed attempts within 30 minutes; the lockout clears automatically and there is no self-service unlock, so a locked customer must call support. From the public marketing site and rate filings you have compiled 312 customer email addresses - no social engineering was used.
Manual review of the authenticated usage-history page shows that a search parameter returns a database error on a single quote. The table behind it holds 90,000 billing records with names, addresses, and bank account details. The client's primary concern is "whether someone can get the data," and the SOC has asked to be told in advance if you plan anything noisy.
1. Design your approach to the lockout-protected login. Should you spray the 312 customer accounts?
Read the worked answer
First question is not "how" but "should." Those are customers, not employees. Spraying them risks locking real people out of a billing portal, creates support load, and may not be authorized - check whether the RoE names customer accounts or only employee accounts.
If the objective is to test authentication strength:
- Ask the client to provision 5–10 test accounts in the same authentication path, or confirm the counter behaves identically for a test tenant.
- If real accounts must be used, confirm the counter empirically on 5 accounts, wait past the window, and confirm the reset behavior. Only then scale.
- If spraying is authorized, use one password per account per cycle with a cycle longer than 30 minutes (31–35 minutes for margin), coordinate with the SOC beforehand, and stop on the first unexpected lockout.
- Never run a second attempt inside the window because a request timed out - retries are what cause lockouts.
Record every lockout you cause. The control you are testing protects customers; breaking it during the test is a real denial of service.
2. How do you demonstrate the SQL injection on a live production system without causing an incident?
Read the worked answer
Prove access with the least invasive technique, then bound it deliberately.
- Confirm the flaw by differential response: a quote versus an escaped quote, or a boolean condition returning a stable difference. Prefer boolean or time-based blind over UNION extraction.
- Stop extracting as soon as the point is made: DBMS type and version, current database user, and the existence of the billing table (row count or a single redacted value). That answers "can someone get the data" without becoming the breach.
- Use low risk/level settings, cap time delays at a couple of seconds, and throttle to avoid database load during business hours.
- No stacked queries, no write operations, no file read/write or command execution through the DBMS, even though they may work.
- Warn the SOC, capture full HTTP request/response evidence, and set stop conditions: a spike in 5xx responses, connection-pool exhaustion, or an SOC alert ends the attempt.
The reasoning: on a production-only system you cannot roll back, so impact control replaces rollback.
3. The client says: "Just pull the whole table so we have proof." How do you respond?
Read the worked answer
Decline, and explain why the refusal protects them.
Pulling 90,000 records containing names, addresses, and bank details creates a second copy of regulated data on your laptop, expands the engagement's data-processing footprint, converts your evidence store into a high-value target, and may trigger breach-notification analysis if it is lost. It also makes the report's data-handling section untrue.
What proves the point instead:
- A row count of the table, obtained without dumping rows.
- One record's structure with values redacted, or a single field truncated to a few characters.
- A screenshot of the query result showing column names with masked values.
- A before/after request pair showing that a crafted parameter changes the response deterministically.
Offer the client a supervised alternative if they need more: they query their own database and share the result. Then restate the engagement's data-minimisation and destruction commitments in the report.