SQL Query Injection

What is SQL Injection?
The ability to inject SQL commands into the database engine through an existing application (i.e. Client supplied data passed to an application without appropriate validation) Processed as commands by the database

       Ho w does SQL Injection work?

       Common vulnerable login query

 SELECT * FROM users     WHERE login = 'victor'     AND password = '123'

        (If it returns something then login!)

       ASP/MS SQL Server login syntax

the codes for implementing the same.

Var sql = "SELECT * FROM users

WHERE  login = '" + formusr + "' 
 AND password = '" + formpwd + "'"; 

formusr = ' or 1=1 – –

formpwd = anything

 Final query would look like this:

SELECT * FROM users WHERE username = ' ' or 1=1– – AND password = 'anything'

Intents

Attacks can also be characterized based on the goal, or intent, of the attacker. Therefore, each of the attack type definitions that we provide in Section 4 includes a list of one or more of the attack intents defined in this section.

1) Identifying injectable parameters: The attacker wants to probe a Web application to discover which parameters and user-input fields are vulnerable to SQLIA.

2) Performing database finger-printing: The attacker wants to discover the type and version of database that a Web application is using. Certain types of databases respond differently to different queries and attacks, and this information can be used to “fingerprint” the database. Knowing the type and version of the database used by a Web application allows an attacker to craft database specific attacks.

3) Determining database schema: To correctly extract data from a database, the attacker often needs to know database schema information, such as table names, column names, and column data types. Attacks with this intent are created to collect or infer this kind of information.

4) Extracting data: These types of attacks employ techniques that will extract data values from the database. Depending on the type of the Web application, this information could be sensitive and highly desirable to the attacker. Attacks with this intent are the most common type of SQLIA.

5) Adding or modifying data: The goal of these attacks is to add or change information in a database.

6) Performing denial of service: These attacks are performed to shut down the database of a Web application, thus denying service to other users. Attacks involving locking or dropping database tables also fall under this category.

7) Evading detection: This category refers to certain attack techniques that are employed to avoid auditing and detection by system protection mechanisms.

8) Bypassing authentication: The goal of these types of attacks is to allow the attacker to bypass database and application authentication mechanisms. Bypassing such mechanisms could allow the attacker to assume the rights and privileges associated with another application user.

9) Executing remote commands: These types of attacks attempt to execute arbitrary commands on the database. These commands can be stored procedures or functions available to database users.

10) Performing privilege escalation: These attacks take advantage of implementation errors or logical flaws in the database in order to escalate the privileges of the attacker. As opposed to bypassing authentication attacks, these attacks focus on exploiting the database user privileges.

       Sources of SQL Injection

       1)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 [14]. Web  applications are generally able to access the user input contained in these requests as they would access any other variable in the environment.

      2)Injection through cookies: Cookies are files that contain state information generated byWeb 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 [8].

      3)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 an SQL injection vulnerability [30]. 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.

       4)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., firstorder) 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 (taken from [1]). 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.

       Second-order injections can be especially difficult to detect and prevent because the point of injection is different from the point where the attack actually manifests itself. A developer may properly escape, type-check, and filter input that comes from the user and assume it is safe. Later on, when that data is used in a different context, or to build a different type of query, the previously sanitized input may result in an injection attack.