界: Input Validation and Representation

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

Cross-Site Scripting: Content Sniffing

Java/JSP
Python

Abstract

未検証のデータを Web ブラウザに送信すると、結果として特定のブラウザで悪意のあるコードが実行される可能性があります。

Explanation

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1.信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。リフレクト XSS の場合、信頼できないソースは Web リクエストであることが最も多く、一方、持続型 XSS (別名: ストアド XSS) の場合はデータベースなどのバックエンドデータストアであるのが一般的です。

2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

ブラウザがレスポンスを HTML として、またはスクリプトを実行する可能性のあるその他のドキュメントとしてレンダリングするためには、text/htmlMIME タイプを指定する必要があります。したがって、XSS が可能になるのは、レスポンスがこの MIME タイプ、またはブラウザがレスポンスを HTML として、またはスクリプトを実行する可能性のあるその他のドキュメント（SVG イメージ (image/svg+xml) や XML ドキュメント (application/xml) など）としてレンダリングするように強制するその他のタイプを使用する場合のみです。

ほとんどの最新のブラウザーは、application/octet-stream のような MIME タイプのレスポンスが提供されても、HTML をレンダリングせず、スクリプトも実行しません。ただし、Internet Explorer などの一部のブラウザは、Content Sniffing と呼ばれる機能を実行します。Content Sniffing では、提供された MIME タイプが無視され、レスポンスの内容によって正しい MIME タイプを推測しようとします。
ただし、text/htmlは、そのような MIME タイプの中で XSS の脆弱性を引き起こす可能性がある唯一の MIME タイプであることには注意が必要です。SVG イメージ (image/svg+xml) や XML ドキュメント (application/xml) など、スクリプトを実行する可能性があるその他のドキュメントは、ブラウザが Content Sniffing を実行するかどうかにかかわらず、XSS の脆弱性を引き起こす可能性があります。

したがって、<html><body><script>alert(1)</script></body></html> などのレスポンスは、その content-type ヘッダーが application/octet-stream、multipart-mixed などに設定されていても、HTML としてレンダリングできます。

例 1: 次の JAX-RS メソッドは、application/octet-stream レスポンスにユーザーデータを反映します。


@RestController
public class SomeResource {
    @RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
    public String response5(@RequestParam(value="name") String name){
        return name;
	}
}

攻撃者が nameパラメータを <html><body><script>alert(1)</script></body></html> に設定してリクエストを送信すると、サーバは次のレスポンスを生成します。


HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed

<html><body><script>alert(1)</script></body></html>

レスポンスを JSON ドキュメントとして扱うようにレスポンス内で明確に既述されていても、古いブラウザはレスポンスを HTML ドキュメントとしてレンダリングしようと試みる場合があり、Cross-Site Scripting 攻撃に対する脆弱性が生じます。

References

[1] X-Content-Type-Options Mozilla

[2] MIME Type Detection in Windows Internet Explorer Microsoft

[3] Understanding Malicious Content Mitigation for Web Developers CERT

[4] HTML 4.01 Specification W3

[5] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System

[6] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications

[7] INJECT-3: XML and HTML generation requires care Oracle

[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5.0

[9] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete

[10] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0

[11] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1

[12] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

[13] Standards Mapping - CIS Kubernetes Benchmark complete

[14] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692

[15] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079

[16] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079

[17] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079

[18] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079

[19] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079

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

[21] Standards Mapping - FIPS200 SI

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

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

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

[25] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting

[26] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)

[27] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)

[28] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)

[29] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)

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

[31] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)

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

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

[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4

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

[36] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7

[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7

[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7

[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7

[40] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7

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

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

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

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

[45] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116

[46] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I

[47] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I

[48] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I

[49] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I

[50] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I

[51] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I

[52] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[67] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)

[68] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting

desc.dataflow.java.cross_site_scripting_content_sniffing

Abstract

未検証のデータを Web ブラウザに送信すると、結果として特定のブラウザで悪意のあるコードが実行される可能性があります。

Explanation

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。
1.信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。リフレクト XSS の場合、信頼できないソースは Web リクエストであることが最も多く、一方、持続型 XSS (別名: ストアド XSS) の場合はデータベースなどのバックエンドデータストアであるのが一般的です。

2.未検証のまま Web ユーザーに送信される動的コンテンツにデータが含まれている場合。
2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

ブラウザがレスポンスを HTML として、またはスクリプトを実行する可能性のあるその他のドキュメントとしてレンダリングするためには、text/html MIME タイプを指定する必要があります。したがって、XSS が可能になるのは、レスポンスがこの MIME タイプ、またはブラウザがレスポンスを HTML として、またはスクリプトを実行する可能性のあるその他のドキュメント（SVG イメージ (image/svg+xml) や XML ドキュメント (application/xml) など）としてレンダリングするように強制するその他のタイプを使用する場合のみです。

ほとんどの最新のブラウザは、application/json のような MIME タイプのレスポンスが提供されても、HTML をレンダリングせず、スクリプトも実行しません。ただし、Internet Explorer などの一部のブラウザは、Content Sniffing と呼ばれる機能を実行します。Content Sniffing では、提供された MIME タイプが無視され、レスポンスの内容によって正しい MIME タイプを推測しようとします。ただし、text/html は、そのような MIME タイプの中で XSS の脆弱性を引き起こす可能性がある唯一の MIME タイプであることには注意が必要です。SVG イメージ (image/svg+xml) や XML ドキュメント (application/xml) など、スクリプトを実行する可能性があるその他のドキュメントは、ブラウザが Content Sniffing を実行するかどうかにかかわらず、XSS の脆弱性を引き起こす可能性があります。

したがって、<html><body><script>alert(1)</script></body></html> などのレスポンスは、その content-type ヘッダーが application/json に設定されていても HTML としてレンダリングできます。

例 1: 次の AWS Lambda 関数は、application/json レスポンスにユーザーデータを反映します。


def mylambda_handler(event, context):
    name = event['name']
    response = {
        "statusCode": 200,
        "body": "{'name': name}",
        "headers": {
            'Content-Type': 'application/json',
        }
    }
    return response

攻撃者が name パラメーターを <html><body><script>alert(1)</script></body></html> に設定してリクエストを送信すると、サーバーは次のレスポンスを生成します。


HTTP/1.1 200 OK
Content-Length: 88
Content-Type: application/json
Connection: Closed

{'name': '<html><body><script>alert(1)</script></body></html>'}