界: Input Validation and Representation
輸入驗證和表示法問題是由中繼字元、替代編碼和數值表示法引起的。信任輸入會導致安全問題。問題包括:「Buffer Overflows」、「Cross-Site Scripting」攻擊、「SQL Injection」及其他許多問題。
SQL Injection: JDO
Abstract
使用 Java Data Objects (JDO) 執行透過不可信賴來源的輸入建立的動態 SQL 或 JDOQL 指令,可能會讓攻擊者修改指令的意義或是執行任意的 SQL 指令。
Explanation
SQL Injection 錯誤會在以下情況中出現:
1. 資料從一個不可信賴的來源進入程式。
2. 資料用來動態建構 SQL 或 JDOQL 查詢。
範例 1:以下程式碼動態地建構並執行了一個 SQL 查詢,該查詢可用來搜尋符合指定名稱的項目。查詢僅會顯示項目所有者與目前已驗證使用者名稱相符的項目。
此查詢欲執行以下程式碼:
但是,由於這個查詢是連續固定基礎查詢字串和使用者輸入字串所動態建構而成的,所以只有在
附加條件
由於查詢必須只會傳回驗證使用者所擁有的項目,但簡化查詢會讓攻擊者不再受到此要求所限制;因此,查詢現在將會傳回所有儲存在
範例 2:此範例會檢查不同的惡意值傳送到建立的查詢以及在
許多的資料庫伺服器 (包括 Microsoft(R) SQL Server 2000),允許一次執行多個由分號隔開的 SQL 陳述式。此攻擊字串會在 Oracle 和其他不允許整批執行由分號隔開指令的資料庫伺服器上造成錯誤,而在允許整批執行的資料庫上,此類的攻擊可讓攻擊者對資料庫執行任意的指令。
請注意這對連字符號 (--),這在大部分的資料庫伺服器上都表示剩餘的陳述式,並視為註釋不予執行 [4]。在此案例中,註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中,攻擊者通常會使用類似
避免 SQL injection 攻擊的一個傳統方法為,將其視為輸入驗證的問題,只接受安全值允許清單中的字元,或是驗證並避免來自潛在惡意值的清單 (拒絕清單)。檢查允許清單是一種相當有效的方法,可強制執行嚴格的輸入驗證規則,而參數化 SQL 陳述式所需的維護較少,並且能提供更高的安全性保障。通常,實作拒絕清單總是存在一些漏洞,所以無法有效避免 SQL injection 攻擊。例如,攻擊者可能:
- 將未列入黑名單的值當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元
手動去除在 SQL 查詢中特殊字元的輸入有一定的幫助,但無法完全保護您的應用程式免於 SQL injection 攻擊。
另外一個處理 SQL injection 攻擊的普遍建議方法為使用儲存的程序。雖然儲存的程序可避免某些類型的 SQL injection 攻擊,但是對於大多數的攻擊還是無能為力。儲存的程序一般用來避免 SQL injection 攻擊的方式是,限制可以傳送到參數的指令類型。但是,雖然有許多的限制方法,仍有許多危險的指令可以傳入儲存的程序中。所以再次強調,儲存的程序可以避免部分盜取情況,但無法保護您的應用程式免於 SQL Injection 攻擊。
1. 資料從一個不可信賴的來源進入程式。
2. 資料用來動態建構 SQL 或 JDOQL 查詢。
範例 1:以下程式碼動態地建構並執行了一個 SQL 查詢,該查詢可用來搜尋符合指定名稱的項目。查詢僅會顯示項目所有者與目前已驗證使用者名稱相符的項目。
...
String userName = ctx.getAuthenticatedUserName();
String itemName = request.getParameter("itemName");
String sql = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ itemName + "'";
Query query = pm.newQuery(Query.SQL, sql);
query.setClass(Person.class);
List people = (List)query.execute();
...
此查詢欲執行以下程式碼:
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:此範例會檢查不同的惡意值傳送到建立的查詢以及在
Example 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 和其他不允許整批執行由分號隔開指令的資料庫伺服器上造成錯誤,而在允許整批執行的資料庫上,此類的攻擊可讓攻擊者對資料庫執行任意的指令。
請注意這對連字符號 (--),這在大部分的資料庫伺服器上都表示剩餘的陳述式,並視為註釋不予執行 [4]。在此案例中,註釋字元會從修改的查詢中將剩餘的一個單引號移除。在不允許以此方式使用註釋的資料庫中,攻擊者通常會使用類似
Example 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 攻擊。例如,攻擊者可能:
- 將未列入黑名單的值當作目標
- 尋找方法以略過特定逸出中繼字元 (escape meta-character) 的需要
- 使用儲存的程序去隱藏插入的中繼字元
手動去除在 SQL 查詢中特殊字元的輸入有一定的幫助,但無法完全保護您的應用程式免於 SQL injection 攻擊。
另外一個處理 SQL injection 攻擊的普遍建議方法為使用儲存的程序。雖然儲存的程序可避免某些類型的 SQL injection 攻擊,但是對於大多數的攻擊還是無能為力。儲存的程序一般用來避免 SQL injection 攻擊的方式是,限制可以傳送到參數的指令類型。但是,雖然有許多的限制方法,仍有許多危險的指令可以傳入儲存的程序中。所以再次強調,儲存的程序可以避免部分盜取情況,但無法保護您的應用程式免於 SQL Injection 攻擊。
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] JDO API Documentation
[6] IDS00-J. Prevent SQL Injection CERT
[7] INJECT-2: Avoid dynamic SQL Oracle
[8] Standards Mapping - Common Weakness Enumeration CWE ID 89
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[15] Standards Mapping - FIPS200 SI
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[22] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[23] Standards Mapping - OWASP Top 10 2010 A1 Injection
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Top 10 2021 A03 Injection
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[38] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.dataflow.java.sql_injection_jdo