您可能知道SQL 注入(SQLi) 攻擊是最古老、最普遍和最致命的 Web 應用程序漏洞,并且可能知道如何防止利用 SQLi 漏洞的攻擊。然而,盡管做出了這些努力,您的 Web 應用程序/網(wǎng)站可能仍容易受到 SQL 盲注(SQLi 漏洞的一種子類型)的攻擊。在本文中,我們將深入探討盲 SQLi 攻擊、盲 SQL 注入類型以及如何預防它們。
當后端數(shù)據(jù)庫將攻擊者輸入的數(shù)據(jù)解釋為 SQL 命令,而不是用戶輸入的正常數(shù)據(jù)時,就會發(fā)生盲 SQL 注入攻擊。通常,攻擊者會利用顯示一般錯誤消息的 Web 應用程序,而不會緩解 SQLi 易受攻擊的代碼。攻擊者向此類易受攻擊的應用程序的后端數(shù)據(jù)庫詢問真假問題,并根據(jù)應用程序的響應確定是否存在 SQL 注入。
Blind SQLi 和經(jīng)典 SQLi 之間的主要區(qū)別在于攻擊者從后端數(shù)據(jù)庫檢索數(shù)據(jù)的方式。在經(jīng)典的 SQLi 攻擊中,攻擊者可以在 Web 應用程序中看到數(shù)據(jù)庫錯誤或惡意 SQLi 命令的輸出。當數(shù)據(jù)庫不顯示錯誤消息或輸出惡意命令時,攻擊者通過向后端數(shù)據(jù)庫詢問一系列正確或錯誤的問題來竊取數(shù)據(jù),并查看應用程序或頁面是否正確加載,花費時間來處理 SQL查詢或其他此類更改。盲注 SQL 注入耗時且難以利用,但并非不可能,并且會為攻擊者產(chǎn)生類似的結果。
前任;
以下申請網(wǎng)址
http://www.example.com/item.php?id=2
這會將以下內(nèi)容作為數(shù)據(jù)庫中的請求發(fā)送。
從 ID = 2 的項目中選擇標題、描述、正文
然后攻擊者將以下內(nèi)容作為查詢注入;
http://www.example.com/item.php?id=2 和 1=2
結果 SQL 查詢是這樣的;
從 ID = 2 和 1=2 的項目中選擇標題、描述、正文
上述查詢將是一個錯誤的結果,因此應用程序?qū)⒉粫@示任何數(shù)據(jù)輸出;而在注入真實陳述時;該應用程序?qū)@示一些數(shù)據(jù)。
通過比較收到的輸出;可以斷定存在 SQL 注入攻擊,
Microsoft SQL Server 使用“WAIT FOR DELAY '0:0:10''
PostgreSQL 使用 pg_sleep()
盲目 SQLi 攻擊的影響
盲目 SQLi 攻擊的影響類似于經(jīng)典的 SQL 注入攻擊。它使攻擊者可以訪問和控制后端數(shù)據(jù)庫服務器。他們能
防止盲目的 SQLi 攻擊
需要注意的是,利用盲 SQLi 漏洞所需的技能和工具可能與經(jīng)典 SQLi 漏洞有很大不同,但針對各種 SQL 注入的預防技術非常相似。很多時候,開發(fā)人員在保護 Web 應用程序免受經(jīng)典 SQLi 漏洞攻擊方面缺乏根據(jù)、考慮不周和努力薄弱會導致盲目的 SQLi 漏洞。例如,關閉錯誤報告。
確保安全編碼實踐
無論您使用什么語言,您使用的編碼實踐都必須與 OWASP 安全編碼指南同步。大多數(shù) Web 開發(fā)平臺都提供了避免所有 SQL 注入的機制。使用參數(shù)化查詢而不是動態(tài)查詢(詳情如下)。請記住實施來自所有用戶輸入字段(評論、聯(lián)系表等)的特殊字符的白名單。并使用輸入編碼。
考慮使用數(shù)據(jù)庫層訪問 (DAL),因為它使您能夠集中處理問題或?qū)ο箨P系映射 (ORM) 系統(tǒng),因為它們僅使用參數(shù)化查詢。無論哪種情況,都可以根據(jù)這些新庫轉換所有遺留代碼。
使用參數(shù)化查詢
不惜一切代價避免動態(tài) SQL 查詢,而是使用參數(shù)化查詢。參數(shù)化查詢是準備好的語句,使您能夠有效且穩(wěn)健地減輕盲目 SQL 注入。因此,找到所有動態(tài) SQL 查詢并將它們轉換為參數(shù)化查詢。
全面智能的安全掃描工具必備
使用全面且智能的安全掃描工具,定期掃描您的 Web 應用程序(從開發(fā)階段開始)以識別可能導致 SQLi 攻擊的新錯誤和漏洞。
加入托管且強大的安全解決方案
掃描只能識別差距和漏洞。為了保護您的 Web 應用程序免受這些攻擊,需要保護和修補這些漏洞,直到它們被修復。加入強大的托管安全解決方案,如 AppTrana,它提供智能托管 WAF、定期安全審計、滲透測試和認證安全專家的服務,以確保您的應用程序始終安全,免受包括盲 SQLi 在內(nèi)的漏洞的侵害。