SQL Injection

ABSTRACT

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

EXPLANATION

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

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

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

例 1：以下代碼動態地構造并執行了一個 SQL 查詢，該查詢用來搜索與指定名稱相匹配的項。該查詢將僅為那些與當前經過身份驗證的用戶同名的所有者顯示各項內容。


procedure get_item (
itm_cv IN OUT ItmCurTyp,
usr in varchar2,
itm in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'owner = '''|| usr || '''' ||
' AND itemname = ''' || itm || '''';
end get_item;

該代碼要執行的查詢如下：


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

但是，由于這個查詢是動態構造的，由一個常數基查詢字符串和一個用戶輸入字符串連接而成，因此只有在 itemName 不包含單引號字符時，才會正確執行這一查詢。如果一個用戶名為 wiley 的攻擊者在 itm 中輸入字符串 "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 指令。對于 Oracle 和其他不允許批量執行用分號分隔的 SQL 指令的數據庫服務器，這個攻擊字符串會導致錯誤；在那些支持批量執行的數據庫上，這種攻擊會使得攻擊者能夠對數據庫執行任意命令。

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


	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 攻擊。

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] David Litchfield Lateral SQL Injection:A New Class of Vulnerability in Oracle

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

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

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

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

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

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

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

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

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

亚洲欧美在线