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

There are a number of factors that conspire to make securely written applications a rarity. First, many applications were written at a time when Web security was not a major consideration. This is especially true of SQL injection. While recently SQL injection is being discussed at security conferences and other settings, the attack frequency of SQL injection only five or so years ago was low enough that most developers were simply not aware. In addition, the application may have been initially written as an internal application with a lower security threshold and subsequently exposed to the Web without considering the security ramifications. Even applications being written and deployed today often inadequately address security concerns. IBM’s X-Force project recently found that 47% of all vulnerabilities that result in unauthorized disclosures are Web application vulnerabilities. Cross-Site Scripting & SQL injection vulnerabilities continue to dominate as the attack vector of choice.1 Note that these reported vulnerabilities are for packaged applications from commercial software vendors. Vulnerabilities in custom applications were not reported. Since this software is generally not as carefully vetted for security robustness, it is reasonable to assume the problem is actually much bigger. According to Neira Jones, head of payment security for Barclays, 97% of data breaches worldwide are still due to an SQL injection somewhere along the line. 2 Interestingly, modern environments and development approaches create a subtle vulnerability. With the advent of Web 2.0 there has been a shift in how developers treat user input. In these applications input is rarely provided by a simple form that directly transmits the information into the Web server for processing. In many cases, the JavaScript portion of the application performs input validation so the feedback to the user is handled more smoothly. This often creates the sense that the application is protected because of this very specific input validation; therefore, the validation on the server side is largely neglected. Unfortunately, attackers won’t use the application to inject their input into the server component of the application. Rather, they leverage intermediate applications to capture the client-side input and allow them to manipulate it. Since the majority of the input validation is bypassed, the attacker can simply enter the SQL fragments needed to change the behavior of the database to accomplish their intent.

0/5 (0 Reviews)

LEAVE A REPLY

Please enter your comment!
Please enter your name here