隨著B/S模式套用開發的發展，使用這種模式編寫應用程式的程式設計師也越來越多。但是由於程式設計師的水平及經驗也參差不齊，相當大一部分程式設計師在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，加之現階段的程式設計師越來越多，信息網路化程度也不斷提高，網路使用率也隨之大大提高。程式設計師的質量也不斷提高。如此使應用程式存在安全隱患率堪憂。SQL 的普及率使一些惡意或者是出於某些意圖而更改用戶可以提交一段資料庫查詢代碼，根據程式返回的結果，獲得某些他想得知的數據，這就是所謂的SQL Injection，即SQL注入。
Sql 注入,外文參考資料,注入初步介紹,
Sql 注入
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開發語言之一!
1.1 普通SQL注入技術概述
目前沒有對SQL注入技術的標準定義，以下是從2個方面進行了描述：
(1) 腳本注入式的攻擊
(2) 惡意用戶輸入用來影響被執行的SQL腳本
當一個攻擊者通過在查詢語句中插入一系列的SQL語句來將數據寫入到應用程式中，這種方法就可以定義成SQL注入。
“從一個資料庫獲得未經授權的訪問和直接檢索”，SQL注入攻擊就其本質而言，它利用的工具是SQL的語法，針對的是應用程式開發者編程過程中的漏洞，“當攻擊者能夠運算元據，往應用程式中插入一些SQL語句時，SQL注入攻擊就發生了”。實際上，SQL注入是存在於常見的多連線的應用程式中一種漏洞，攻擊者通過在應用程式中預先定義好的查詢語句結尾加上額外的SQL語句元素，欺騙資料庫伺服器執行非授權的任意查詢。這類應用程式一般是網路應用程式(Web Application)，它允許用戶輸入查詢條件，並將查詢條件嵌入SQL請求語句中，傳送到與該應用程式相關聯的資料庫伺服器中去執行。通過構造一些畸形的輸入，攻擊者能夠操作這種請求語句去獲取預先未知的結果。
1.2 SQL注入攻擊的防禦手段
由於越來越多的攻擊利用了SQL注入技術，也隨之產生了很多試圖解決注入漏洞的方案。目前被提出的方案有：
(1) 在服務端正式處理之前對提交數據的合法性進行檢查；
(2) 封裝客戶端提交信息；
(3) 替換或刪除敏感字元/字元串；
(4) 禁止出錯信息。
方案(1)被公認是最根本的解決方案，在確認客戶端的輸入合法之前，服務端拒絕進行關鍵性的處理操作，不過這需要開發者能夠以一種安全的方式來構建網路應用程式，雖然已有大量針對在網路應用程式開發中如何安全地訪問資料庫的文檔出版，但仍然有很多開發者缺乏足夠的安全意識，造成開發出的產品中依舊存在
注入漏洞；
方案(2)的做法需要RDBMS的支持，目前只有Oracle採用該技術；
方案(3)則是一種不完全的解決措施，例如，當客戶端的輸入為“…ccmdmcmdd…”時,在對敏感字元串“cmd”替換刪除以後，剩下的字元
正好是“…cmd…”；
方案(4)是目前最常被採用的方法，很多安全文檔都認為SQL注入攻擊需要通過錯誤信息收集信息，有些甚至聲稱某些特殊的任務若缺乏詳細的錯誤信息則不能完成，這使很多安全專家形成一種觀念，即注入攻擊在缺乏詳細錯誤的情況下不能實施。而實際上，禁止錯誤信息是在服務端處理完畢之後進行補救，攻擊其實已經發生，只是企圖阻止攻擊者知道攻擊的結果而已。
SQL盲注技術就是一些攻擊者使用的新技術，其在錯誤信息被禁止的情況下使攻擊者仍能獲得所需的信息，並繼續實施注入攻擊。
