SQL Token Boundary Lab: Tokenizer, AST & Live Query Engine

Query Construction Mode

Attacker Payload

Playback speed 1.0x

Query Result

Idle — press Run Query.

AST nodes parsed

—

Rows returned

Payload re-tokenized?

—

Query phase

idle

How it works

This lab runs a real (if tiny) hand-written SQL tokenizer, recursive-descent parser and relational evaluator against actual sample tables — nothing here is a per-payload lookup table. In vulnerable mode the attacker's payload text is spliced directly into the query string before tokenizing: WHERE name='<payload>'. Whatever quotes, keywords or comment markers the payload contains become real tokens the parser assembles into the syntax tree. In parameterized mode the query text is fixed — WHERE name=? — and tokenized once regardless of the payload; the payload is bound afterward as a single opaque value compared byte-for-byte, and never re-enters the tokenizer.

tokenize(text) → [STRING, KEYWORD, IDENT, OP, PARAM, …]
parse(tokens)  → AST: SELECT{ columns, table, where, union? } | DROP{ table }
evaluate(AST, db) → rows, by walking the *same* tree against real sample data

The three canned payloads are genuine injection techniques, each producing a different AST shape and a different real result when evaluated against the sample users and payments tables below:

' OR '1'='1'-- — closes the string early, adds an OR branch whose two literal operands are always equal, so the WHERE clause is true for every row (comments out the trailing quote).
'; DROP TABLE users-- — the ; starts a second statement; a driver that allows stacked queries executes the DROP as real DDL, wiping the table.
' UNION SELECT card_no FROM payments-- — appends a second SELECT against an unrelated table; the engine's own UNION evaluator concatenates its rows onto the result, leaking payment data through a users-table query.

Because the payload literally never becomes text the parameterized tokenizer sees, its own AST is identical no matter which payload is selected — that structural invariance is exactly why prepared statements are OWASP's primary defense against SQL injection (CWE-89).

Code-plane token Payload-derived token AST node Matched / leaked row