Home / The SQL Injection Threat Study
Download: The SQL Injection Threat Study

What is SQL Injection Attack and How does the Attack Work?

SQL injection is a form of database attack typically executed through a web application. SQL injection attacks are accomplished by exploiting a vulnerability in the SQL generation process of a database-connected application. In the SQL injection attack a fragment of SQL code is entered (e.g. injected) into a data field on a web page form or directly into the URL. There are also examples of SQL injection that attacked the cookie values on a web page. If the data field containing the injected SQL is sucessfully processed by a vulnerable application, the result can be a rogue SQL statement being dispatched to the connected database. Rogue SQL statements attempt to access, modify, or delete content stored on the database that the attacker is not authorized to access. In extreme cases SQL injection attacks can gain control of the server on which the database resides, creating an even far greater security threat.

The SQL injection vulnerability manifests itself when code fragments are dynamically inserted by the application into the SQL query without the proper sanitization or parameterization. Although SQL injection attacks have been documented since the late 1990’s, this method of attack still accounts for a very large percentage of records breached each year. It's been estimated that over 20% of database connected applications have at least one SQL injection vulnerability.


SQL Injection Statistcs from the Ponemon SQL Injection Survery

  • 65% of respondents had experienced one or more SQL injection attacks that successfully evaded their perimeter defenses over the past 12 months
  • It required organizations an average of nearly 140 days to discover that a SQL injection attack had breached their databases
  • Nearly half of respondents (46%) were familiar with the term “WAF Bypass”
  • 88% of respondents had a favorable or very favorable opinion of the use of Artificial Intelligence (AI) technologies to detect SQL injection attacks
  • 44% of respondents utilize professional penetration testers to identify vulnerabilities in their IT systems; but only a third (35%) of those penetration tests were allowed to actually test for SQL injection vulnerabilities

SQL Injection Attack Tutorial with Examples

Assume a Web application that displays a simple form with input fields for user name and password. With these credentials the user can access a list of all credit card accounts they have with a bank. Further assume that the bank’s application is vulnerable to SQL injection attack.

It's relatively common for an application to take the input the user sends and place it directly into an SQL query that's constructed to retrieve that user's credentials. In PHP, for example, the query string would look something like this:

$query = “select accountName, accountNumber from creditCardAccounts where username='“.$_POST[“username“].“' and password='“.$_POST[“password“].“'“

Normally this would work properly when a user enters their credentials, say johnSmith and myPassword, and formed the query:

$query = “select accountName, accountNumber from creditCardAccounts where username='johnSmith' and password='myPassword'

This query would return one or more accounts linked to John Smith.
Now consider an individual with a devious intent. This person decides they want to see if they can access the account information of one or more of the bank's other customers. To accomplish this they enter the following credential into the form:

' or 1=1 -- and anyThingsAtAll

When this SQL fragment is inserted into the SQL query by the application it resolves to:

$query = “select accountName, accountNumber from creditCardAccounts where username='' or 1=1 -- and password= anyThingsAtAll

The purpose of the injected SQL fragment, ' or 1=1 --, is two fold. First, it causes the first term in the SQL statement to always be true for all rows of the query; second, the -- causes the rest of the statement to be treated as a comment and, therefore, ignored during run time. As a result all the credit cards in the database, up to the limit the Web page will list, are returned and the attacker has stolen the valuable information they were seeking.

The above example is just one illustration of literally an infinite number of variations that could be used to accomplish the same style of SQL injection attack.


SQL Injection Prevention

There is no single mechanism that truly offers strong SQL injection protection. Mounting a viable defense against SQL injection requires a comprehensive defense-in-depth strategy. This includes the following:

  • Deploy Continuous Monitoring
  • Enforce Coding Best Practices
  • Baseline Database Infrastructure
  • Disable Unnecessary Database Capabilities
  • Enforce Least Privileges
  • Apply Patches Regularly
  • Conduct Penetration Testing
  • Deploy Perimeter Security and Keep Signature Files Updated
  • Suppress Error Messages
  • Enforce Password Policies

Parameterized queries, perimeter security devices, and DAMs can collectively reduce your risks. However, protecting your databases against SQL injection attacks requires a defense-in-depth strategy that also includes continuous monitoring.