界: Input Validation and Representation
入力の検証や表現の問題は、メタキャラクター、代替エンコーディング、数値表現などによって引き起こされます。セキュリティの問題は、入力を信頼することに起因します。この問題に含まれるのは、「Buffer Overflow」、「Cross-Site Scripting」攻撃、「SQL Injection」などです。
SQL Injection: NHibernate
Abstract
NHibernate を使用して、信頼されていないソースから受信した入力で構築された動的な SQL ステートメントを実行すると、攻撃者によるステートメントの改変や任意の SQL コマンドの実行が可能になります。
Explanation
次の場合に SQL Injection エラーが発生します。
1. 信頼できないソースからデータがプログラムに入り込んだ場合。
2. データが SQL クエリの動的な構築に使用された場合。
例 1: 次のコードは、指定された名前に一致するアイテムを検索する SQL クエリを動的に構築し、実行します。このクエリでは、認証済みユーザーのユーザー名と
このコードによって実行されるクエリは次のようになります。
ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、
このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、
例 2: この例では、
Microsoft(R) SQL Server 2000 などの多くのデータベースサーバーでは、セミコロンで区切って入力した複数の SQL ステートメントをまとめて実行することができます。このような悪意のある文字列は、セミコロンで区切った複数ステートメントのバッチ処理を許可しない Oracle などのデータベースサーバーではエラーになりますが、バッチ処理を許容するデータベースの場合、攻撃者はデータベースに対して任意のコマンドを実行できます。
末尾の 2 つのハイフン (--) に注意してください。多くのデータベースサーバーでは、これ以降のステートメントはコメントとなり、実行されません [4]。この例では、変更されたクエリの末尾に残っている単一引用符が、コメント文字により削除されます。コメントをこのように使用することが許されていないデータベースでも、
SQL Injection の攻撃を阻止する従来からの手段に、これらを入力検証の問題として扱う方法があります。安全な値の許可リストにある文字だけを受け入れるか、悪意のあることが疑われる値をリストで識別して回避するか (拒否リスト) のどちらかを行います。許可リストをチェックする方法は、入力検証ルールの厳密な適用に効果的ですが、パラメーター化された SQL ステートメントを使用する方がメンテナンスしやすく、セキュリティ上の安全性も高まります。ほとんどの場合と同様、拒否リストを実装する方法には SQL Injection の攻撃に対する防御を無効にできる抜け穴が多く存在します。たとえば、攻撃者は次のことを実行できます。
- 引用符で囲まれていないフィールドをターゲットとする。
- 特定のメタ文字をエスケープする必要性を回避する方法を見つけ出す。
- ストアドプロシージャを使用して、挿入されたメタ文字を隠す。
SQL クエリへの入力文字を手動でエスケープすることは便利ですが、アプリケーションを SQL Injection 攻撃の危険にさらすことになります。
その他、SQL Injection の攻撃への一般的な対処として、ストアドプロシージャを使用する方法があります。ストアドプロシージャは特定のタイプの SQL Injection 攻撃を阻止するためには有効ですが、他の多くの攻撃に対しては無力です。ストアドプロシージャは通常、パラメーターに渡されるステートメントのタイプを制限することで SQL Injection の阻止を助けます。ただし、この制限を回避する方法は多数あり、問題になりそうな多くのステートメントをストアドプロシージャに渡すことができます。ストアドプロシージャはある種の悪用を阻止することができますが、アプリケーションが SQL Injection 攻撃に対して安全になるわけではありません。
1. 信頼できないソースからデータがプログラムに入り込んだ場合。
2. データが SQL クエリの動的な構築に使用された場合。
例 1: 次のコードは、指定された名前に一致するアイテムを検索する SQL クエリを動的に構築し、実行します。このクエリでは、認証済みユーザーのユーザー名と
owner
が一致するアイテムだけが表示されます。
...
string userName = ctx.GetAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ ItemName.Text + "'";
List items = sess.CreateSQLQuery(query).List();
...
このコードによって実行されるクエリは次のようになります。
SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;
ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、
ItemName
に単一引用符が含まれない場合のみクエリは正しく動作します。ユーザー名 wiley
を持つ攻撃者が文字列「name' OR 'a'='a
」を ItemName
に入力すると、クエリは次のようになります。
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
を持つ攻撃者が文字列「name'; DELETE FROM items; --
」を ItemName
に入力すると、クエリは次の 2 つのクエリになります。
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';
DELETE FROM items;
--'
Microsoft(R) SQL Server 2000 などの多くのデータベースサーバーでは、セミコロンで区切って入力した複数の SQL ステートメントをまとめて実行することができます。このような悪意のある文字列は、セミコロンで区切った複数ステートメントのバッチ処理を許可しない Oracle などのデータベースサーバーではエラーになりますが、バッチ処理を許容するデータベースの場合、攻撃者はデータベースに対して任意のコマンドを実行できます。
末尾の 2 つのハイフン (--) に注意してください。多くのデータベースサーバーでは、これ以降のステートメントはコメントとなり、実行されません [4]。この例では、変更されたクエリの末尾に残っている単一引用符が、コメント文字により削除されます。コメントをこのように使用することが許されていないデータベースでも、
Example 1
と同様の技法を使用すると一般的な攻撃を有効にできます。攻撃者が文字列「name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a
」を入力すると、次の 3 つの有効なステートメントが作成されます。
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] 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] NHibernate API Documentation
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5.0
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark partial
[12] Standards Mapping - Common Weakness Enumeration CWE ID 89
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[24] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[25] Standards Mapping - OWASP Top 10 2010 A1 Injection
[26] Standards Mapping - OWASP Top 10 2013 A1 Injection
[27] Standards Mapping - OWASP Top 10 2017 A1 Injection
[28] Standards Mapping - OWASP Top 10 2021 A03 Injection
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[31] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] 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
[42] 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
[43] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[44] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[45] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[46] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[68] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.dataflow.dotnet.sql_injection_nhibernate