Skip to main content

Wolfcore Cyber Security

Try our phishing simulations free for 14 days. Start free trial →
Get Started

SQL injection: what it is, real cases and prevention

In one sentence: SQL injection is when an attacker types database commands into a website form or link and the website runs them, letting the attacker read or change data they should never see.

What it is

Websites store customers, orders and logins in a database, and talk to it in a language called SQL. SQL injection happens when a website builds a database command by pasting in text a visitor supplied, so the database cannot tell the website’s instructions from the visitor’s input.

The NCSC says an innocent field on a web page can let an attacker extract or modify the entire backing database, or even run code as the database server. It has been around for nearly 30 years and OWASP lists injection among its top risks.

How it works

  1. The attacker finds an input the site passes to its database, such as a search box, login form or URL parameter.
  2. They enter text that changes the meaning of the database command, not just the data inside it.
  3. The database runs the changed command. OWASP lists the consequences: loss of confidentiality, login bypass without knowing a password, and changes to stored authorisation data.
  4. The attacker widens it, reading other tables or changing records.

A harmless illustration of the weakness and the fix:

# Vulnerable: text is pasted into the command
query = “SELECT * FROM users WHERE name = ‘” + name + “‘”

# Fixed: a parameterised query keeps data and command apart
query = “SELECT * FROM users WHERE name = ?”
run(query, [name])

OWASP says parameterised queries are the primary defence, because the value is treated as data and cannot change the command.

Who it affects and how badly

Any organisation with a website or app that uses a database, including custom web shops, portals, booking systems and SaaS products. Legacy pages that nobody remembers are especially risky.

Small firms on custom or old sites risk stolen customer lists and a defaced or offline site. Mid-sized SaaS start-ups, recruitment platforms and retailers risk theft of personal data and lost client trust. Regulated firms such as fintech, insurers and telecoms face ICO or other regulator fines and mandatory breach reports. OWASP found some form of injection in testing across 94% of the applications it assessed, with an average incidence rate of 3.37%, in its 2021 data.

Real examples

TalkTalk, 2015. The ICO found that attackers used SQL injection against legacy web pages inherited from Tiscali. The personal details of 156,959 customers were accessed, including bank account numbers and sort codes of 15,656. The ICO found the database software was outdated, with a fix available for over three and a half years, and that two earlier SQL injection attacks in July and September 2015 had gone unaddressed. It fined TalkTalk £400,000. Source: https://ico.org.uk/about-the-ico/media-centre/talktalk-cyber-attack-how-the-ico-investigation-unfolded/

MOVEit Transfer, 2023. CISA says the CL0P group exploited a previously unknown SQL injection flaw (CVE-2023-34362) in MOVEit Transfer from 27 May 2023 to steal data. Source: https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a

How to detect it

  • Look in web server and application logs for requests containing unusual quote characters, SQL keywords or very long parameters, and for sudden database errors.
  • Watch for sudden spikes in database load, large result sets or a new database account activity pattern.
  • Run a free scan of your site, and ask for a manual test of any form that touches a database.
  • Turn on database auditing and alert on queries from the application account that touch tables it should not.
  • Keep an inventory of old pages. The ICO’s TalkTalk finding shows forgotten pages are a risk.

How to fix or prevent it

  1. Use parameterised queries (prepared statements) for every database call. OWASP calls this the primary defence.
  2. Never rely on manual escaping or on checking input alone. OWASP says validated data is still not safe to paste into SQL.
  3. Where a value cannot be a parameter, such as a column name, map user choices to a fixed list you wrote.
  4. Give the application database account least privilege so a successful attack does less damage.
  5. Patch databases and frameworks. TalkTalk’s fix had been available for years.
  6. Remove unused pages and test environments from the internet.
  7. Test with a manual penetration test and code review.

Related terms

Browse all entries in the web application security hub.

FAQ

What is the best defence against SQL injection? OWASP says parameterised queries, which keep data separate from the database command.

Is input validation enough? No. OWASP says validated data is not necessarily safe to insert into SQL by string building.

Has it caused big fines? Yes. The ICO fined TalkTalk £400,000 after a SQL injection attack in 2015.

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. Start with the free web vulnerability scan at wolfcore.co.uk/free-web-vulnerability-scan and see Wolfcore penetration testing.