계: Input Validation and Representation

입력 검증 및 표현 문제는 메타 문자, 대체 인코딩 및 숫자 표현 때문에 발생합니다. 보안 문제는 입력을 신뢰하기 때문에 발생합니다. 문제로는 "Buffer Overflows", "Cross-Site Scripting" 공격, "SQL Injection", 그 외 여러 가지가 있습니다.

Cross-Site Scripting: Content Sniffing

Java/JSP
Python

Abstract

확인되지 않은 데이터를 웹 브라우저로 보내면 특정 브라우저가 악성 코드를 실행할 수 있습니다.

Explanation

XSS(Cross-Site Scripting) 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.

2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.

웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.

브라우저가 HTML 또는 스크립트를 실행할 수 있는 다른 문서로 응답을 렌더링하려면 text/html MIME 유형을 지정해야 합니다. 따라서 응답이 이 MIME 유형을 사용하거나 브라우저가 응답을 HTML 또는 스크립트를 실행할 수 있는 다른 문서(예: SVG 이미지(image/svg+xml), XML 문서(application/xml) 등)로 렌더링하게 만드는 다른 유형을 사용하는 경우에만 XSS가 가능합니다.

대부분의 최신 브라우저는 application/octet-stream 같은 MIME 유형을 사용하여 응답을 제공할 때 HTML을 렌더링하지 않거나 스크립트를 실행하지 않습니다. 하지만 Internet Explorer와 같은 일부 브라우저는 Content Sniffing으로 알려진 동작을 수행합니다. 콘텐트 스니핑에서는 제공된 MIME 유형을 무시하고 응답의 콘텐트를 기준으로 올바른 MIME 유형을 추정하려고 시도합니다.
그러나 text/html의 MIME 유형은 XSS 취약점으로 이어질 수 있는 MIME 유형 중 하나일 뿐입니다. SVG 이미지(image/svg+xml), XML 문서(application/xml) 등과 같은, 스크립트를 실행할 수 있는 다른 문서로 인해 브라우저가 콘텐트 스니핑을 수행하는지 여부와 관계없이 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 문서로 렌더링하려고 시도할 수 있으므로 XSS(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

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

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

[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.2 Requirement 6.5.7

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

[40] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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

확인되지 않은 데이터를 웹 브라우저로 보내면 특정 브라우저가 악성 코드를 실행할 수 있습니다.

Explanation

XSS(Cross-Site Scripting) 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.

2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.

웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.

브라우저가 HTML 또는 스크립트를 실행할 수 있는 다른 문서로 응답을 렌더링하려면 text/html MIME 유형을 지정해야 합니다. 따라서 응답이 이 MIME 유형을 사용하거나 브라우저가 응답을 HTML 또는 스크립트를 실행할 수 있는 다른 문서(예: SVG 이미지(image/svg+xml), XML 문서(application/xml) 등)로 렌더링하게 만드는 다른 유형을 사용하는 경우에만 XSS가 가능합니다.

대부분의 최신 브라우저는 application/json 같은 MIME 유형을 사용하여 응답을 제공할 때 HTML을 렌더링하거나 스크립트를 실행하지 않습니다. 하지만 Internet Explorer와 같은 일부 브라우저는 Content Sniffing으로 알려진 동작을 수행합니다. 콘텐트 스니핑에서는 제공된 MIME 유형을 무시하고 응답의 콘텐트를 기준으로 올바른 MIME 유형을 추정하려고 시도합니다.그러나 text/html의 MIME 유형은 XSS 취약점으로 이어질 수 있는 MIME 유형 중 하나일 뿐입니다.
SVG 이미지(image/svg+xml), XML 문서(application/xml) 등과 같은, 스크립트를 실행할 수 있는 다른 문서로 인해 브라우저가 콘텐트 스니핑을 수행하는지 여부와 관계없이 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>'}