Improving Accuracy of the Testing

CHAPTER 4. DETECTION OF SQL INJECTION VULNERABILITIES

SELECT * FROM users WHERE

name=’ø₁’ and id=ø₂ and password=’ø₃’(ø_i: target slot).

The ø₁ and ø₃ pair is appropriate for the target slots for a combination attack, because when ø1 is exploited by a backslash, thenamefield in the SQL query is:

“’ and id=ν2 and password=” (νi: a value for ø_i),

in which the value for ø2is incorporated into thenamefield in the SQL query. Thus, if a target slot that is not enclosed in quotes exists between a pair of target slots, the pair can also be a target slot for a combination attack.

For detecting vulnerabilities against another variant of combination attacks, a mutli-byte SQL injection, Sania executes a singular attack with an attack code containing only a single quote. The reason why Sania only executes a singular attack but not a combination attack is because the vulnerability of a multi-byte SQL injection can be detected only by observing how the single quote is processed in the web application.

Although a safe web application modifies a single quote into a set of two single quotes or a set of a backslash and a single quote, if another string is generated, it may become vulnerable. Because of this reason, Sania checks a suspicious character or a byte before the injected single quote in the resulting SQL query, as well as checking the structural change of the SQL query.

Table 4.3: Sania-attributes to improve the accuracy of testing

Name Purpose

length-attribute To limit the maximum length of an attack code equivalent-attribute To apply the same value to multiple fields

skip-attribute To exclude user-specified parameters from testing preserve-attribute To detect a vulnerability of stored SQL injection structure-attribute To accept the change of tree structure of SQL query

Sania-attributes as shown in Table 4.3, and introduce them in order. In the current implementation, users input Sania-attributes through its graphical user interface (GUI).

4.2.4.1 Length Attribute

A database defines the maximum character length of a column (or a field in some databases). An attack code longer than the maximum length will be rejected by the database without executing the SQL query. To suppress the creation of such non-executable attacks, Sania allows the users to specify the maximum length of an attack code to be generated. Alength-attributeis used to specify the maximum length so that Sania does not create an attack code longer than that specified by the length-attribute.

4.2.4.2 Equivalent Attribute

In some web pages, a client needs to enter the same data into several input fields. For example, a web page has a password field and its confirmation field to which the same password must be entered. If these do not match, the web application rejects the request and Sania can not reach the web page of interest. Sania allows the user to attach an equivalent-attribute to HTTP parameters. By attaching an equivalent-attribute, Sania inserts the same data into the parameters.

4.2.4.3 Skip Attribute

Sania excludes HTTP parameters from testing, if a skip-attribute is attached to the HTTP parameters. This attribute is useful for stateful parameters described in Sec-tion 4.2.1. By attaching a skip-attribute to the stateful parameters, Sania can skip testing against them.

4.2.4.4 Preserve Attribute

To deal with astoredSQL injection presented in Section 2.1.3, Sania introduces preserve-attribute. A preserve-attribute is attached to the parameter whose value appears in a later SQL query triggered by another request. Sania records all the requests between

CHAPTER 4. DETECTION OF SQL INJECTION VULNERABILITIES

Table 4.4: Structure-attributes and their acceptable expressions

Name Acceptable expressions

arithmeticExpression Number/mathematical statements

conditionalExpression Conditional statements such as AND/OR statements relationalExpression Relational statements used to compare two values,

such as LIKE and IS NULL statements

notExpression Statements that can accept NOT expression, such as BETWEEN, IN, and LIKE statements

subSelectExpression Statements that can accept sub-SELECT expres-sions, such as JOIN and FROM statements

the request containing a preserve-attribute and the request that triggers the SQL query.

To send an attack, Sania sends all the recorded requests and checks for a vulnerability in the SQL query of interest. For example, a request R₁ contains a parameter p₁ but does not trigger any SQL query. The second requestR2neither contains any parameter nor triggers any issue of an SQL query. The third request R₃ has no parameters but issues an SQL query that contains p₁. In this example, Sania can not identify p₁ in the SQL query triggered byR3, thus requires users to specify preserve-attribute. Sania regenerates the requests (fromR₁ toR₃) after sending the attack, and checks the SQL query afterR₃.

4.2.4.5 Structure Attribute

We also added another Sania-attribute to optimize the tree validation for a special case that we encountered during the preliminary experiments. We found an example where the structure of a dynamically generated SQL query depends on the client’s inputs, even though there was no vulnerability. The web application issues the following SQL query and øcan hold an arbitrary arithmetic expression as well as a number:

SELECT * FROM users WHERE id=ø(ø: target slot).

The structure of this SQL query changes according to the value of ø, because an arith-metic expression, for example “1 + 2”, is expressed as a subtree composed of two number nodes. In case a number is applied to ø, the tree for øis expressed with only a number node. Because of this, Sania judges the application to be vulnerable to SQL injection even though it is not vulnerable. To avoid this problem, Sania allows the user to attach astructure-attributeto an HTTP parameter, which enables the user to specify several acceptable subtrees. Table 4.4 lists structure-attributes. In the above example, the user can associate an arithmeticExpressionattribute with theidfield to let it contain an arbitrary arithmetic expression.

Sania User

HTTP proxy

SQL proxy web application

database Browser

intercept

SQL query Innocent HTTP request

intercept

core

use Sania

User core

specify Sania-attribute

attack

Sania

web application

database SQL query

intercept

core 3. Checking vulnerabilities

send GUI

HTTP proxy SQL proxy

GUI 2. Generating attacks

attack rule Sania-attribute

create 1. Identifying

target slots HTTP req.

SQL query

HTTP proxy

SQL proxy GUI

SQL query

Figure 4.2: Implementation and vulnerability detection process of Sania 4.2.4.6 Automated Deletion of Inserted Data

Additionally, we also found a case where Sania needs to delete successfully injected attack codes from database before executing the subsequent attacks. A web page, such as a user registration page, issues an SQL query to insert user-supplied data into the database. If Sania embeds an attack code into the data, the attack code is stored in the database and will adversely affect subsequent attack results. For example, the web site initially checks the database for the user ID specified in an HTTP request. If the user ID is not in the database, an SQL query is issued to insert the new user information.

Otherwise, the SQL query is not issued and we cannot execute testing of any value in the SQL query.

To avoid this, every data inserted into the database has to be deleted before the next attack gets started. Suppose a web application issues an insert statement shown below and the id column is defined to be unique.

INSERT INTO users(id,name) VALUES (333,’ø’)(ø: target slot).

This SQL query inserts a new user’s information with his id and name values. Since the id value is already made by the innocent request, Sania needs to delete the inserted data for preventing duplication errors at the database. To this end, Sania automatically analyzes the insert statement sent to the database for constructing another SQL query that deletes the inserted data as follows.

DELETE FROM users WHERE id=333 and name=’ν’(ν: the value for a target slot).