SQL注入或SQLi漏洞指的是攻擊者可以修改從Web應(yīng)用發(fā)送到數(shù)據(jù)庫(kù)的SQL語(yǔ)句。今天，南昌網(wǎng)絡(luò)公司小編就來(lái)為大家介紹一下Web 應(yīng)用中常規(guī)SQL注入檢測(cè)方法。

首先要說(shuō)的是SQL注入攻擊可以根據(jù)bug的不同分為不同類(lèi)別。通常來(lái)說(shuō)，可以按照HTTP響應(yīng)返回的數(shù)據(jù)種類(lèi)來(lái)區(qū)分注入。如果返回的是類(lèi)似下面這樣的SQL錯(cuò)誤，就可以實(shí)施基于錯(cuò)誤的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語(yǔ)句中包含錯(cuò)誤，Web應(yīng)用也根本不會(huì)返回錯(cuò)誤。這種類(lèi)型的SQLi通常叫作Blind SQLi，因?yàn)閺臄?shù)據(jù)庫(kù)或應(yīng)用得不到任何錯(cuò)誤。

此時(shí)，通過(guò)對(duì)比正常請(qǐng)求和惡意請(qǐng)求的HTTP響應(yīng)之間的區(qū)別，也可以檢測(cè)到SQLi是否會(huì)影響某些資源。前述區(qū)別可以分為兩種。一種是內(nèi)容長(zhǎng)度不同，也就是返回的響應(yīng)體的內(nèi)容不同。另一種是響應(yīng)時(shí)間不同，比如常規(guī)響應(yīng)時(shí)間是1秒，而惡意響應(yīng)卻需要5秒。下面來(lái)看一段Ruby代碼，這段代碼是可以被SQL注入的：

get "/" do

@config = ConfigReader.instance.config

# 從GET請(qǐng)求中取得book_id參數(shù)

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

# 若找到一個(gè)特定的book_id參數(shù)

# 就執(zhí)行以下未加密查詢

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

如果將一個(gè)類(lèi)似/page?book_id=1'的GET請(qǐng)求發(fā)送給這段代碼中的處理程序，那么數(shù)據(jù)庫(kù)就會(huì)返回類(lèi)似前面的錯(cuò)誤信息。只要發(fā)送像下面這樣檢索MySQL數(shù)據(jù)庫(kù)版本的查詢，就可以利用這種基于錯(cuò)誤的SQLi：

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

最終的SQL語(yǔ)句會(huì)被攻擊者在SELECT * FROM books WHERE id=1后面追加上UNION ALL SELECT NULL, @@VERSION, NULL。Web應(yīng)用的那個(gè)拼接的查詢(query = "SELECT * FROM books WHERE id=" + book_id + ";")之所以不安全，是因?yàn)閰?shù)值book_id未經(jīng)輸入驗(yàn)證就被用于字符串拼接。這種[沒(méi)有預(yù)處理語(yǔ)句(Prepared Statements)18]的查詢結(jié)果，會(huì)使應(yīng)用面臨SQL注入的風(fēng)險(xiǎn)。

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

假設(shè)你事先并不知道這一點(diǎn)，而想要檢測(cè)某個(gè)資源是否可以實(shí)施SQLi。可以發(fā)送下面這個(gè)GET請(qǐng)求：

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

然后，經(jīng)過(guò)大約5秒鐘，你才會(huì)收到HTTP響應(yīng)。這么長(zhǎng)的響應(yīng)時(shí)間意味著該資源存在SQL注入漏洞，因?yàn)镾LEEP語(yǔ)句被成功執(zhí)行了。

以上內(nèi)容便是南昌網(wǎng)絡(luò)公司小編為大家介紹的關(guān)于SQL注入的檢測(cè)方法，這些只是比較淺顯的SQL注入檢測(cè)，想進(jìn)一步了解這方面知識(shí)的朋友，歡迎關(guān)注本公司官網(wǎng)動(dòng)態(tài)，更多技術(shù)性文章與您來(lái)分享。此外，如有需要關(guān)于南昌網(wǎng)站建設(shè)、微信開(kāi)發(fā)、手機(jī)APP開(kāi)發(fā)等方面的服務(wù)，百恒網(wǎng)絡(luò)隨時(shí)為您效勞!