SQL Injection With Real Customer Data
During a web application test for an online retailer, you find a SQL injection in the 'search' parameter of https://shop.example.com/products. The backend is MySQL 8.0 running as the database user shop_app. The application stores customer names, addresses, and bcrypt password hashes. The rules of engagement say: 'Do not exfiltrate real customer data. Do not modify or delete data. Stop and notify the client if you encounter sensitive personal data.' You also find an unrestricted file upload in the support ticket form; the WAF blocks .php but not .phtml. The application is load-balanced across three servers, and the client has no staging environment. The client wants a working proof of impact but is worried about a data breach. The database contains 240,000 customer records.
1. How would you build a safe proof of concept for the SQL injection without dumping customer data?
Read the worked answer
Prove execution, not disclosure. Use non-sensitive metadata and aggregates:
- Boolean proof:
' AND 1=1-- -versus' AND 1=2-- -, and show the different response lengths. - Time proof:
' AND SLEEP(5)-- -, and measure the delay. - Metadata only:
' UNION SELECT 1,@@version,current_user-- -to show the database version and the application's database user. - Aggregate only if needed:
' UNION SELECT 1,COUNT(*),3 FROM customers-- -shows scale without returning a single record.
Use sqlmap with --technique=BT --current-user --current-db --is-dba --batch and no --dump. Capture the request, response, and timestamp for each step. Stop immediately if a response contains a name, address, or hash. Do not write the injection results into a shared report without redaction. The client gets a reproducible PoC and evidence of impact without a data breach.
2. How would you demonstrate the file upload risk without deploying a web shell?
Read the worked answer
Use a benign proof file. Create a .phtml file whose entire content is <?php echo 'POC-7f3a9c'; ?>. Upload it through the support ticket form and request the returned path. If the token appears in the response, the server executed PHP; that is sufficient proof. Do not include system(), exec(), shell_exec(), or any command parameter. Do not upload a full web shell, even temporarily.
Remove the file immediately after capturing evidence, and record the upload path, timestamp, and HTTP response. If the WAF blocks the request, do not obfuscate or bypass without written approval; report the control as effective and note the residual risk if .phtml were allowed. Because the app is load-balanced, note which backend served the file and whether the file persisted across requests. That detail affects remediation.
3. What should the report say about the data exposure risk, and what must you avoid including?
Read the worked answer
Describe the risk in categories, not records: 'SQL injection in the search parameter allows read access to the application database, which contains 240,000 customer records including names, addresses, and bcrypt password hashes.' State that you confirmed database metadata and execution but did not extract customer rows. Include the exact requests and responses with any sensitive values redacted.
Do not include real names, addresses, hashes, or record samples. Do not paste sqlmap output that contains dumped rows. Reference evidence by file name and hash instead. Recommend parameterised queries, least-privilege database accounts, WAF tuning, and logging/monitoring for injection attempts. Add a note that the ROE prohibition on exfiltration was observed, and that the client should treat the finding as a potential breach if logs show prior exploitation.