SQL Injiect

應(yīng)用程序錯(cuò)誤。

WASC分類：SQL Injection

分為 Normal SQL Injection 和 Blind SQL Injection

可參考：http://www.webappsec.org/projects/threat/classes/sql_injection.shtml　

錯(cuò)誤級(jí)別：

         嚴(yán)重（High）。

風(fēng)險(xiǎn)：

可以造成非法訪問、修改、刪除數(shù)據(jù)庫中的記錄和表。

The impact of this attack can allow attackers to gain total control of the database or even execute commands on the system

技術(shù)說明：

Normal SQL Injection：

動(dòng)態(tài)網(wǎng)站有很多是將用戶輸入，作為SQL查詢的參數(shù)拼成SQL語句進(jìn)行數(shù)據(jù)庫訪問。如未對(duì)用戶輸入校驗(yàn)，拼寫SQL時(shí)將會(huì)造成SQL語義變化。

譬如用戶查詢：

select count(*) from users where username=”$username-userinput”

如果用戶輸入：michael： SQL語句為：

Select count(*) from users where username=’michael’

如果用戶輸入  michael‘%20or%201=1%20or ‘‘=‘:  SQL語句為：

Select count(*) from users where username=’michael’ or 1=1 or ‘’=’’

這樣無論michael是否存在，只要數(shù)據(jù)庫中有記錄，查出來的結(jié)果michael都會(huì)在的。

通過同樣的手法，就可以不斷的改變SQL的語義，達(dá)到自己的目的（但是攻擊者第一步一定要了解查詢的SQL結(jié)構(gòu)）。

Blind SQL Injiection：

不依靠返回的錯(cuò)誤。通過不斷的發(fā)送變化的有攻擊性的參數(shù)，通過返回來判斷是否使用到了這些參數(shù)進(jìn)行查詢。

參數(shù)使用到了 AND表達(dá)式，一次為真、一次為假；返回的結(jié)果要么和原始結(jié)果一樣（如成功登錄），要么不行，這樣就可以猜測程序的行為。 OR表達(dá)式也同樣適用于很多不同的場合。

如果參數(shù)是數(shù)字，則有簡單的方法進(jìn)行探測。如原始輸入的123，和0+123結(jié)果是否一樣。。。

Blind SQL Injection是可以在在缺少信息（錯(cuò)誤信息、漏洞信息）的條件下進(jìn)行的，，每次獲取一點(diǎn)，或者用惡意的方式進(jìn)行查詢。這意味著程序行為（結(jié)果和原始結(jié)果是否一致）能提供一些可估計(jì)的查詢信息。對(duì)攻擊者意味著可以通過組織數(shù)據(jù)庫布爾表達(dá)式來猜測程序的行為。

攻擊方法：

         譬如用戶登錄，原來用戶無法登錄，但是獲知SQL語句的結(jié)構(gòu)，在登錄采用SQL語句中，填入了1=1，這樣使得攻擊者通過了驗(yàn)證，可以合法的使用網(wǎng)站資源了。

解決方式：

1.       加強(qiáng)對(duì)參數(shù)的校驗(yàn)：
一定要做，大量的漏洞都是針對(duì)參數(shù)未作校驗(yàn)引出很多攻擊手法(會(huì)有如何檢查參數(shù)的單獨(dú)說明)

2.       數(shù)據(jù)庫查詢：
不要直接拼成SQL語句，利用參數(shù)化的方式進(jìn)行查詢：PreparedStatement、 CallableStatement、 Entity Bean 方式

3.       屏蔽錯(cuò)誤顯示，頁面上顯示客戶友好的錯(cuò)誤信息，增加猜測SQL語句的難度

Blind SQL Injection

Application

WASC Threat Classification

       Command Execution: SQL Injection

       http://www.webappsec.org/projects/threat/classes/sql_injection.shtml

CVE Reference(s)

       N/A

Security Risks

       It is possible to view, modify or delete database entries and tables

Possible Causes

       Sanitation of hazardous characters was not performed correctly on user input

Technical Description

Web applications often use databases at the backend to interact with the enterprise data warehouse.The de-facto standard language for querying databases is SQL (each major database vendor has its own dialect). Web applications often take user input (taken out of the HTTP request) and incorporate it in an SQL query, which is then sent to the backend database. The query results are then processed by the application and sometimes displayed to the user.

This mode of operation can be exploited by an attacker if the application is not careful enough with its treatment of user (attacker) input. If this is the case, an attacker can inject malicious data, which when incorporated into an SQL query, changes the original syntax of the query into something completely different. For example, if an application uses user‘s input (such as username and password) to query a database table of users‘ accounts in order to authenticate the user, and the attacker has the ability to inject malicious data into the username part of the query (or the password part, or both), the query can be changed into a different data yanking query, a query that modifies the database, or a query that runs shell commands on the database server.

Typically, the attacker achieves this goal in steps. He/she will first learn the structure of the SQL query, and then use this knowledge to thwart the query (by injecting data that changes the query syntax) into performing differently than intended. Suppose the query in question is:

SELECT COUNT(*) FROM accounts WHERE username=‘$user‘ AND password=‘$pass‘

Where $user and $pass are user input (collected from the HTTP request which invoked the script that constructs the query - either from a GET request query parameters, or from a POST request body parameters). A regular usage of this query would be with values $user=john, $password=secret123. The query formed would be:

SELECT COUNT(*) FROM accounts WHERE username=‘john‘ AND password=‘secret123‘

The expected query result is 0 if no such user+password pair exists in the database, and >0 if such pair exists (i.e. there is a user named ‘john‘ in the database, whose password is ‘secret123‘). This would serve as a basic authentication mechanism for the application. But an attacker can alter this query in the following way:

By providing an input consisting of a single apostrophe character (‘), the attacker can cause the database to emit an error message, which usually contains valuable information regarding the SQL query. The attack would simply involve sending a request with the user value ‘ and a password with any value (e.g. foobar). The result would be the following (malformed) SQL query:

SELECT COUNT(*) FROM accounts WHERE username=‘‘‘ AND password=‘foobar‘

This may yield the following error message (depending on the specific database in use at the backend): Syntax error (missing operator) in query expression ‘username = ‘‘‘ AND password = ‘foobar‘‘. The attacker is informed that the query is built around the expression username=‘$user‘ AND password=‘$pass‘. This crucial information is needed to exploit the SQL query at hand. When the attacker understands the format of the query, his next step would simply be to use:

user = ‘ or 1=1 or ‘‘=‘

password = foobar

The resulting query is:  SELECT COUNT(*) FROM accounts WHERE username=‘‘ or 1=1 or ‘‘=‘‘ AND password=‘foobar‘

This means that the query (in the SQL database) will return TRUE for every record of the table "accounts", since the expression 1=1 is always true. Therefore, the query will return the number of records in "accounts", and thus the user (attacker) will be considered valid. There are several variants of this probing method, such as sending ‘; or \‘ (it should be remembered that almost all vendors have their own unique SQL ‘dialect‘). Specifically sending ‘ having 1=1 is also known to produce error messages that reveal information about column names. In some cases, the user input is not incorporated in a string context (encompassed in apostrophes), but rather in numeric context, that is, embedded as-is. Thus the input string 1 having 1=1 can be used in such cases.

* Blind SQL injection techniques:

A common way to reduce the risk of being attacked by SQL injection is to supress detailed SQL error messages, which are usually used by attackers (as explained in the examples above) to easily locate scripts that are susceptible to SQL Injection. This (security through obscurity) solution can be bypassed by using a technique called "Blind SQL injection", in which the hacker locates scripts, which are susceptible to SQL injection, without having to depend on the returning SQL error messages.

The technique calls for sending requests whose vulnerable parameter (the parameter that gets embedded in the SQL query) is modified in such way that the response indicates whether the data is used in SQL query context or not. The modification involves the use of an AND boolean expression with the original string, which evaluates once as true and once as false. In one case, the net result should be identical to the original result (e.g. a successful login), and in the other case, the result should be different (e.g. failed login). An OR expression which evaluates as true may also be useful for some rare cases.

If the original data is numeric, then a simpler trick can be played. The original data (say, 123) can be replaced with 0+123 in one request, and with 456+123 in another. The result of the first request should be identical to the original result, whereas the result of the second request should be different (as the number is evaluated as 579). For some cases, we still need a version of the attack described above (using AND and OR), but without escaping from string context. The concept behind blind SQL injection is that it is possible, even without receiving direct data from

the database (in the form of an error message, or leaked information), to extract data from the database, one bit at a time, or to modify the query in a malicious way. The idea is that the application

behavior (result identical to the original result, or result different than the original result) can provide a single bit of information about the evaluated (modified) query, meaning, it‘s possible for the attacker to formulate an SQL Boolean expression whose evaluation (single bit) is compromised in the form of the application behavior (identical/un-identical to the original behavior).