Web Application Environment
Before we drive into a discussion on the approaches to detect and prevent SQL injection attacks, let’s first explore the Web application environment. Web application information is presented to the Web server by the user’s client, in the form of URL’s, cookies and form inputs (POSTs and GETs). These inputs drive both the logic of the application and the queries those applications create and send to a database to extract relevant data. Unfortunately, many applications do not adequately validate user input and are thus susceptible to SQL injection. Attackers capitalize on these flaws to attempt to cause the backend database to do something different than what the application (and the organization) intended. This can include extracting sensitive information, destroying information or executing a denial of service (DoS) attack that limits others’ use of the application.
SQL Injection Attack Overview
SQL injection attacks are initiated by manipulating the data input on a Web form such that fragments of SQL instructions are passed to the Web application. The Web application then combines these rogue SQL fragments with the proper SQL dynamically generated by the application, thus creating valid SQL requests. These new, unanticipated requests cause the database to perform the task the attacker intends. To clarify, consider the following simple example. Assume we have an application whose Web page contains a simple form with input fields for username and password. With these credentials the user can get a list of all credit card accounts they hold with a bank. Further assume that the bank’s application was built with no consideration of SQL injection attacks. As such, it is reasonable to assume the application merely takes the input the user types and places it directly into an SQL query constructed to retrieve that user’s information. In PHP that 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 as a user entered 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 Mr. Smith. Now consider someone 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 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 becomes:
$query = “select accountName, accountNumber from creditCardAccounts where username=” or 1=1 — and password= anyThingsAtAll
The injection of the term, ‘ or 1=1 —, accomplishes two things. First, it causes the first term in the SQL statement to 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. The result is that 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. It should be noted that this simple example is just one of literally an infinite number of variations that could be used to accomplish the same attack. Further, there are many other ways to exploit a vulnerable application. We will discuss more of these attacks as we delve into the efficacy of various attack mitigation techniques.
Applications Vulnerable to SQL Injection