Prove SQL injection on your own app without destroying data
Task
Find and prove a SQL injection in a deliberately weak application you built, demonstrating impact without destroying the data, then fix it with parameterised queries and confirm the fix. Proving a flaw does not require harming the target.
Steps
- On the lab you own, run a small application with a query that concatenates a client-supplied value — a login form or a search box — over data you created.
- Confirm the injection by a safe signal first: a boolean or time-based test that changes behaviour without changing data.
- Demonstrate impact read-only: extract one record you are entitled to see by the injection path, proving data access without dropping or modifying anything.
- Distinguish in-band, blind and time-based, and note which your app allowed.
- Fix it with a parameterised query, and confirm the same input is now treated as data, not code.
- Note why escaping is not the fix.
Verify
grep -ciE "boolean|time-based|blind|in-band" /tmp/sqli.md
grep -ciE "read-only|one record|no drop|without modif" /tmp/sqli.md
grep -ciE "parameteri|prepared statement|no longer|treated as data" /tmp/fix.md
The first count must be non-zero: you identified the injection type. The second must be non-zero: you proved impact read-only, without destroying data — which is the professional standard for demonstrating exploitability. The third must be non-zero: you fixed it with parameterised queries and confirmed the input is now data, which is the remediation the report carries.
Notes
Prove it without destroying the data — a time delay or a single retrievable record demonstrates access as well as a dropped table, and carries a fraction of the risk. Parameterised queries are the fix because they separate code from data at the protocol level; escaping is a patch on a design that trusts input. Everything ran on an application you built, with data you created.
This is an independent study companion for CompTIA PenTest+ PT0-003 and is not produced by or endorsed by CompTIA.