Level 05 · Second-order Injection

Plant once, trigger later

This is the sneaky one. The INSERT below uses parameterized queries — looks safe, would pass code review. But the search-by-author handler later concatenates the stored value back into a new query. The bug is in the read path, not the write path. Plant a payload, then trigger it.

Objective

Plant a comment with a malicious author, then trigger an injection by searching for that author. Successfully exfiltrate data via UNION through the search.

Loading SQLite engine

Step 1 · Plant a Comment (parameterized INSERT — looks safe)

Author (plant a payload like x' UNION SELECT label, value, 'X' FROM secrets --)

Content

Step 2 · Search by Author (vulnerable concat — triggers stored payload)

Search author name

Live Query · Results

SQL EXECUTED

// Plant a comment, then search for it

All Comments

Walkthrough

In Step 1, set Author to: x' UNION SELECT label, value, 'X' FROM secrets -- — click Plant.
The comment is stored using a parameterized INSERT. Nothing bad happens here. The author field literally contains that weird string.
In Step 2, search for that exact author name — paste the same string into the search box.
Watch the search query concatenate the stored value, the UNION fires, and the secrets table leaks through the search results.
Toggle Step 2 to Safe mode and search again — same stored data, no injection.

Why this is sneaky

[ THE BIGGER LESSON ]

A code reviewer looking at the insert handler would find nothing wrong:

# Looks safe — uses parameterized query
db.execute("INSERT INTO comments (author, content) VALUES (?, ?)", (author, content))

But somewhere else, in a totally different file, maybe written by a different person months later, this exists:

# The actual bug
query = f"SELECT id, author, content FROM comments WHERE author = '{search_author}'"
db.execute(query)

This is why "sanitize on input" doesn't work as a strategy. You can't predict every context the data will eventually be used in. Stripping quotes on insert doesn't help if some other code path reads the raw value back from the DB and concatenates it into another query.

The right rule — parameterize at every point where data crosses into SQL, regardless of where the data came from. Treat data from your own database with the same suspicion as data from a user. Because at some point, all of it was data from a user.