SQL Injection: Everything You Need to Know

Accepting input from users is a core requirement for many applications. But what if threat actors lurk among your users and inject malicious commands into your app? In that case, your app has suffered a SQL injection attack. Depending on how it responds, attackers may be able to use SQL injection to steal sensitive information, destroy important data, and potentially even take control of the application and the system that hosts it. Fortunately, there are steps that developers and security teams can take to protect against SQL injection. This article unpacks them by explaining everything modern organizations need to know about SQL injection.

What is SQL injection?

SQL injection attack is an attack where threat actors insert malicious commands into an application using SQL, a language commonly used for interacting with databases. Normally, SQL commands enable applications to read and write data from databases for legitimate purposes. But if attackers are able to "trick" an application into running SQL commands designed to enable malicious actions – such as displaying information from a database that should not be visible to application users – they can cause harm.

SQL injection methods

There are three main types of SQL injection attacks, each of which uses a different method to inject malicious input into an application:

• In-band injection: Attackers inject code into an application and view results through the same interface. This is the simplest type of SQL injection.
• Out-of-band injection: The attacker injects code into the application, and then relies on special database features, like the ability to transfer data via HTTP, to obtain sensitive information.
• Blind injection: Instead of injecting code that causes the application to display sensitive data from a database, the attacker injects commands designed to evaluate how the database is structured or configured. This information can help attackers learn more about a database so that they can in turn craft code for other types of SQL injection attacks.

SQL injection example

As an example of SQL injection, imagine a Web application that asks users to log in by entering a username into a text box and a password into another text box. After a user submits this information, the application reads the values from the text boxes and stores them as the following variables:

• user, for the username
• pass, for the password

Based on these variables, the application generates a SQL query and sends it to a database to check whether the username and password match those of a legitimate account. The query might look like this: SELECT * FROM Customers WHERE CustomerName ="' + user + '" AND Password ="' + pass + '" As long as the username and password that the user entered are legitimate, the database will return a result that the application can use to determine whether the user actually has an account and whether the password for the account is correct. But now, imagine that instead of entering legitimate text into the username and password fields in the app, an attacker enters the following into each text box: " or ""=" In this case, the values for user and pass have each become " or ""=". Consequently, the SQL query that the application generates is: SELECT * FROM Customers WHERE CustomerName ="" or ""="" AND Password ="" or ""="" This code will cause the database to display all of the data stored in the database table labeled Customers. If the data appears on a page that the attacker can view, the attacker has successfully accessed potentially sensitive information about the business's customers. Note that the consequences of SQL injection aren't limited to the exposure of sensitive data. Attackers could also use this technique to obtain usernames and passwords for admin accounts if those accounts are stored in a database that is connected to a vulnerable application. They could then log into the application as privileged users, allowing them to conduct a variety of other malicious activities that extend beyond simply accessing sensitive information.

What causes SQL injection?

Most SQL injection vulnerabilities result from an application's failure to validate input properly. If attackers insert malicious SQL commands into an input field and the application simply passes those commands onto a database without checking whether the input contains malicious commands or other data, the attack is likely to be successful. For example, in the scenario above where an application was vulnerable to SQL injection when attackers enter the string " or ""=" into text boxes, the application could stop the attack by checking whether the input actually resembles usernames and passwords. Normally, characters like ' would not be part of a username, so detecting unusual values in the username field would be easy. Catching the malicious string in the password field would be harder because the set of legitimate characters that could be part of passwords is larger. But if the application compared the input in the password field to a list of commands commonly used in SQL attacks, or looked for patterns that resemble SQL commands (such as strings separated by the ' character and whitespaces), it could detect the malicious code. Unfortunately, however, basic input validation isn't always enough to prevent SQL injection. Sophisticated attackers can use special techniques to bypass standard validations. For example, many SQL commands include the characters ' or " because they are typically used to identify values that may appear inside a database table. For that reason, scanning input for these characters is a common way to detect SQL injection attempts. But in certain cases (such as a command that targets a column with a numeric name), it's possible to write valid SQL statements without using the ' or " characters – which means that checking for these characters would not block all attacks.

How to prevent SQL injection

Because of these complications, there is no simple way of detecting every potential SQL injection vulnerability. But the following measures are effective for stopping most attacks:

• Validate application input as thoroughly as possible, being sure to consider all potential edge cases and attack scenarios.
• Where possible, restrict the maximum length of data input. This makes it harder for attackers to inject malicious commands, which are often longer than strings like usernames. 
• Scan source code to detect any instances where an application accepts input without validating it.
• Test applications for SQL injection vulnerabilities by attempting to insert malicious commands into the applications in a test environment and evaluating how the applications respond.
• Limit the output displayed on the screen when an application interacts with a database.

Stopping SQL injection with Checkmarx

When it comes to detecting SQL injection risks, Checkmarx has you covered. Checkmarx helps protect your application from code-to-cloud using the Checkmarx One platform. Using Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), teams can discover SQL injection and other vulnerabilities in both source code and runtime environments. Plus, Checkmarx Software Composition Analysis (SCA) extends SQL injection defenses to your software supply chain by identifying dependencies subject to SQL injection attacks and other risks. Learn more by requesting a demo.