Web applications are becoming more sophisticated and increasingly technically complex. They range from dynamic Internet and intranet portals, such as e-commerce sites and partner extranets, to HTTP-delivered enterprise applications such as document management systems and ERP applications. The availability of these systems and the sensitivity of the data that they store and process are becoming critical to almost all major businesses, not just those that have online e-commerce stores. Web applications and their supporting infrastructure and environments use diverse technologies and can contain a significant amount of modified and customized codes. The very nature of their feature-rich design and their capability to collate, process, and disseminate information over the Internet or from within an intranet makes them a popular target for attack. Also, since the network security technology market has matured and there are fewer opportunities to breach information systems through network-based vulnerabilities, hackers are increasingly switching their focus to attempting to compromise applications. SQL injection is an attack in which the SQL code is inserted or appended into application/user input parameters that are later passed to a back-end SQL server for parsing and execution. Any procedure that constructs SQL statements could potentially be vulnerable, as the diverse nature of SQL and the methods available for constructing it provide a wealth of coding options. The primary form of SQL injection consists of direct insertion of code into parameters that are concatenated with SQL commands and executed. A less direct attack injects malicious code into strings that are destined for storage in a table or as metadata. When the stored strings are subsequently concatenated into a dynamic SQL command, the malicious code is executed. When a Web application fails to properly sanitize the parameters which are passed to dynamically created SQL statements (even when using parameterization techniques) it is possible for an attacker to alter the construction of back-end SQL statements. When an attacker is able to modify an SQL statement, the statement will execute with the same rights as the application user; when using the SQL server to execute commands that interact with the operating system, the process will run with the same permissions as the component that executed the command (e.g. database server, application server, or Web server), which is often highly privileged. To illustrate this, let’s return to the previous example of a simple online retail store. If you remember, we attempted to view all products within the store that cost less than $100, by using the following URL:

• http://www.victim.com/products.php?val=100
The URL examples in this chapter use GET parameters instead of POST parameters for ease
of illustration. POST parameters are just as easy to manipulate; however, this usually involves the use of something else, such as a traffic manipulation tool, Web browser plug-in, or inline proxy application. This time, however, you are going to attempt to inject your own SQL commands by appending them to the input parameter val. You can do this by appending the string ‘OR ‘1’=
‘1
to the URL:
• http://www.victim.com/products.php?val=100’ OR ‘1’=‘1
This time, the SQL statement that the PHP script builds and executes will return all of the
products in the database regardless of their price. This is because you have altered the logic of the query. This happens because the appended statement results in the OR operand of the query always returning true, that is, 1 will always be equal to 1. Here is the query that was built and executed:

SELECT ∗
FROM ProductsTbl
WHERE Price < ‘100.00’ OR ‘1’ = ‘1’
ORDER BY ProductDescription;


There are many ways to exploit SQL injection vulnerabilities to achieve a myriad of goals; the success of the attack is usually highly dependent on the underlying database and interconnected systems that are under attack. Sometimes it can take a great deal of skill and perseverance to exploit a vulnerability to its full potential.
The preceding simple example demonstrates how an attacker can manipulate a dynamically created SQL statement that is formed from input that has not been validated or encoded to perform actions that the developer of an application did not foresee or intend. The example, however, perhaps does not illustrate the effectiveness of such a vulnerability; after all, we only used the vector to view all of the products in the database, and we could have legitimately done that by using the application’s functionality as it was intended to be used in the first place.

What if the same application can be remotely administered using a content management system (CMS)? A CMS is a Web application that is used to create, edit, manage, and publish content to a Web site, without having to have an in-depth understanding of or ability to code in HTML. You can use the following URL to access the CMS application:
• http://www.victim.com/cms/login.php?username=foo&password=bar
The CMS application requires that you supply a valid username and password before you
can access its functionality. Accessing the preceding URL would result in the error “Incorrect
username or password, please try again.” Here is the code for the login.php script:


// connect to the database
$conn = mysql_connect(“localhost”,“username”,“password”);
// dynamically build the sql statement with the input
$query = “SELECT userid FROM CMSUsers WHERE user = ‘$_GET[“user”]’ ”.
“AND password = ‘$_GET[“password”]’”;
// execute the query against the database
$result = mysql_query($query);
// check to see how many rows were returned from the database
$rowcount = mysql_num_rows($result);
// if a row is returned then the credentials must be valid, so
// forward the user to the admin pages
if ($rowcount ! = 0){header(“Location: admin.php”);}
// if a row is not returned then the credentials must be invalid
else {die(‘Incorrect username or password, please try again.’)}


The login.php script dynamically creates an SQL statement that will return a record set if a username and matching password are entered. The SQL statement that the PHP script builds and executes is illustrated more clearly in the following code snippet. The query will return the userid that corresponds to the user if the user and password values entered match a corresponding stored value in the CMSUsers table:

SELECT userid
FROM CMSUsers
WHERE user = ‘foo’ AND password = ‘bar’;

The problem with the code is that the application developer believes the number of records returned when the script is executed will always be zero or one. In the previous injection example, we used the exploitable vector to change the meaning of the SQL query to always return true. If we use the same technique with the CMS application, we can cause the application logic to fail. By appending the string ‘OR ‘1’=’1 to the following URL, the SQL statement that the PHP script builds and executes this time will return all of the userids for all of the users in the CMSUsers table. The URL would look like this:
• http://www.victim.com/cms/login.php?username=foo&password=bar’ OR ‘1’=’1
All of the userids are returned because we altered the logic of the query. This happens
because the appended statement results in the OR operand of the query always returning true, that is, 1 will always be equal to 1. Here is the query that was built and executed:

SELECT userid
FROM CMSUsers
WHERE user = ‘foo’ AND password = ‘password’ OR ‘1’ = ‘1’;

The logic of the application means that if the database returns more than zero records, we must have entered the correct authentication credentials and should be redirected and given access to the protected admin.php script. We will normally be logged in as the first user in the CMSUsers table. An SQL injection vulnerability has allowed the application logic to be manipulated and subverted. Do not try any of these examples on any Web applications or systems, unless you have permission (in writing, preferably) from the application or system owner. In the United States, you could be prosecuted under the Computer Fraud and Abuse Act of 1986

(www.cio.energy.gov/documents/ComputerFraud-AbuseAct.pdf) or the USA PATRIOT Act
of 2001. In the United Kingdom, you could be prosecuted under the Computer Misuse Act of
1990 (www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_1) and the revised Police and
Justice Act of 2006 (www.opsi.gov.uk/Acts/acts2006/ukpga_20060048_en_1). If successfully charged and prosecuted, you could receive a fine or a lengthy prison sentence

LEAVE A REPLY

Please enter your comment!
Please enter your name here