What is SQL injection?

SQL injection: definition and cause

Web applications usually store customers, orders and content in an SQL database and query it with SQL commands. If such a command is built by simply inserting user input into the text, an attacker can alter the structure of the command. The database can then no longer tell code from data.

The cause is almost always the same: input from forms, search fields, cookies or address parameters is built into database queries unchecked. SQL injection has been part of the “Injection” category of the OWASP Top 10 for years, although the effective countermeasure has been known for a long time. It mainly affects older custom solutions and unmaintained plugins.

How an attack works

Instead of a search term, an attacker enters a snippet of text that alters the original query, for example so that a condition is always true. This can bypass login checks, read data from other tables or change entries, in extreme cases even delete them. Attackers use automated tools to test thousands of sites for such weaknesses; database error messages displayed unfiltered make their work easier.

• Data leakage: customer data, orders or credentials are read out
• Manipulation: prices, content or accounts are changed
• Bypass: logins are accepted without a valid password
• In the worst case: takeover of the database server or other systems

Real-world example: the old shop filter

A specialist retailer runs a web shop based on a custom-programmed legacy solution. The product filter builds the database query directly from the address parameter. An attacker changes the parameter and can thereby retrieve tables with customer data; the retailer only notices when customers receive fraud emails containing their real order details. The damage: loss of trust, effort and possibly reporting obligations.

The fix is plain craftsmanship: queries are converted to parameterized statements, the shop’s database privileges are restricted and error messages are hidden from the outside. A web application firewall offers additional protection but does not replace the fix in the code. After the incident, it remains to be clarified which data was affected.

Protective measures and imple­menta­tion

The most effective protection is prepared statements (parameterized queries), in which command and data stay strictly separated. ORMs and modern frameworks use them by default, as long as queries are not built by string concatenation. Input validation based on an allow list, a database user with minimal privileges, current software and targeted security tests help in addition.

Nano Concepts checks code and configurations with code reviews and vulnerability analyses, fixes flaws in existing applications and develops new software to secure standards from the start. For older custom solutions, gradual modernization is often advisable instead of permanent emergency repairs, so that security does not hinge on individual spots.

• Building SQL by concatenating user input
• Using a database user with admin privileges for the website
• Showing detailed database errors in the browser
• Relying only on input filters (“removing special characters”)
• Continuing to run outdated plugins and legacy scripts