Cyber City · District 01: City Bank

SQL Injection Playground

Break into a real bank login, then defend it. No install, no account.

Every attempt runs against a genuine SQL engine in your browser — not a script checking your answer. That is why real payloads work here and typos in the middle of one still fail.

Red Team: this login builds its query by pasting your text straight into the SQL, so your input can become code. That is the vulnerability — break in.

City Bank — Staff Login

The query your input builds

Rows the database returned

🏦 City Bank open
☕ Coffee Shop
⚡ Power Grid
🏥 Hospital
💀 Ransomware HQ

How SQL injection works

SQL injection is a vulnerability that happens when an application builds a database query by pasting user input straight into the query text. The database cannot tell the developer's code apart from the visitor's characters, so a carefully chosen input changes what the query means.

A login form is the classic example. Vulnerable code often looks like this:

query = "SELECT * FROM users
         WHERE username = '" + username + "'
         AND password = '" + password + "'"

Type ' OR '1'='1' -- into the username box and the database actually receives:

SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = ''

The ' closes the developer's string early, OR '1'='1' is always true, and -- comments out the rest — including the password check. Every row now matches, so the app logs you in. In the playground above this really happens: the rows are what a real SQL engine returned.

Most "SQL injection simulators" only compare your text against a hard-coded answer, so a slightly different attack silently fails. This one runs a genuine SQL engine in your browser — press Prove it's real and it bypasses the login with a randomly generated attack that could not have been hard-coded.

The Red Team challenges

1. Bypass the login

Make the WHERE clause always true. The classic payload is ' OR '1'='1' --; leave the password blank, since the comment removes it.

2. Log in as the admin

A blanket bypass returns everyone. To return only the administrator, target that row: admin' -- authenticates as admin with the password check commented out.

3. Discover the hidden table

Attackers map the database. A UNION SELECT appends a second result set, letting you read the list of tables from sqlite_master. There is a second table here — find its name.

4. Exfiltrate the vault PIN

Once you know the hidden table's name, dump it through the login box with another UNION SELECT, matching the five columns of the original query. This is how a login bug becomes a data breach.

The Blue Team fix

Switch to Blue Team and the login uses a parameterised query (a prepared statement). The query structure is sent first with placeholders; the input is sent separately and can only ever be data, never code:

SELECT * FROM users WHERE username = ? AND password = ?
-- bindings: [username, password]

Now ' OR '1'='1' -- just looks for a user literally named ' OR '1'='1' --. None exists, so the attack fails while real logins still work — exactly what you see in Blue Team mode.

Blacklisting the apostrophe, escaping by hand, or hiding error messages all reduce symptoms without removing the cause, and each can be bypassed. Parameterise the query.

Is this legal to practise on?: Yes. Everything runs on a fake database inside your own browser — you are not touching any real system. Practising injection on systems you do not own is illegal; this exists so you never have to.
Do I need to install anything or sign in?: No. Nothing to download, no account. Refresh and the database resets.
Is the SQL engine real?: Yes — it tokenises, parses and executes real SQL. The "Prove it's real" button bypasses the login with a randomly generated attack that cannot have been pre-programmed.

Ready for more depth? The PortSwigger Web Security Academy runs free server-side labs across dozens of vulnerability classes. This playground is the fastest way to grasp the mechanics first.