SQL Injection

• SQLi is among the oldest and most damaging classes — one input box can give an attacker the whole table.
• Understanding it in depth teaches you how interpreters work, which explains every other injection family too.
• Modern ORMs remove the obvious cases, so the interesting bugs are in dynamic SQL, admin consoles, and query builders.

The field expected a name; the attacker typed instructions the clerk (the DB) could not tell apart.

• The app builds 'SELECT * FROM users WHERE id = ' + input, and input is attacker territory.
• An attacker feeds '1 OR 1=1' so the WHERE always matches; '1; DROP TABLE x' shows up when stacked statements are allowed.
• Blind variants don't return data visibly: the attacker infers truth from timing, error text, or page differences.
• The fix is structural: bind parameters as data to the prepared statement so the DB can never confuse them with syntax.

• A data-heavy app migrates every 'WHERE id =' + var to a prepared statement, then runs a regex sweep for remaining concatenation.
• A DB account used by the app is granted only SELECT/INSERT on its own schema, so even a successful injection has no DROP rights.
• A WAF's detection rule catches the classic payloads, but the real defense (parameters) is what the team enforces in code review.

• Never build SQL from strings with user input — parameterized/prepared statements or safe ORMs only.
• Give the app a least-privilege DB account; injection inside a schema you can't break is a small compromise.
• Allow-list input formats (ids are integers, not free text) and validate server-side, not client-side.
• Run SAST and grep for query string concatenation as a cheap, constant audit.

• Relying on a WAF to 'block injection' while the app still concatenates impossible-to-fix inputs.
• Using 'magic quotes'-style escaping instead of parameterization — escaping is a race you eventually lose.
• Leaving verbose DB error messages on in production, handing attackers your schema and query shapes.
• Writing new dynamic SQL 'just this once' for an admin tool that nobody remembers to audit.

• Reproduce with the minimal repro: a single GET with id=1' and watch the error text change to confirm the injection point.
• Audit with grep for 'SELECT' + operators in the codebase; every hit is a candidate needing parameterization.
• Compare query output between id=1 and id=1 AND 1=1 to detect blind cases in your own API responses.

• Exercise SQLi ONLY on your own DVWA-style lab app; probing production databases is a criminal act and catastrophic to data.
• Store query templates in code review: a query change without a parameterization review is a change worth blocking.
• Monitor DB roles and error logs; your earliest SQLi signal often shows up as unusual statements in the audit trail.