Lion Cipher Lab
Prevent SQL injection with parameterized queries (hands-on)
- AppSec / DevSecOps
- Intermediate
- ~45 min
- Free · no account required
Why it matters
In Part 1 you learned, on paper, why gluing user input into a SQL command is dangerous and why parameterized queries make it impossible. Reading that is not the same as believing it in your gut. This lab closes that gap: you build a small, deliberately vulnerable login program on your own machine, type the classic ' OR '1'='1 into it, and watch it hand back every account in the database — then you change a single line to a parameterized query, feed it the exact same input, and watch the attack simply stop working. That before-and-after, run with your own hands on your own toy app, is what…
What you'll learn
- building a tiny vulnerable login app on your own machine with Python and SQLite
- seeing a real SQL injection work: how ' OR '1'='1 turns one lookup into 'return every row'
- recognizing the exact dangerous line — user input concatenated into a query string
- rewriting a query as a parameterized (prepared) statement with a ? placeholder
- proving the fix by feeding the same malicious input and watching it fail
- explaining precisely why the parameterized version is structurally immune
- using allow-list validation for the parts a placeholder cannot cover (column and table names)
Steps in this lab
- From Part 1's paper to your own keyboard
- Set up: confirm Python works and make a folder
- Build the toy database (three fake users)
- Write the VULNERABLE login (the bug, on purpose)
- Prove the injection works (watch it dump every user)
- Fix it: one line becomes a parameterized query
- Re-test: confirm the injection is dead
- The one spot ? cannot cover: allow-list the rest
- What you did — and the reflex to keep