SQL Injection Series:SQL Injection Mechanisms

SQL Injection Series

·                 -         Introduction

·         SQL Injection Mechanisms

·         Impact of SQL Injection

·         Exploitation of SQL Injection Techniques

·         Test/Detect SQL Injection

·         Prevention from SQL Injection

Malicious SQL statements can be introduced into a vulnerable application using many different input mechanisms. In this section, we explain the most common mechanisms.

Injection through user input : In this case, attackers inject SQL commands by providing suitably crafted user input.
 A Web application can read user input in several ways based on the environment in which the application is deployed. In most SQLIAs that target Web applications, user input typically comes from form submissions that are sent to the Web application via HTTP GET or POST requests .Web applications are generally able to access the user input contained in these requests as they would access any other variable in the environment.
Injection through cookies:
 Cookies are files that contain state information generated by Web applications and stored on the client machine. When a client returns to a Web application, cookies can be used to restore the client’s state information. Since the client has control over the storage of the cookie, a malicious client could tamper with the cookie’s contents. If a Web application uses the cookie’s contents to build SQL queries, an attacker could easily submit an attack by embedding it in the cookie.
Injection through server variables:
Server variables are a collection of variables that contain HTTP, network headers, and environmental variables. Web applications use these server variables in a variety of ways, such as logging usage statistics and identifying browsing trends. If these variables are logged to a database without sanitization, this could create SQL injection vulnerability . Because attackers can forge the values that are placed in HTTP and network headers, they can exploit this vulnerability by placing an SQLIA directly into the headers. When the query to log the server variable is issued to the database, the attack in the forged header is then triggered.
Second-order injection:
In second-order injections, attackers seed malicious inputs into a system or database to indirectly trigger an SQLIA when that input is used at a later time. The objective of this kind of attack differs significantly from a regular (i.e., first- order) injection attack. Second-order injections are not trying to cause the attack to occur when the malicious input initially reaches the database. Instead, attackers rely on knowledge of where the input will be subsequently used and craft their attack so that it occurs during that usage. To clarify, we present a classic example of a second order injection attack. In the example, a user registers on a website using a seeded user name, such as “admin’ -- ”. The application properly escapes the single quote in the input before storing it in the database, preventing its potentially malicious effect. At this point, the user modifies his or her password, an operation that typically involves (1) checking that the user knows the current password and (2) changing the password if the check is successful. To do this, the Web application might construct an SQL command as follows:

queryString="UPDATE users SET password=’" + newPassword +
"’ WHERE userName=’" + userName + "’ AND password=’" +
oldPassword + "’"

newPassword and oldPassword are the new and old passwords, respectively, and username is the name of the user currently logged-in (i.e., ‘‘admin’--’’ ). Therefore, the query string that is sent to the database is (assume that newPassword and oldPas –sword are “newpwd” and“oldpwd”):

UPDATE users SET password=’newpwd’
WHERE userName= ’admin’--’ AND password=’oldpwd’

Because “--” is the SQL comment operator, everything after it is ignored by the database. Therefore, the result of this query is that the database changes the password of the administrator (“admin”) to an attacker-specified value.
In Next Part of the SQL Injection Series we will go through the Impact of SQL Injection