SQL Injection

ABSTRACT

通過不可信來源的輸入構建動態 SQL 指令，攻擊者就能夠修改指令的含義或者執行任意 SQL 命令。

EXPLANATION

SQL injection 錯誤在以下情況下發生：

1. 數據從一個不可信賴的數據源進入程序。

2. 數據用于動態地構造一個 SQL 查詢。

例1：以下代碼動態地構造并執行了一個SQL查詢，該查詢可以搜索與指定名稱相匹配的項。該查詢僅會顯示條目所有者與被授予權限的當前用戶一致的條目。


	...
	username = Session("username")
	itemName = Request.Form("itemName")
	strSQL = "SELECT * FROM items WHERE owner = '"& userName &"' AND itemname = '" & itemName &"'"
	objRecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
	...

這一代碼所執行的查詢遵循如下方式：


	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

但是，由于這個查詢是動態構造的，由一個常數基查詢字符串和一個用戶輸入字符串連接而成，因此只有在 itemName 不包含單引號字符時，才會正確執行這一查詢。如果一個用戶名為 wiley 的攻擊者在 itemName 中輸入字符串 "name' OR 'a'='a"，那么構造的查詢就會變成：


	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

附加條件 OR 'a'='a' 會使 where 從句永遠評估為 true，因此該查詢在邏輯上將等同于一個更為簡化的查詢：


	SELECT * FROM items;

這種查詢的簡化會使攻擊者繞過查詢只返回經過驗證的用戶所擁有的條目的要求；而現在的查詢則會直接返回所有儲存在 items 表中的條目，不論它們的所有者是誰。

例 2：這個例子指出了將不同的惡意數值傳遞給在例 1 中構造和執行的查詢時所帶來的各種影響。如果一個用戶名為 wiley 的攻擊者在 itemName 中輸入字符串“name'; DELETE FROM items; --”，那么最后構造的查詢將變成兩個：


	SELECT * FROM items 
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

眾多數據庫服務器，其中包括 Microsoft(R) SQL Server 2000，都可以一次性執行多條用分號分隔的 SQL 指令。對于那些不允許運行用分號分隔的批量 SQL 指令的數據庫服務器，比如 Oracle 和其他數據庫服務器，攻擊者輸入的這個字符串只會導致錯誤；但是在那些支持這種操作的數據庫服務器上，攻擊者可能會通過執行多條 SQL 而在數據庫上執行任意 SQL 指令。

注意成對的連字符 (--)；這在大多數數據庫服務器上都表示下面的語句將作為注釋使用，而不能加以執行 [4]。在這種情況下，注釋字符的作用就是刪除修改的查詢指令中遺留的最后一個單引號。而在那些不允許這樣加注注釋的數據庫中，通常攻擊者可以如例 1 那樣來攻擊。如果攻擊者輸入字符串 “name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a” 就會創建如下三個有效的 SQL 指令：


	SELECT * FROM items 
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

避免 SQL injection 攻擊的傳統方法之一是，把它作為一個輸入合法性檢查的問題來處理，只接受列在白名單中的字符，或者識別并避免那些列在黑名單中的惡意數據。白名單方法是一種非常有效方法，它可以強制執行嚴格的輸入檢查規則，但是參數化的 SQL 指令所需維護更少，而且能提供更好的安全保障。而對于通常采用的列黑名單方式，由于總是存在一些小漏洞，所以并不能有效地防止 SQL injection 威脅。例如，攻擊者可以：

— 把沒有被黑名單引用的值作為目標

— 尋找方法以繞過對某一轉義序列元字符的需要

— 使用存儲過程來隱藏注入的元字符

手動去除 SQL 查詢中的元字符有一定的幫助，但是并不能完全保護您的應用程序免受 SQL injection 攻擊。

防范 SQL injection 攻擊的另外一種常用方式是使用存儲過程。雖然存儲過程可以阻止某些類型的 SQL injection 攻擊，但是對于絕大多數攻擊仍無能為力。存儲過程有助于避免 SQL injection 的常用方式是限制可作為參數傳入的指令類型。但是，有許多方法都可以繞過這一限制，許多危險的表達式仍可以傳入存儲過程。所以再次強調，存儲過程在某些情況下可以避免這種攻擊，但是并不能完全保護您的應用系統抵御 SQL injection 的攻擊。

REFERENCES

[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A1 Injection

[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws

[3] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A6 Injection Flaws

[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[5] Standards Mapping - Security Technical Implementation Guide Version 3.4 - (STIG 3.4) APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[6] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 89

[7] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 089

[8] Standards Mapping - SANS Top 25 2010 - (SANS 2010) Insecure Interaction - CWE ID 089

[9] Standards Mapping - SANS Top 25 2011 - (SANS Top 25 2011) Insecure Interaction - CWE ID 089

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.6

[13] Standards Mapping - FIPS200 - (FISMA) SI

[14] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) SQL Injection

[15] P. Finnigan SQL Injection and Oracle, Part One Security Focus

[16] S. J. Friedl SQL Injection Attacks by Example

[17] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine

[18] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press

亚洲欧美在线