SQL blind note summary of Security red lines

Security red line SQL blind note summary

Security level: high

Security risks: data entries and tables may be viewed, modified, or deleted.

 Possible causes:

Hazard character clearing is not performed correctly for user input

Technical description:

Web applications usually use databases at the backend to interact with enterprise data warehouses. The standard language for database query is SQL (different database vendors have their own versions ). Web applications usually obtain user input (from an HTTP request), merge it into an SQL query, and then send it to the backend database. The application then processes the query results and sometimes displays the results to the user.

If the application is not careful enough to process user (attacker) input, attackers can use this method. In this case, attackers can inject malicious data. when the data is incorporated into an SQL query, the original query syntax is completely changed. For example, if the application uses user input (such as the user name and password) to query the database table of the user account to authenticate the user, however, attackers can inject malicious data into the user name (and/or password) of the query, and the query may be changed to a completely different data replication query, which may be a change to the database query, or run shell command query on the database server.

Generally, attackers can achieve this goal step by step. He will first learn the structure of the SQL query, and then use this knowledge to obstruct the query (by injecting data that changes the query syntax), so that the executed query is different from expected. Assume that the related query is:

Select count (*) from accountswhere username = '$ user' and Password =' $ pass'

$ User and $ pass are user inputs (collected from HTTP requests that call the constructed query script-they may be from GET request query parameters or POST request subject parameters ). The common usage of this query, whose values are $ user = John and $ Password = secret123. The resulting query is as follows: Select count (*) from accountswhere username = 'john' and Password = 'secret123'

If the user password is not matched in the database, the expected query result is 0. If such a pair exists (that is, the database named "John, and the password is "secret123"), the result is> 0. This is the basic authentication mechanism for applications. However, attackers can modify the query in the following ways.

An attacker can provide an input consisting of single quotes (') to send an error message to the database, which usually contains valuable information about SQL queries. An attacker only needs to include the user value 'in the sent request and include any value (such as foobar) in the password ). The result is the following (incorrectly formatted) SQL query: Select count (*) from accountswhere username = ''' and Password = 'foobar'

This may produce the following error message (depending on the specific database used by the backend ): A syntax error (operator omitted) occurs in the query expression 'username = ''' and Password = 'foobar ).
Then the attacker will know that the query is based on the expression username = '$ user' and Password =' $ pass. This key information is required when you use the SQL query at hand. After attackers understand the Query format, they only need to use:

User = 'or 1 = 1 or ''= 'password = foobar
The generated query is as follows:
Select count (*) from accounts where username = ''or 1 = 1or'' = ''and Password = 'foobar'

This indicates that the query (in the SQL database) returns true for each record of the "accounts" table, because the 1 = 1 expression is always true. Therefore, the query returns the number of records in "accounts", and the user (attacker) is also considered valid. This probe method has several variants, such as sending '; or \' (you should remember that almost all vendors have their own unique SQL "versions ". Specifically, sending 'having 1 = 1 will also generate an error message, which will leak information about the column name. In some cases, user input is not incorporated into the string context (enclosed in single quotes), but into the digital context, that is, embedded according to the current situation. Therefore, in this case, you can use the input string
1 having 1 = 1.

* Blind SQL Injection Technology:

The general method to reduce the risk of SQL injection attacks is to disable detailed SQL error messages. attackers usually exploit these messages (as described in the preceding example ), easily find scripts that are vulnerable to "SQL injection.
This solution can be omitted using the technology called "Blind SQL injection". Hackers do not need to rely on the returned SQL error message, you can find scripts that are vulnerable to "SQL injection.

This technology needs to send vulnerable parameters (parameters embedded in SQL queries) that have been modified, enable the response to indicate whether data is used in the context of SQL query. This modification includes using the and Boolean expression with the original string, so that it gets true at the moment and false at the moment. In one case, the final result should be the same as the original result (for example, logon is successful). In the other case, the result should be different (for example, Logon failure ). In some rare cases, the true or expression is also useful.

If the raw data is a number, you can use a simple trick. Raw data (such as 123) can be replaced with 0 + 123 in one request and 456 + 123 in another request. The results of the first request should be the same as the original results, and those of the second request should be different (because the number obtained is 579 ). In some cases, we still need the attack version (Use and or) described above, but do not escape the string context.

The concept behind blind SQL injection is that even if the database data is not directly received (in the form of an error message or leakage of information), the data in the database may be extracted, one bit at a time, or maliciously modify the query. The concept is that the application behavior (the results are the same as the original results, or the results are different from the original results) can provide information about the unit meta of the query for the requested value (modified), that is, attackers may plan an SQL Boolean expression that affects the evaluate (unit) of an application in the form of application behavior (same or different from the original behavior.

 

Application solution:

Some methods remedy this problem by clearing special characters in user input. For SQL blind injection, you need to filter Context Change symbols. Such as single quotation marks, quotation marks, backslash escape single quotation marks \ ', backslash escape quotation marks \ ", ending parentheses), semicolons ;.

The application uses dynamic concatenation of SQL statements to cause SQL injection. Therefore, in the application, avoid directly splicing SQL statements, then, the Javascript special character verification works properly with the server-side filter to filter special characters to prevent SQL injection attacks. The general method is as follows:

1. JDBC pre-compiled SQL statements

Uses JDBC preparedstatement, Which is pre-compiled and stored in the preparedstatement Object pool. This method can be used to set input parameters to prevent attackers from manipulating SQL statements by injecting incorrect characters (such as single quotes.

An example of SQL concatenation is as follows:

String SQL = "select * from users where username = '" + username + "'";

Try

{

Statementstat = conn. createstatement ();

Resultsetrs = Stat. executequery (SQL );

...

}

...

Examples of pre-compiled SQL statements are as follows:

String SQL = "select * from users where username =? ";

Try

{

Preparedstatementps = myconnection. preparestatement (SQL );

PS. setstring (1, username );

Resultsetrs = ps.exe cutequery ();

...

}

...

2. bind variables using Stored Procedures

Using Bound variables in the stored procedure not only greatly improves the SQL query speed, but also effectively prevents SQL blind injection.

Many users use the following method to perform SQL queries. This method varies with the input parameter I _username. Each time the Oracle database hardcodes the SQL statement.

SQL: =
'Select * From userswhere username = ''' | I _username | ''';

Open o_cursor for SQL;

 

The following is an example of variable binding. This method uses the BIND encoding. Even if the I _username value is different each time, Oracle performs a hard parsing. You only need soft parsing at a time, this greatly improves data query and effectively prevents SQL blind injection.

SQL: = 'select * from users where username =: username ';

Open o_cursor for SQL using I _useranme;

3. Use the commons validator framework

Use the struts integration framework commons validator to complete data verification requirements. For more information about the validation. xml configuration rules, see the relevant instructions.

Note: If you need background validation. if you configure rules in XML, the from-bean corresponding to the action must inherit validateform (for the reason, you can view the source code). Otherwise, only JavaScript verification is performed on the page. The user (attacker) you can also disable illegal Javascript script input.

4. JavaScript Validation + custom filter

This method is similar to the above method. The basic idea of this method is to perform a normal data verification and special character verification prompt on the page, and then perform special character processing in the filter. If the user is found to be illegal to enter special characters, special characters are processed. For example, the system jumps to the special character prompt page. In this method, special character verification by JavaScript is the same operation. You can write a common js method to register the trigger event when loading the page.

 

In the project, method 1 and method 2 are decisive methods, and similar error instance code is not allowed.

Chaofanga

2012-9-19