SQL注入或SQLi漏洞指的是攻擊者可以修改從Web應用發送到數據庫的SQL語句。今天，南昌網絡公司小編就來為大家介紹一下Web 應用中常規SQL注入檢測方法。

首先要說的是SQL注入攻擊可以根據bug的不同分為不同類別。通常來說，可以按照HTTP響應返回的數據種類來區分注入。如果返回的是類似下面這樣的SQL錯誤，就可以實施基于錯誤的SQLi：

You have an error in your SQL syntax; check the

manual that corresponds to your MySQL server version

for the right syntax to use near ''' at line 1

某些情況下，即使SQL語句中包含錯誤，Web應用也根本不會返回錯誤。這種類型的SQLi通常叫作Blind SQLi，因為從數據庫或應用得不到任何錯誤。

此時，通過對比正常請求和惡意請求的HTTP響應之間的區別，也可以檢測到SQLi是否會影響某些資源。前述區別可以分為兩種。一種是內容長度不同，也就是返回的響應體的內容不同。另一種是響應時間不同，比如常規響應時間是1秒，而惡意響應卻需要5秒。下面來看一段Ruby代碼，這段代碼是可以被SQL注入的：

get "/" do

@config = ConfigReader.instance.config

# 從GET請求中取得book_id參數

book_id = params[:book_id]

# MySQL連接池

pool = Mysql2::Client.new(

:host => @config['db_host'],

:username => @config['restricted_db_user'],

:password => @config['restricted_db_userpasswd'],

:database => @config['db_name']

)

begin

if book_id == nil

@rs = pool.query "SELECT * FROM books;"

else

# 若找到一個特定的book_id參數

# 就執行以下未加密查詢

query = "SELECT * FROM books WHERE id=" + book_id + ";"

@rs = pool.query query

end

erb :"sqlinjection"

rescue Exception => e

@rs = {}

@error_message = e.message

erb :"sqlinjection"

end

end

如果將一個類似/page?book_id=1'的GET請求發送給這段代碼中的處理程序，那么數據庫就會返回類似前面的錯誤信息。只要發送像下面這樣檢索MySQL數據庫版本的查詢，就可以利用這種基于錯誤的SQLi：

/page?book_id=1+UNION+ALL+SELECT+NULL%2C%40%40VERSION%2CNULL%23

最終的SQL語句會被攻擊者在SELECT * FROM books WHERE id=1后面追加上UNION ALL SELECT NULL, @@VERSION, NULL。Web應用的那個拼接的查詢(query = "SELECT * FROM books WHERE id=" + book_id + ";")之所以不安全，是因為參數值book_id未經輸入驗證就被用于字符串拼接。這種[沒有預處理語句(Prepared Statements)18]的查詢結果，會使應用面臨SQL注入的風險。

再考慮一種情況。假設前面存在漏洞的代碼除了把底部的一行(@error_message = e.message)刪除之外，其余都相同，那么此時仍然可以被SQL注入攻擊，只不過變成了Blind。

假設你事先并不知道這一點，而想要檢測某個資源是否可以實施SQLi。可以發送下面這個GET請求：

/page?book_id=1+AND+SLEEP(5)

然后，經過大約5秒鐘，你才會收到HTTP響應。這么長的響應時間意味著該資源存在SQL注入漏洞，因為SLEEP語句被成功執行了。

以上內容便是南昌網絡公司小編為大家介紹的關于SQL注入的檢測方法，這些只是比較淺顯的SQL注入檢測，想進一步了解這方面知識的朋友，歡迎關注本公司官網動態，更多技術性文章與您來分享。此外，如有需要關于南昌網站建設、微信開發、手機APP開發等方面的服務，百恒網絡隨時為您效勞!