M_01/ A03:2021 — Injection

SQL Injection Visualizer

Type a payload on the left, watch the SQL transform in the middle, and read the attack analysis on the right. Flip Secure Mode to see why parameterized queries defeat the same input.

Developer intent: Authenticate the user only if username AND password match.
1.0 Viewport
Payload presets
Input is concatenated directly into a SQL string. Whatever the attacker types becomes part of the query.
2.0 Server-Side Logic
Vulnerable
// vulnerable: string concatenation
SELECT id, username, role FROM users
WHERE username = 'admin' --'
  AND password_hash = sha256('password123');
Final Query
SELECT id, username, role FROM users WHERE username = 'admin' --'
Outcome
✓ Logged in as admin. Password check bypassed.
users table
idusernamepassword_hashrole
1admin$2b$12$AbCd…admin
2alice$2b$12$EfGh…user
3bob$2b$12$IjKl…user
4carol$2b$12$MnOp…moderator
1 row(s) returned • ROW LEAK
3.0 Intelligence

What just happened

Authentication bypass via comment + tautology.

Logical flow

  • Comment operator (--, #) terminates the rest of the SQL.
  • Password predicate is never evaluated.
  • Query returns the first matching user (admin).
  • Parameterized queries treat input as data, not code.
Risk
Critical
What the developer thinks
The query checks username AND password.
Only the right user can authenticate.
Inputs are "just strings".
What the SQL parser actually sees
Two adjacent strings glued with quotes.
A terminating comment.
An always-true predicate.
Attack flow