SQL injection

A SQL injection (SQLi) is a type of security exploit in which the attacker adds Structured Query Language (SQL) code to a Web form input box in order to gain access to unauthorized resources or make changes to sensitive data. An SQL query is a request for some action to be performed on a database. When executed correctly, a SQL injection can expose intellectual property, the personal information of customers, administrative credentials or private business details.

SQL injection attacks can be used to target any application that uses a SQL database, with websites being the most common prey. Common SQL databases include MySQL, Oracle and SQL Server.

The OWASP has listed SQL injection as one of the top threats to web application security. The risk of SQL injection exploits is on the rise because of automated tools. In the past, the danger was somewhat limited because an exploit had to be carried out manually. However, automated SQL injection programs are now available, and as a result, both the likelihood and the potential damage of an exploit has increased.

Example of how a SQL injection attack works

Software developers create SQL queries to perform database functions within their applications. Each query has an argument that ensures only desired records are returned when a user runs the query. In a SQL injection, attackers exploit this argument by injecting malicious code into the input form.

The first step of a SQL injection attack is to research how the targeted database functions. This is done by submitting a variety of random values into the argument field to observe how the server responds. The second step is using this information to craft an input value that the server will interpret and execute as a SQL command.

For example, a database may store information about customers that have made a purchase with customer ID numbers. Instead of searching for a specific customer ID, an attacker may insert the argument “CustomerID = 1000 OR 1=1” into the input field. Since the statement 1=1 is always true, the SQL query would execute to return all available customer IDs and any corresponding data.

In addition to returning unauthorized information, SQL arguments could be written that delete an entire database, bypass the need for credentials, remove records or add unwanted data.

Types of SQL injection attacks

SQL injections can be categorized in a few ways:

  • In-band SQLi- Also known as a classic SQLi, this is when hackers use the same channel of communication to launch and collect results from an attack. An in-band SQLi can be done through error-based or union-based queries. Error-based attacks force the database to produce error messages that reveal information about the structure of the database. Union-based attacks use prepared statements that exploit the “UNION” SQL operator in order to display data.
  • Inferential SQLi- Also known as a blind SQLi, this is when hackers send data payloads to a server to observe its response and behavior without being able to see the database. An inferential SQLi can be either Boolean or time-based. A Boolean SQLi uses true or false statements while a time-based SQLi sets a designated response period.
  • Out-of-band SQLi- This is when hackers take advantage of domain name system (DNS) or hypertext transfer protocol (HTTP) requests to handover data. An out-of-band SQLi is usually only performed when a server is too slow or when an in-band SQLi is not possible to execute.

How to detect and prevent a SQL injection attack

If a SQL injection attack is successfully carried out, the damage could be expensive in terms of resources and customer trust. That is why detecting this type of attack in a timely manner is important. Web application firewalls (WAF) are the most common tool used to filter out SQLi attacks. WAFs are based on a library of updated attack signatures and can be configured to flag malicious SQL queries.

In order to prevent a SQL injection attack from occurring in the first place, developers can follow these practices:

  • Avoid SQL statements that allow user input, choose prepared statements and parameterized queries instead.
  • Perform input validation, or sanitization, for user-provided arguments.
  • Do not leave sensitive data in plaintext format, or use encryption.
  • Limit database permissions, privileges and capabilities to the bare minimum.
  • Keep databases updated on security patches.
  • Routinely test the security measures of applications that rely on databases.
  • Remove the display of database error messages to the users.
This was last updated in August 2019

Continue Reading About SQL injection

Dig Deeper on DevSecOps and automated security