界: Input Validation and Representation

入力の検証や表現の問題は、メタキャラクター、代替エンコーディング、数値表現などによって引き起こされます。セキュリティの問題は、入力を信頼することに起因します。この問題に含まれるのは、「Buffer Overflow」、「Cross-Site Scripting」攻撃、「SQL Injection」などです。

XPath Injection

Abstract

ユーザー入力を使用して XPath クエリを動的に構築すると、攻撃者によりステートメントの意味が改変される可能性があります。

Explanation

次の場合に XPath Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. データが XPath クエリの動的な構築に使用された場合。

例 1: 以下のコードは、指定されたアカウント ID の電子メールアドレスを取得する XPath クエリを動的に構築して実行します。このアカウント ID は、HTTP リクエストから読み取られるため、信頼することはできません。


...
string acctID = Request["acctID"];
string query = null;
if(acctID != null) {
       StringBuffer sb = new StringBuffer("/accounts/account[acctID='");
       sb.append(acctID);
       sb.append("']/email/text()");
       query = sb.toString();
}

XPathDocument docNav = new XPathDocument(myXml);
XPathNavigator nav = docNav.CreateNavigator();
nav.Evaluate(query);
...

アカウント番号 1 に属する電子メールアドレスを検索するような通常の状況では、このコードが実行するクエリは次のようになります。

/accounts/account[acctID='1']/email/text()

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、acctID に単一引用符が含まれない場合のみクエリは正しく動作します。攻撃者が acctID に文字列「1' or '1' = '1」を入力すると、クエリは次のようになります。

/accounts/account[acctID='1' or '1' = '1']/email/text()1' or '1' = '1 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

//email/text()

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、文書内に格納されているすべての電子メールアドレスを返すようになりました。

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 643

[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754

[3] Standards Mapping - FIPS200 SI

[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3

[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3

[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1

[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3

[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.10 Output Encoding and Injection Prevention Requirements (L1 L2 L3)

[12] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection

[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation

[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4

[15] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws

[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws

[17] Standards Mapping - OWASP Top 10 2010 A1 Injection

[18] Standards Mapping - OWASP Top 10 2013 A1 Injection

[19] Standards Mapping - OWASP Top 10 2017 A1 Injection

[20] Standards Mapping - OWASP Top 10 2021 A03 Injection

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1

[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1

[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1

[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4

[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[31] 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

[32] 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

[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I

[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I

[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I

[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I

[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I

[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I

[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I

[55] Standards Mapping - Web Application Security Consortium Version 2.00 XPath Injection (WASC-39)

[56] Standards Mapping - Web Application Security Consortium 24 + 2 XPath Injection

desc.dataflow.dotnet.xpath_injection

Abstract

この特定のメソッドは、未検証の入力を使用して構築された XPath クエリを呼び出します。このコールにより、攻撃者は、ステートメントの意味を改変したり、任意の XPath クエリを実行したりできるようになります。

Explanation

次の場合に XPath Injection が発生します。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. データが XPath クエリの動的な構築に使用された場合。

例 1: C API をコールする次の Objective-C コードは、指定されたアカウント ID の電子メールアドレスを取得する XPath クエリを動的に構築して実行します。このアカウント ID は、HTTP リクエストから読み取られるため、信頼することはできません。


...
    NSString *accountStr = account.text;

    xmlXPathContextPtr xpathCtx;
    NSString *query = @"/accounts/account[actId='" + accountStr + @"']/email/text()";

    xpathCtx = xmlXPathNewContext(doc);

    /* Evaluate XPath expression */
    xmlChar *queryString =
        (xmlChar *)[query cStringUsingEncoding:NSUTF8StringEncoding];
    xpathObj = xmlXPathEvalExpression(queryString, xpathCtx);
...

アカウント番号 1 に属する電子メールアドレスを検索するような通常の状況では、このコードが実行するクエリは次のようになります。

/accounts/account[acctID='1']/email/text()

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、acctID に単一引用符が含まれない場合のみクエリは正しく動作します。攻撃者が acctID に文字列「1' or '1' = '1」を入力すると、クエリは次のようになります。

/accounts/account[acctID='1' or '1' = '1']/email/text()1' or '1' = '1 条件を追加すると、where 句は常に真 (true) の評価を行います。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

//email/text()

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、文書内に格納されているすべての電子メールアドレスを返すようになりました。