SQL Injection Explained: How One Text Box Can Expose a Database

The 30-second explanation

Websites keep things like accounts and orders in a database, and they talk to it in a language called SQL. SQL injection happens when a site builds those database commands by pasting in whatever a visitor typed. A visitor who types something clever can change what the command means, and the database does what it is told. A search box or login form becomes a way to read data the site never meant to hand out.

How it works

1. 1

   1. Input

   A visitor types text into a form, a search box or a parameter in a web address.

2. 2

   2. Concatenation

   The site pastes that text directly into a database command instead of passing it as data.

3. 3

   3. Rewrite

   A character like a quote mark ends the intended text early, and the remainder is read as database instructions.

4. 4

   4. Exposure

   The database returns, changes or deletes data the page was never meant to touch.

Take a login form. Behind it, the site runs a query that amounts to this: find the user whose name matches what was typed and whose password matches what was typed. On a vulnerable site, the code builds that query by joining the visitor's text straight into the command. Most of the time the text is an ordinary name and everything works. But the database reads the finished string as one piece. If the input contains a quote mark and a little extra logic, the quote ends the text early and the rest is read as part of the command. The attacker has now rewritten the question the site asks its own database, for example to make the password check always succeed or to return a different table. The cause is always the same: data and instructions travelling mixed together. The fix is to keep them apart. With parameterised queries the command is sent first with empty slots, and the visitor's values are sent separately and handled only as data, so nothing typed can change what the command does.

Real-world example

How to spot it

• Database errors on screen

  A page that shows raw SQL or database error text after odd input is passing that input to the database.

• Logins that behave strangely

  Sign-ins that succeed without a correct password, or fail only for names containing quote marks.

• Odd strings in the logs

  Web or database logs full of long, strange search terms, quote marks, or repeated probing of the same parameter.

• Unexpected amounts of data

  A page that normally shows ten results suddenly returns far more, or content from a different table.

What to do

1. 1Use parameterised queries (prepared statements) for every database call, including internal tools, and never build queries by joining strings.
2. 2Give the web application's database account only the permissions it needs, so one flaw cannot read unrelated data or drop tables.
3. 3Hash stored passwords with a slow, salted algorithm, switch off detailed database errors in production, and test regularly for injection flaws.