sql injection

SQL注入是從正常的WWW埠訪問，而且表面看起來跟一般的Web頁面訪問沒什麼區別，所以目前市面的防火牆都不會對SQL注入發出警報，如果管理員沒查看IIS日誌的習慣，可能被入侵很長時間都不會發覺。但是，SQL注入的手法相當靈活，在注入的時候會碰到很多意外的情況。能不能根據具體情況進行分析，構造巧妙的SQL語句，從而成功獲取想要的數據。

據統計，網站用ASP+Access或SQLServer的佔70%以上，PHP+MySQL佔20%，其他的不足10%。

Incorrectly filtered escape characters

This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into a SQL statement. This results in the potential manipulation of the statements performed on the database by the end user of the application.

The following line of code illustrates this vulnerability:

statement := "SELECT * FROM users WHERE name = '" + userName + "';"

This SQL code is designed to pull up the records of a specified username from its table of users, however, if the "userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the "userName" variable as

a' or 't'='t

renders this SQL statement by the parent language:

SELECT * FROM users WHERE name = 'a' OR 't'='t';

If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of 't'='t' is always true.

On some SQL servers such as MS SQL Server any valid SQL command may be injected via this method, including the execution of multiple statements. The following value of "userName" in the statement below would cause the deletion of the "users" table as well as the selection of all data from the "data" table (in essence revealing the information of every user):

a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '%

This input renders the final SQL statement as follows:

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%';

Other SQL implementations won't execute multiple commands in the same SQL query as a security measure. This prevents hackers from injecting entirely separate queries, but doesn't stop them from modifying queries.

Incorrect type handling

This form of SQL injection occurs when a user supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example:

statement := "SELECT * FROM data WHERE id = " + a_variable + ";"

It is clear from this statement that the author intended a_variable to be a number correlating to the "id" field. However, if it is in fact a string then the end user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to

1;DROP TABLE users

will delete the "users" table from the database as the rendered SQL would be rendered as follows:

SELECT * FROM DATA WHERE id = 1;DROP TABLE users;

php 網站的使用超過了20% asp的使用已經減少了(更正) php已經成了主流web開發語言之一!

目前沒有對SQL注入技術的標準定義，以下是從2個方面進行了描述：

(1) 腳本注入式的攻擊

(2) 惡意用戶輸入用來影響被執行的SQL腳本

當一個攻擊者通過在查詢語句中插入一系列的SQL語句來將數據寫入到應用程序中，這種方法就可以定義成SQL注入。

“從一個資料庫獲得未經授權的訪問和直接檢索”，SQL注入攻擊就其本質而言，它利用的工具是SQL的語法，針對的是應用程序開發者編程過程中的漏洞，“當攻擊者能夠操作數據，往應用程序中插入一些SQL語句時，SQL注入攻擊就發生了”。實際上，SQL注入是存在於常見的多連接的應用程序中一種漏洞，攻擊者通過在應用程序中預先定義好的查詢語句結尾加上額外的SQL語句元素，欺騙資料庫伺服器執行非授權的任意查詢。這類應用程序一般是網路應用程序(Web Application)，它允許用戶輸入查詢條件，並將查詢條件嵌入SQL請求語句中，發送到與該應用程序相關聯的資料庫伺服器中去執行。通過構造一些畸形的輸入，攻擊者能夠操作這種請求語句去獲取預先未知的結果。

由於越來越多的攻擊利用了SQL注入技術，也隨之產生了很多試圖解決注入漏洞的方案。目前被提出的方案有：

(1) 在服務端正式處理之前對提交數據的合法性進行檢查；

(2) 封裝客戶端提交信息；

(3) 替換或刪除敏感字元/字元串；

(4) 屏蔽出錯信息。

方案(1)被公認是最根本的解決方案，在確認客戶端的輸入合法之前，服務端拒絕進行關鍵性的處理操作，不過這需要開發者能夠以一種安全的方式來構建網路應用程序，雖然已有大量針對在網路應用程序開發中如何安全地訪問資料庫的文檔出版，但仍然有很多開發者缺乏足夠的安全意識，造成開發出的產品中依舊存在

注入漏洞；

方案(2)的做法需要RDBMS的支持，目前只有Oracle採用該技術；

方案(3)則是一種不完全的解決措施，例如，當客戶端的輸入為“…ccmdmcmdd…”時，在對敏感字元串“cmd”替換刪除以後，剩下的字元

正好是“…cmd…”；

方案(4)是目前最常被採用的方法，很多安全文檔都認為SQL注入攻擊需要通過錯誤信息收集信息，有些甚至聲稱某些特殊的任務若缺乏詳細的錯誤信息則不能完成，這使很多安全專家形成一種觀念，即注入攻擊在缺乏詳細錯誤的情況下不能實施。而實際上，屏蔽錯誤信息是在服務端處理完畢之後進行補救，攻擊其實已經發生，只是企圖阻止攻擊者知道攻擊的結果而已。

SQL盲注技術就是一些攻擊者使用的新技術，其在錯誤信息被屏蔽的情況下使攻擊者仍能獲得所需的信息，並繼續實施注入攻擊。