537 개 항목 찾음
취약점
Abstract
런타임 시 사용자가 제어하는 XML 문서를 역직렬화하면 공격자가 서버에서 악성 코드를 실행할 수 있습니다.
Explanation
개발자는 JDK XMLEncoder 및 XMLDecoder 클래스를 통해 손쉽게 개체를 유지하여 XML 문서로 직렬화할 수 있습니다. 또한 개발자는 XMLEncoder를 사용하여 메서드 호출을 직렬화할 수 있습니다. 공격자는 XMLDecoder를 통해 역직렬화할 XML 문서를 제공할 수 있는 경우 서버에서 임의의 코드를 모두 실행할 수 있게 됩니다.

예제 1: 다음 Java 코드는 신뢰할 수 없는 입력을 처리하는 XMLDecoder 인스턴스를 보여줍니다.


XMLDecoder decoder = new XMLDecoder(new InputSource(new InputStreamReader(request.getInputStream(), "UTF-8")));

Object object = decoder.readObject();
decoder.close();
예제 1: 다음 XML 문서는 ProcessBuilder 개체를 인스턴스화하고 해당 정적 start() 메서드를 호출하여 Windows 계산기를 실행합니다.


<java>
<object class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="1" >
<void index="0">
<string>c:\\windows\\system32\\calc.exe</string>
</void>
</array>
<void method="start"/>
</object>
</java>
References
[1] Oracle Oracle official documentation for XMLDecoder
[2] Standards Mapping - Common Weakness Enumeration CWE ID 502
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [23] CWE ID 502
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [21] CWE ID 502
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [13] CWE ID 502
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [12] CWE ID 502
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [15] CWE ID 502
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [16] CWE ID 502
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-001764, CCI-001774, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.2 Input and Output Architectural Requirements (L2 L3), 5.5.1 Deserialization Prevention Requirements (L1 L2 L3), 5.5.3 Deserialization Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A8 Insecure Deserialization
[23] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.dynamic_code_evaluation_xmldecoder_injection
Abstract
프로그램은 AWT/Swing을 사용하여 Enterprise JavaBeans 규격을 위반합니다.
Explanation
Enterprise JavaBeans 규격에 따르면 모든 bean 공급자는 bean이 이식 가능하고 EJB 컨테이너에서 일관성 있게 동작하도록 하기 위한 프로그래밍 지침을 따라야 합니다[1].

이 경우, 프로그램은 다음 EJB 지침을 위반합니다.

"enterprise bean은 디스플레이에 정보를 출력하거나 키보드에서 정보를 입력받을 때 AWT 기능을 사용할 수 없습니다."

규격에서 다음과 같이 정당화하는 요구 사항입니다.

"서버는 응용 프로그램과 서버 시스템에 연결된 키보드/디스플레이가 직접 상호 작용하는 것을 허용하지 않습니다."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 575
desc.structural.java.ejb_bad_practices_use_of_awt_swing
Abstract
프로그램은 클래스 로더를 사용하여 Enterprise JavaBeans 규격을 위반합니다.
Explanation
Enterprise JavaBeans 규격에 따르면 모든 bean 공급자는 bean이 이식 가능하고 EJB 컨테이너에서 일관성 있게 동작하도록 하기 위한 프로그래밍 지침을 따라야 합니다[1].

이 경우, 프로그램은 다음 EJB 지침을 위반합니다.

"Enterprise Bean은 클래스 로더 생성, 컨텍스트 클래스 로더 설정, 보안 관리자 설정, 새 보안 관리자 생성, JVM 중단 또는 입력, 출력 및 오류 스트림 변경을 할 수 없습니다."

규격에서 다음과 같이 정당화하는 요구 사항입니다.

"이러한 함수는 Enterprise Bean 컨테이너용으로 예약되어 있습니다. Enterprise Bean이 이러한 함수를 사용하면 보안이 약해지고 컨테이너가 런타임 환경을 올바로 관리하는 기능이 저하됩니다."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 578
desc.structural.java.ejb_bad_practices_use_of_classloader
Abstract
프로그램은 java.io 패키지를 사용하여 Enterprise JavaBeans 규격을 위반합니다.
Explanation
Enterprise JavaBeans 규격에 따르면 모든 bean 공급자는 bean이 이식 가능하고 EJB 컨테이너에서 일관성 있게 동작하도록 하기 위한 프로그래밍 지침을 따라야 합니다[1].

이 경우, 프로그램은 다음 EJB 지침을 위반합니다.

"Enterprise Bean은 Java I/O 패키지를 사용하여 파일 시스템의 파일과 디렉터리에 액세스할 때 주의해야 합니다."

규격에서 다음과 같이 정당화하는 요구 사항입니다.

"파일 시스템 API는 비즈니스 구성 요소가 데이터에 액세스하는 데 적합하지 않습니다. 모든 인스턴스에서 파일에 액세스할 수 없는 경우도 있고, 인스턴스마다 내용이 다를 수도 있으며, 파일에 대한 업데이트를 조정하는 것이 어려울 수도 있습니다. 비즈니스 구성 요소는 JDBC 같은 리소스 관리자 API를 사용하여 데이터를 저장해야 합니다."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 576
desc.structural.java.ejb_bad_practices_use_of_java_io
Abstract
프로그램은 소켓을 사용하여 Enterprise JavaBeans 규격을 위반합니다.
Explanation
Enterprise JavaBeans 규격에 따르면 모든 bean 공급자는 bean이 이식 가능하고 EJB 컨테이너에서 일관성 있게 동작하도록 하기 위한 프로그래밍 지침을 따라야 합니다[1].

이 경우, 프로그램은 다음 EJB 지침을 위반합니다.

"enterprise bean은 소켓에서 수신 대기하거나 소켓에서 연결을 수락하거나 멀티캐스트에 소켓을 사용할 수 없습니다."

규격에서 다음과 같이 정당화하는 요구 사항입니다.

"Enterprise Bean 아키텍처는 Enterprise Bean 인스턴스가 네트워크 소켓 클라이언트가 되는 것을 허용하지만, 네트워크 서버가 되는 것은 허용하지 않습니다. 인스턴스가 네트워크 서버가 되도록 허용하면 Enterprise Bean의 기본 기능인 Enterprise Beans 클라이언트에 서비스를 제공하는 것과 충돌하게 됩니다."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] Standards Mapping - Common Weakness Enumeration CWE ID 577
desc.structural.java.ejb_bad_practices_use_of_sockets
Abstract
프로그램은 스레드 동기화 기본 형식을 사용하여 Enterprise JavaBeans 규격을 위반합니다.
Explanation
Enterprise JavaBeans 규격에 따르면 모든 bean 공급자는 bean이 이식 가능하고 EJB 컨테이너에서 일관성 있게 동작하도록 하기 위한 프로그래밍 지침을 따라야 합니다[1].

이 경우, 프로그램은 다음 EJB 지침을 위반합니다.

"Bean 관리 동시성이 포함된 단일 항목 세션 Bean이 아닌 경우 Enterprise Bean은 여러 인스턴스의 실행을 동기화할 때 스레드 동기화 기본 형식을 사용할 수 없습니다."

규격에서 다음과 같이 정당화하는 요구 사항입니다.

"이 규칙은 일부 Enterprise Bean 컨테이너가 하나의 JVM을 사용하여 모든 Enterprise Bean의 인스턴스를 실행하는 반면 나머지는 여러 JVM에 인스턴스를 분산시키기 때문에 런타임 의미의 일관성을 유지하기 위해 필요합니다."
References
[1] Jakarta Enterprise Beans 4.0 Eclipse Foundation
[2] THI01-J. Do not invoke ThreadGroup methods CERT
[3] Standards Mapping - Common Weakness Enumeration CWE ID 574
desc.structural.java.ejb_bad_practices_use_of_synchronization_primitives
Abstract
확인되지 않은 SpEL 식을 평가하면 원격 코드가 실행될 수 있습니다.
Explanation
SpEL(Spring Expression Language)은 런타임 시 개체 그래프를 쿼리하고 조작하는 것을 지원하는 강력한 표현 언어입니다. 언어 구문은 Unified EL과 유사하지만 추가 기능, 특히 메서드 호출 및 기본 문자열 템플릿 기능을 제공합니다.
확인되지 않은 식을 평가하도록 허용하면 공격자가 임의 코드를 실행할 수 있게 됩니다.

예제 1: 응용 프로그램이 사용자가 제어하는 확인되지 않은 데이터를 사용하여 SpEL 식을 생성하고 평가합니다.


String expression = request.getParameter("input");
SpelExpressionParser parser = new SpelExpressionParser();
SpelExpression expr = parser.parseRaw(expression);
예제 2: 응용 프로그램이 이중 SpEL 평가를 수행하는 Spring 태그에서 사용자가 제어하는 확인되지 않은 데이터를 사용합니다.


<spring:message text="" code="${param['message']}"></spring:message>
References
[1] Dan Amodio Remote Code with Expression Language Injection
[2] Expression Language Injection OWASP
[3] CVE-2011-2730 Red Hat
[4] Standards Mapping - Common Weakness Enumeration CWE ID 94, CWE ID 95, CWE ID 917
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [25] CWE ID 077
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [17] CWE ID 077, [25] CWE ID 094
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [16] CWE ID 077, [23] CWE ID 094
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094, [13] CWE ID 077
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.4 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[18] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[19] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2010 A1 Injection
[22] Standards Mapping - OWASP Top 10 2013 A1 Injection
[23] Standards Mapping - OWASP Top 10 2017 A1 Injection
[24] Standards Mapping - OWASP Top 10 2021 A03 Injection
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] 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
[36] 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
[37] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.expression_language_injection_spring
Abstract
응용 프로그램의 컨텍스트 내에서 신뢰할 수 없는 스크립트를 실행할 수 있는 파일을 로드하는 것은 위험합니다.
Explanation
File Based Cross Zone Scripting은 다음 조건이 충족될 때 발생합니다.

1. 스크립트가 응용 프로그램 내에서 실행되도록 허용할 수 있는 파일이 로드됩니다.

2. 로드되는 스크립트의 출처가 실행 중인 응용 프로그램과 동일합니다.

이 두 조건이 모두 충족될 경우 특히 상대방이 정보가 응용 프로그램의 경계 내에서 오는 것인지에 따라 신뢰 여부를 결정할 경우, 일련의 공격이 가능해질 수 있습니다.

예제 1: 다음 코드는 Android WebView를 사용하여 로컬에서 파일을 로드합니다.

...
myWebView.loadUrl("file:///android_asset/www/index.html");
...
Example 1에서 Android WebView 렌더러는 “file://”로 시작하는 URL을 사용하여 loadUrl()로 로드되는 모든 것을 출처가 동일한 것으로 취급합니다.

공격자가 파일에서 로드될 때 File Based Cross-Zone Scripting 취약점을 활용하는 몇 가지 일반적인 방법이 있습니다.
- 파일에 스크립트를 삽입할 수 있는 공격자가 로컬 파일을 조작할 수 있습니다.
이 방법은 파일 권한, 파일의 위치 또는 파일이 저장되었다 로드될 수 있는(수정 가능 시간이 있을 수 있음) 경쟁 조건(race condition)에 따라 달라집니다.

- 파일이 외부 리소스로 호출될 수 있습니다.
로드된 파일이 외부 리소스에서 스크립트를 검색할 때 이 상황이 발생할 수 있습니다.

예제 2: 다음 코드는 실행해야 하는 JavaScript를 결정하기 위해 외부 소스를 찾습니다.

<script src="http://www.example.com/js/fancyWidget.js"></script>
Example 2에서는 결과 스크립트를 악의적 작업자가 수정하는 것이 가능한 안전하지 않은 프로토콜이 사용됩니다. 또는 컴퓨터를 공격자의 사이트로 경로 재지정하는 다른 공격이 수행될 수 있습니다.

- 로드된 파일에 Cross-Site Scripting 취약점이 포함될 수 있습니다.
로드되는 파일에 코드 삽입이 가능한 경우, 삽입된 코드는 응용 프로그램의 컨텍스트에서 실행될 수 있습니다. 꼭 JavaScript를 삽입하는 기능이 아니라 단순히 HTML을 삽입할 수만 있어도 변조(defacement) 또는 DOS(Denial of Service) 공격이 가능해질 수 있습니다.
References
[1] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[2] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [1] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] 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)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[61] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.semantic.java.file_based_cross_zone_scripting
Abstract
응용 프로그램의 권한 있는 컨텍스트 내에서 신뢰할 수 없는 스크립트를 실행할 수 있는 로컬 파일을 로드하는 것은 위험합니다.
Explanation
다음 조건이 충족될 때 파일 기반 Cross-Zone Scripting이 발생합니다.

1. 응용 프로그램 내에서 스크립트 실행을 허용할 수 있는 파일이 로드됩니다.


2. 로드된 스크립트는 실행 중인 응용 프로그램과 출처가 동일한 것처럼 보입니다(file://).

이 두 조건이 모두 충족될 경우, 특히 상대방이 정보가 응용 프로그램의 경계 내에서 오는 것인지에 따라 신뢰 여부를 결정할 경우, 일련의 공격이 가능해질 수 있습니다.

예제 1: 다음 코드는 UIWebView.loadRequest(_:) 메서드를 사용하여 로컬 파일을 로드합니다.

...
NSURL *url = [[NSBundle mainBundle] URLForResource: filename withExtension:extension];
[webView loadRequest:[[NSURLRequest alloc] initWithURL:url]];
...
Example 1에서, WebView 엔진은 file://로 시작하는 URL을 사용하여 UIWebView.loadRequest(_:)를 통해 로드되는 모든 것을 권한 있는 로컬 파일 출처에 있는 것으로 취급합니다.

파일에서 로드할 때 공격자가 파일 기반 Cross-Zone Scripting 취약점을 활용하는 몇 가지 일반적인 방법이 있습니다.

- 로컬 파일이 공격자에 의해 제어될 수 있습니다. 예를 들어, 공격자가 파일을 피해자에게 보내고 이 피해자가 이 파일을 취약한 응용 프로그램(예: 클라우드 저장소 응용 프로그램)에 저장할 수 있습니다.
- 파일에 스크립트를 삽입할 수 있는 공격자에 의해 로컬 파일이 조작될 수 있습니다. 이 방법은 파일 권한, 파일의 위치 또는 파일이 저장되었다 로드될 수 있는(수정 가능 시간이 있을 수 있음) 경쟁 조건(race condition)에 따라 달라집니다.
- 파일이 외부 리소스로 호출될 수 있습니다. 로드된 파일이 외부 리소스에서 스크립트를 검색할 때 이 상황이 발생할 수 있습니다.
- 로드된 파일에 Cross-Site Scripting 취약점이 포함될 수 있습니다. 로드되고 있는 파일에 삽입된 코드가 포함된 경우, 이 코드는 응용 프로그램의 컨텍스트에서 실행될 수 있습니다. 삽입된 코드가 JavaScript 코드여야 할 필요는 없으며, 삽입된 HTML은 변조 또는 denial of service 공격을 활성화할 수도 있습니다.

공격자가 제어하는 파일이 file:// URL을 통해 로컬에 로드된 경우, 동일 출처 정책(Same Origin Policy)은 이 파일의 스크립트가 동일 출처의 다른 파일에 액세스할 수 있도록 허용하므로 공격자가 민감한 정보가 포함된 로컬 파일에 액세스할 수 있습니다.
References
[1] Same-origin policy for file: URIs Mozilla
[2] Old Habits Die Hard: Cross-Zone Scripting in Dropbox & Google Drive Mobile Apps IBM
[3] loadHTMLString(_:baseURL:) API documentation Apple
[4] loadRequest(_:) API documentation Apple
[5] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2024 [1] CWE ID 079
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] 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)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.objc.file_based_cross_zone_scripting
Abstract
응용 프로그램의 권한 있는 컨텍스트 내에서 신뢰할 수 없는 스크립트를 실행할 수 있는 로컬 파일을 로드하는 것은 위험합니다.
Explanation
다음 조건이 충족될 때 파일 기반 Cross-Zone Scripting이 발생합니다.

1. 응용 프로그램 내에서 스크립트 실행을 허용할 수 있는 파일이 로드됩니다.


2. 로드된 스크립트는 실행 중인 응용 프로그램과 출처가 동일한 것처럼 보입니다(file://).

이 두 조건이 모두 충족될 경우, 특히 상대방이 정보가 응용 프로그램의 경계 내에서 오는 것인지에 따라 신뢰 여부를 결정할 경우, 일련의 공격이 가능해질 수 있습니다.

예제 1: 다음 코드는 UIWebView.loadRequest(_:) 메서드를 사용하여 로컬 파일을 로드합니다.

...
let url = Bundle.main.url(forResource: filename, withExtension: extension)
self.webView!.load(URLRequest(url:url!))
...
Example 1에서, WebView 엔진은 file://로 시작하는 URL을 사용하여 UIWebView.loadRequest(_:)를 통해 로드되는 모든 것을 권한 있는 로컬 파일 출처에 있는 것으로 취급합니다.

파일에서 로드할 때 공격자가 파일 기반 Cross-Zone Scripting 취약점을 활용하는 몇 가지 일반적인 방법이 있습니다.

- 로컬 파일이 공격자에 의해 제어될 수 있습니다. 예를 들어, 공격자가 파일을 피해자에게 보내고 이 피해자가 이 파일을 취약한 응용 프로그램(예: 클라우드 저장소 응용 프로그램)에 저장할 수 있습니다.
- 파일에 스크립트를 삽입할 수 있는 공격자에 의해 로컬 파일이 조작될 수 있습니다. 이 방법은 파일 권한, 파일의 위치 또는 파일이 저장되었다 로드될 수 있는(수정 가능 시간이 있을 수 있음) 경쟁 조건(race condition)에 따라 달라집니다.
- 파일이 외부 리소스로 호출될 수 있습니다. 로드된 파일이 외부 리소스에서 스크립트를 검색할 때 이 상황이 발생할 수 있습니다.
- 로드된 파일에 Cross-Site Scripting 취약점이 포함될 수 있습니다. 로드되고 있는 파일에 삽입된 코드가 포함된 경우, 이 코드는 응용 프로그램의 컨텍스트에서 실행될 수 있습니다. 삽입된 코드가 JavaScript 코드여야 할 필요는 없으며, 삽입된 HTML은 변조 또는 denial of service 공격을 활성화할 수도 있습니다.

공격자가 제어하는 파일이 file:// URL을 통해 로컬에 로드된 경우, 동일 출처 정책(Same Origin Policy)은 이 파일의 스크립트가 동일 출처의 다른 파일에 액세스할 수 있도록 허용하므로 공격자가 민감한 정보가 포함된 로컬 파일에 액세스할 수 있습니다.
References
[1] Same-origin policy for file: URIs Mozilla
[2] Old Habits Die Hard: Cross-Zone Scripting in Dropbox & Google Drive Mobile Apps IBM
[3] loadHTMLString(_:baseURL:) API documentation Apple
[4] loadRequest(_:) API documentation Apple
[5] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2024 [1] CWE ID 079
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] 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)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.swift.file_based_cross_zone_scripting
Abstract
사용자 입력으로 서버 쪽 리디렉션 경로를 생성하면 공격자는 응용 프로그램 바이너리(응용 프로그램 클래스 또는 jar 파일 포함)를 다운로드하거나 보호할 수 있는 디렉터리 내 임의의 파일을 볼 수 있습니다.
Explanation
다음과 같은 경우 파일 공개가 발생합니다.
1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터를 사용하여 경로를 동적으로 생성합니다.

예제 1: 다음 코드는 신뢰할 수 없는 데이터를 취하고 이를 사용하여 서버 쪽 전달에 사용되는 경로를 빌드합니다.


...
String returnURL = request.getParameter("returnURL");
RequestDispatcher rd = request.getRequestDispatcher(returnURL);
rd.forward();
...
예제 2: 다음 코드는 신뢰할 수 없는 데이터를 취하고 이를 사용하여 서버 쪽 전달에 사용되는 경로를 빌드합니다.


...
<% String returnURL = request.getParameter("returnURL"); %>
<jsp:include page="<%=returnURL%>" />
...



공격자가 민감한 파일 위치와 일치하는 요청 매개 변수를 URL에 제공한 경우, 해당 파일을 볼 수 있습니다. 예를 들어 "http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml"에서 응용 프로그램의 applicationContext.xml을 볼 수 있습니다.
공격자는 applicationContext.xml을 확보한 후 applicationContext.xml 또는 클래스나 jar 파일에서 참조된 다른 구성 파일을 찾아 다운로드할 수 있습니다. 그러면 공격자는 응용 프로그램에 대한 민감한 정보를 얻고 해당 정보를 대상으로 다른 유형의 공격을 할 수 있습니다.
References
[1] Ryan Berg and Dinis Cruz Two Security Vulnerabilities in the Spring Framework's MVC
[2] Standards Mapping - Common Weakness Enumeration CWE ID 552
[3] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.12.1 Secure File Upload Architectural Requirements (L2 L3), 12.5.1 File Download Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[13] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[14] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[16] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[29] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 073
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Web Application Security Consortium Version 2.00 URL Redirector Abuse (WASC-38)
desc.dataflow.java.file_disclosure_j2ee
Abstract
사용자 입력으로 서버 쪽 리디렉션 경로를 생성하면 공격자는 응용 프로그램 바이너리(응용 프로그램 클래스 또는 jar 파일 포함)를 다운로드하거나 보호할 수 있는 디렉터리 내 임의의 파일을 볼 수 있습니다.
Explanation
다음과 같은 경우 파일 공개가 발생합니다.
1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터를 사용하여 경로를 동적으로 생성합니다.

예제 1: 다음 코드는 신뢰할 수 없는 데이터를 취하고 이를 사용하여 서버 쪽 전달에 사용되는 경로를 빌드합니다.


...
String returnURL = request.getParameter("returnURL");
return new ModelAndView(returnURL);
...


공격자가 민감한 파일 위치와 일치하는 요청 매개 변수를 URL에 제공한 경우, 해당 파일을 볼 수 있습니다. 예를 들어 "http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml"에서 응용 프로그램의 applicationContext.xml을 볼 수 있습니다.
공격자는 applicationContext.xml을 확보한 후 applicationContext.xml 또는 클래스나 jar 파일에서 참조된 다른 구성 파일을 찾아 다운로드할 수 있습니다. 그러면 공격자는 응용 프로그램에 대한 민감한 정보를 얻고 해당 정보를 대상으로 다른 유형의 공격을 할 수 있습니다.
References
[1] Ryan Berg and Dinis Cruz Two Security Vulnerabilities in the Spring Framework's MVC
[2] Standards Mapping - Common Weakness Enumeration CWE ID 552
[3] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.12.1 Secure File Upload Architectural Requirements (L2 L3), 12.5.1 File Download Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[13] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[14] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[16] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[29] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 073
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Web Application Security Consortium Version 2.00 URL Redirector Abuse (WASC-38)
desc.dataflow.java.file_disclosure_spring
Abstract
사용자 입력으로 서버 측 리디렉션 경로를 구성하면 공격자가 응용 프로그램 바이너리(응용 프로그램 클래스 또는 jar 파일 포함)를 다운로드하거나 보호된 디렉터리 내의 임의 파일을 볼 수 있습니다.
Explanation
Spring Webflow에서 view resolver는 보기 이름을 실제 렌더링 기술로 변환하는 데 사용됩니다. 일반적으로 view resolver는 접두사 및 접미사를 사용하여 파일의 유형 및 위치를 제한합니다. 그러나 요청 매개 변수를 사용하면 보기 이름이 이 메커니즘을 회피하도록 지정됩니다.
예제 1: 다음 Spring Webflow 구성은 요청 매개 변수를 사용하여 보기 이름을 지정합니다.

<webflow:end-state id="finalStep" view="${requestParameters.url}"/>
<webflow:view-state id="showView" view="${requestParameters.test}">

기본 Spring Webflow 보기 확인자의 의도는 "/WEB-INF/views/"에 있는 jsp 파일의 확인만 허용하는 것입니다.


<bean class="org.springframework.web.servlet.view.
InternalResourceViewResolver">
<property name="prefix" value="/WEB-INF/views/" />
<property name="suffix" value=".jsp" />
</bean>


공격자는 다음 URL을 사용하여 applicationContext.xml 파일을 볼 수 있습니다. "http://www.yourcorp.com/webApp/logic?url=../applicationContext.xml;x="
InternalResourceViewResolver는 구성된 접두사를 사용하여 보기 속성으로 전달된 값을 연결하고 최종적으로 접미사를 추가합니다.
그 결과로 나온 상대 URL "/WEB-INF/views/../applicationContext.xml;x=.jsp"가 서버 측 요청 디스패처에 전달됩니다. 세미콜론을 사용하면 공격자가 ".jsp" 접미사를 경로 매개 변수로 변환할 수 있습니다. 이 공격은 웹 응용 프로그램 루트 아래 임의의 파일을 공개하는 데 사용될 수 있습니다.
References
[1] Ryan Berg and Dinis Cruz Two Security Vulnerabilities in the Spring Framework's MVC
[2] Seth Ladd Expert Spring MVC and Web Flow
[3] Standards Mapping - Common Weakness Enumeration CWE ID 552
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.12.1 Secure File Upload Architectural Requirements (L2 L3), 12.5.1 File Download Requirements (L1 L2 L3)
[11] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[14] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[16] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[17] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[30] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 073
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 URL Redirector Abuse (WASC-38)
desc.configuration.java.file_disclosure_spring_webflow
Abstract
사용자 입력으로 서버 쪽 리디렉션 경로를 생성하면 공격자는 응용 프로그램 바이너리(응용 프로그램 클래스 또는 jar 파일 포함)를 다운로드하거나 보호할 수 있는 디렉터리 내 임의의 파일을 볼 수 있습니다.
Explanation
다음과 같은 경우 파일 공개가 발생합니다.
1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터를 사용하여 경로를 동적으로 생성합니다.

예제 1: 다음 코드는 신뢰할 수 없는 데이터를 취하고 이를 사용하여 서버 쪽 전달에 사용되는 경로를 빌드합니다.


...
String returnURL = request.getParameter("returnURL");
return new ActionForward(returnURL);
...


공격자가 민감한 파일 위치와 일치하는 요청 매개 변수를 URL에 제공한 경우, 해당 파일을 볼 수 있습니다. 예를 들어 "http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml"에서 응용 프로그램의 applicationContext.xml을 볼 수 있습니다.
공격자는 applicationContext.xml을 확보한 후 applicationContext.xml 또는 클래스나 jar 파일에서 참조된 다른 구성 파일을 찾아 다운로드할 수 있습니다. 그러면 공격자는 응용 프로그램에 대한 민감한 정보를 얻고 해당 정보를 대상으로 다른 유형의 공격을 할 수 있습니다.
References
[1] Ryan Berg and Dinis Cruz Two Security Vulnerabilities in the Spring Framework's MVC
[2] Standards Mapping - Common Weakness Enumeration CWE ID 552
[3] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.12.1 Secure File Upload Architectural Requirements (L2 L3), 12.5.1 File Download Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[13] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[14] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[16] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[29] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 073
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Web Application Security Consortium Version 2.00 URL Redirector Abuse (WASC-38)
desc.dataflow.java.file_disclosure_struts
Abstract
사용자 입력이 파일 권한을 직접 변경하는 것을 허용하면 공격자가 보호된 시스템 리소스에 접근할 수 있습니다.
Explanation
File permission manipulation 오류는 다음 조건 중 하나를 만족할 때 발생합니다.

1. 공격자가 file system의 권한을 수정하는 작업에서 사용한 경로를 지정할 수 있는 경우

2. 공격자가 파일 시스템상의 작업에 의해 할당된 권한을 지정할 수 있습니다.

예제 1: 다음 코드에서는 시스템 환경 변수의 입력을 사용하여 파일 권한을 설정합니다. 공격자는 시스템 환경 변수를 변경할 수 있으면 프로그램을 사용하여 프로그램이 조작하는 파일에 접근할 수 있습니다. 프로그램이 path manipulation에도 취약한 경우 공격자는 이 취약점을 이용하여 시스템의 임의 파일에 접근할 수 있습니다.


permissions := strconv.Atoi(os.Getenv("filePermissions"));
fMode := os.FileMode(permissions)
os.chmod(filePath, fMode);
...
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - FIPS200 AC
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[10] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, MASVS-PLATFORM-1
[15] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.file_permission_manipulation
Abstract
사용자 입력이 파일 권한을 직접 변경하는 것을 허용하면 공격자가 보호된 시스템 리소스에 접근할 수 있습니다.
Explanation
파일 권한 조작 오류는 다음 조건 중 하나를 만족할 때 발생합니다.

1. 공격자가 파일 시스템에서 권한을 수정하는 작업에 사용되는 경로를 지정할 수 있습니다.

2. 공격자가 파일 시스템 상의 작업에 의해 할당된 권한을 지정할 수 있습니다.

예제 1: 다음 코드는 시스템 속성의 입력을 사용하여 기본 권한 마스크를 설정합니다. 공격자는 시스템 속성을 변경할 수 있으면 프로그램을 사용하여 프로그램이 조작하는 파일에 접근할 수 있습니다. 프로그램이 path manipulation에도 취약한 경우 공격자는 이 취약점을 이용하여 시스템의 임의 파일에 접근할 수 있습니다.


String permissionMask = System.getProperty("defaultFileMask");
Path filePath = userFile.toPath();
...
Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
Files.setPosixFilePermissions(filePath, perms);
...
References
[1] FIO01-J. Create files with appropriate access permissions CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[11] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[31] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.file_permission_manipulation
Abstract
사용자 입력이 파일 권한을 직접 변경하는 것을 허용하면 공격자가 보호된 시스템 리소스에 접근할 수 있습니다.
Explanation
파일 권한 조작 오류는 다음 조건 중 하나를 만족할 때 발생합니다.

1. 공격자가 파일 시스템에서 권한을 수정하는 작업에 사용되는 경로를 지정할 수 있습니다.

2. 공격자가 파일 시스템 상의 작업에 의해 할당된 권한을 지정할 수 있습니다.

예제 1: 다음 코드는 웹 페이지를 FTP를 통해 업로드하는 사용자를 위한 적절한 파일 권한을 설정하도록 설계되었습니다. 이 코드는 HTTP 요청의 입력을 사용하여 외부 사용자가 파일을 볼 수 있도록 표시합니다.


$rName = $_GET['publicReport'];
chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...


그러나 공격자가 "../../localuser/public_html/.htpasswd" 등과 같이 publicReport에 대해 악성 값을 제공할 경우, 응용 프로그램은 지정된 파일을 공격자가 읽을 수 있게 합니다.

예제 2: 다음 코드는 구성 파일의 입력을 사용하여 기본 권한 마스크를 설정합니다. 공격자가 구성 파일을 변경할 수 있으면, 프로그램을 사용하여 프로그램이 조작하는 파일에 접근할 수 있습니다. 프로그램이 path manipulation에도 취약한 경우 공격자는 이 취약점을 이용하여 시스템의 임의 파일에 접근할 수 있습니다.


...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[11] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[31] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.file_permission_manipulation
Abstract
사용자 입력이 파일 권한을 직접 변경하는 것을 허용하면 공격자가 보호된 시스템 리소스에 접근할 수 있습니다.
Explanation
File permission manipulation 오류는 다음 조건 중 하나를 만족할 때 발생합니다.

1. 공격자가 파일 시스템에서 권한을 수정하는 작업에 사용되는 경로를 지정할 수 있습니다.

2. 공격자가 파일 시스템상의 작업에 의해 할당된 권한을 지정할 수 있습니다.

예제 1: 다음 코드에서는 시스템 환경 변수의 입력을 사용하여 파일 권한을 설정합니다. 공격자는 시스템 환경 변수를 변경할 수 있으면 프로그램을 사용하여 프로그램이 조작하는 파일에 접근할 수 있습니다. 프로그램이 path manipulation에도 취약한 경우 공격자는 이 취약점을 이용하여 시스템의 임의 파일에 접근할 수 있습니다.


permissions = os.getenv("filePermissions");
os.chmod(filePath, permissions);
...
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - FIPS200 AC
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[10] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, MASVS-PLATFORM-1
[15] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.file_permission_manipulation
Abstract
사용자 입력이 파일 권한을 직접 변경하는 것을 허용하면 공격자가 보호된 시스템 리소스에 접근할 수 있습니다.
Explanation
파일 권한 조작 오류는 다음 조건 중 하나를 만족할 때 발생합니다.

1. 공격자가 파일 시스템에서 권한을 수정하는 작업에 사용되는 경로를 지정할 수 있습니다.

2. 공격자가 파일 시스템 상의 작업에 의해 할당된 권한을 지정할 수 있습니다.

예제 1: 다음 코드는 웹 페이지를 FTP를 통해 업로드하는 사용자를 위한 적절한 파일 권한을 설정하도록 설계되었습니다. 이 코드는 HTTP 요청의 입력을 사용하여 외부 사용자가 파일을 볼 수 있도록 표시합니다.


...
rName = req['publicReport']
File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...


그러나 공격자가 "../../localuser/public_html/.htpasswd" 등과 같이 publicReport에 대해 악성 값을 제공할 경우, 응용 프로그램은 지정된 파일을 공격자가 읽을 수 있게 합니다.

예제 2: 다음 코드는 구성 파일의 입력을 사용하여 기본 권한 마스크를 설정합니다. 공격자가 구성 파일을 변경할 수 있으면, 프로그램을 사용하여 프로그램이 조작하는 파일에 접근할 수 있습니다. 프로그램이 path manipulation에도 취약한 경우 공격자는 이 취약점을 이용하여 시스템의 임의 파일에 접근할 수 있습니다.


...
mask = config_params['perms']
File.chmod(filename, mask)
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[11] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[31] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.file_permission_manipulation
Abstract
디버깅 정보는 공격자가 시스템을 파악하고 공격 형태를 계획하는 데 도움이 됩니다.
Explanation
Blaze DS를 사용하여 예기치 못한 이벤트의 기록을 수행하는 경우, services-config.xml 설명 파일이 “Logging” XML 요소를 지정하여 로깅의 다양한 부분을 설명합니다. 다음과 같습니다.

예제 1:

<logging>
<target class="flex.messaging.log.ConsoleTarget" level="Debug">
<properties>
<prefix>[BlazeDS]</prefix>
<includeDate>false</includeDate>
<includeTime>false</includeTime>
<includeLevel>false</includeLevel>
<includeCategory>false</includeCategory>
</properties>
<filters>
<pattern>Endpoint.*</pattern>
<pattern>Service.*</pattern>
<pattern>Configuration</pattern>
</filters>
</target>
</logging>


target 태그는 level라는 옵션 속성을 갖습니다. 이는 로그 레벨을 나타냅니다. 디버그 수준이 너무 자세한 수준으로 설정되어 있으면 응용 프로그램에서 민감한 데이터를 로그 파일에 쓸 수 있습니다.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 11
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420, CCI-003272
[3] Standards Mapping - FIPS200 CM
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SA-15 Development Process and Standards and Tools (P2), SC-8 Transmission Confidentiality and Integrity (P1), SI-11 Error Handling (P2)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SA-15 Development Process and Standards and Tools, SC-8 Transmission Confidentiality and Integrity, SI-11 Error Handling
[7] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.1.3 Build (L2 L3)
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[11] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[12] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP3620 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP3620 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.flex_misconfiguration_debug_information
Abstract
공격자는 스프레드시트에 작성된 데이터를 제어할 수 있으므로, 특정 스프레드시트 프로세서에서 파일을 여는 사용자를 대상으로 공격할 수 있습니다.
Explanation
Apache OpenOffice Calc 및 Microsoft Office Excel과 같은 많이 사용하는 스프레드시트 프로세서는 강력한 수식 연산 기능을 지원하므로, 공격자가 스프레드시트를 제어하여 기본 시스템에서 임의 명령을 실행할 수 있게 하거나 스프레드시트의 민감한 정보를 누출할 수 있게 합니다.

예를 들어, 공격자가 CSV 필드의 일부로 다음 페이로드를 삽입할 수 있습니다. =cmd|'/C calc.exe'!Z0. 스프레드시트를 여는 사용자가 문서의 출처를 신뢰하는 경우, 스프레드시트 프로세서에서 제시하는 모든 보안 프롬프트를 수락하고 해당 시스템에서 페이로드(이 예제에서는 Windows 계산기를 열고 있음)가 실행될 수 있게 할 수 있습니다.

예제 1: 다음 예제는 정화되지 않은 사용자 제어 데이터로 CSV 응답을 생성하는 ASP.NET 컨트롤러를 보여줍니다.


public void Service()
{
string name = HttpContext.Request["name"];

string data = GenerateCSVFor(name);
HttpContext.Response.Clear();
HttpContext.Response.Buffer = true;
HttpContext.Response.AddHeader("content-disposition", "attachment;filename=file.csv");
HttpContext.Response.Charset = "";
HttpContext.Response.ContentType = "application/csv";
HttpContext.Response.Output.Write(tainted);
HttpContext.Response.Flush();
HttpContext.Response.End();
}
References
[1] Formula Injection Pentest Magazine
[2] Comma Separated Vulnerabilities Context
[3] Standards Mapping - Common Weakness Enumeration CWE ID 1236
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.formula_injection
Abstract
공격자는 스프레드시트에 작성된 데이터를 제어할 수 있으므로, 특정 스프레드시트 프로세서에서 파일을 여는 사용자를 대상으로 공격할 수 있습니다.
Explanation
Apache OpenOffice Calc 및 Microsoft Office Excel과 같은 많이 사용하는 스프레드시트 프로세서는 강력한 수식 연산 기능을 지원하므로, 공격자가 스프레드시트를 제어하여 기본 시스템에서 임의 명령을 실행할 수 있게 하거나 스프레드시트의 민감한 정보를 누출할 수 있게 합니다.

예를 들어, 공격자가 CSV 필드의 일부로 다음 페이로드를 삽입할 수 있습니다. =cmd|'/C calc.exe'!Z0. 스프레드시트를 여는 사용자가 문서의 출처를 신뢰하는 경우, 스프레드시트 프로세서에서 제시하는 모든 보안 프롬프트를 수락하고 해당 시스템에서 페이로드(이 예제에서는 Windows 계산기를 열고 있음)가 실행될 수 있게 할 수 있습니다.

예제 1: 다음 예제는 정화되지 않은 사용자 제어 데이터를 사용하여 csv 파일에 내용을 작성합니다.


func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
foo := r.FormValue("foo")
...
w := csv.NewWriter(file)
w.Write(foo)
}
References
[1] Formula Injection Pentest Magazine
[2] Comma Separated Vulnerabilities Context
[3] Standards Mapping - Common Weakness Enumeration CWE ID 1236
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.formula_injection
Abstract
공격자는 스프레드시트에 작성된 데이터를 제어할 수 있으므로, 특정 스프레드시트 프로세서에서 파일을 여는 사용자를 대상으로 공격할 수 있습니다.
Explanation
Apache OpenOffice Calc 및 Microsoft Office Excel과 같은 많이 사용하는 스프레드시트 프로세서는 강력한 수식 연산 기능을 지원하므로, 공격자가 스프레드시트를 제어하여 기본 시스템에서 임의 명령을 실행할 수 있게 하거나 스프레드시트의 민감한 정보를 누출할 수 있게 합니다.

예를 들어, 공격자가 CSV 필드의 일부로 다음 페이로드를 삽입할 수 있습니다. =cmd|'/C calc.exe'!Z0. 스프레드시트를 여는 사용자가 문서의 출처를 신뢰하는 경우, 스프레드시트 프로세서에서 제시하는 모든 보안 프롬프트를 수락하고 해당 시스템에서 페이로드(이 예제에서는 Windows 계산기를 열고 있음)가 실행될 수 있게 할 수 있습니다.

예제 1: 다음 예제는 정화되지 않은 사용자 제어 데이터로 CSV 응답을 생성하는 Spring 컨트롤러를 보여줍니다.


@RequestMapping(value = "/api/service.csv")
public ResponseEntity<String> service(@RequestParam("name") String name) {

HttpHeaders responseHeaders = new HttpHeaders();
responseHeaders.add("Content-Type", "application/csv; charset=utf-8");
responseHeaders.add("Content-Disposition", "attachment;filename=file.csv");

String data = generateCSVFor(name);

return new ResponseEntity<>(data, responseHeaders, HttpStatus.OK);
}
References
[1] Formula Injection Pentest Magazine
[2] Comma Separated Vulnerabilities Context
[3] Standards Mapping - Common Weakness Enumeration CWE ID 1236
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.formula_injection
Abstract
공격자는 스프레드시트에 작성된 데이터를 제어할 수 있으므로, 특정 스프레드시트 프로세서에서 파일을 여는 사용자를 대상으로 공격할 수 있습니다.
Explanation
Apache OpenOffice Calc 및 Microsoft Office Excel과 같은 많이 사용하는 스프레드시트 프로세서는 강력한 수식 연산 기능을 지원하므로, 공격자가 스프레드시트를 제어하여 기본 시스템에서 임의 명령을 실행할 수 있게 하거나 스프레드시트의 민감한 정보를 누출할 수 있게 합니다.

예를 들어, 공격자가 CSV 필드의 일부로 다음 페이로드를 삽입할 수 있습니다. =cmd|'/C calc.exe'!Z0. 스프레드시트를 여는 사용자가 문서의 출처를 신뢰하는 경우, 스프레드시트 프로세서에서 제시하는 모든 보안 프롬프트를 수락하고 해당 시스템에서 페이로드(이 예제에서는 Windows 계산기를 열고 있음)가 실행될 수 있게 할 수 있습니다.

예제 1: 다음 예제는 정화되지 않은 사용자 제어 데이터로 CSV 응답을 생성하는 Spring 컨트롤러를 보여줍니다.


@RequestMapping(value = "/api/service.csv")
fun service(@RequestParam("name") name: String): ResponseEntity<String> {
val responseHeaders = HttpHeaders()
responseHeaders.add("Content-Type", "application/csv; charset=utf-8")
responseHeaders.add("Content-Disposition", "attachment;filename=file.csv")
val data: String = generateCSVFor(name)
return ResponseEntity(data, responseHeaders, HttpStatus.OK)
}
References
[1] Formula Injection Pentest Magazine
[2] Comma Separated Vulnerabilities Context
[3] Standards Mapping - Common Weakness Enumeration CWE ID 1236
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.kotlin.formula_injection
Abstract
PreferenceActivity를 확장하는 Android 작업이 인스턴스화할 수 있는 조각 클래스를 제한하지 않습니다.
Explanation
악성 응용 프로그램이 안전하지 않은 PreferenceActivity를 실행하고 임의 클래스를 로드할 수 있도록 만들기 위해 :android:show_fragment 인텐트 엑스트라를 제공할 수 있습니다. 악성 응용 프로그램이 PreferenceActivity를 통해 취약한 응용 프로그램의 임의 Fragment를 로드할 수 있으며, 일반적으로 내보내지 않는 작업 내부에 로드되어 공격자에게 작업을 노출시킵니다.

예제 1: 다음 코드는 예상된 조각만 로드되는지 확인하는 검사를 구현하지 않습니다.


@Override
public static boolean isFragmentValid(Fragment paramFragment)
{
return true;
}
References
[1] Roee Hay A New Vulnerability in the Android Framework: Fragment Injection
[2] Standards Mapping - Common Weakness Enumeration CWE ID 470
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.java.fragment_injection
Abstract
신뢰할 수 없는 소스에서 Google Remote Procedure Call(gRPC) Metadata 개체가 생성됩니다. 그러므로 공격자가 중요한 프로토콜 필드를 제어하게 될 수 있습니다.
Explanation
Metadata 클래스는 Google Remote Procedure Call(gRPC)에서 사용하는 기본 프로토콜의 헤더 데이터를 저장하는 데 사용되는 경우가 많습니다. 기본 프로토콜이 HTTP일 때는 Metadata 개체의 데이터를 제어하면 시스템이 HTTP 헤더 조작에 취약해질 수 있습니다. 공격자가 다른 공격 벡터(대개 기본 프로토콜 기반)를 이용할 수 있기 때문입니다.

예제 1: 다음 코드는 gRPC Metadata 개체의 입력으로 사용되는 신뢰할 수 없는 데이터를 보여줍니다.


...
String? evnVar = System.Environment.GetEnvironmentVariable("evnVar ");
Metadata headers = new Metadata();
headers.Add("field", evnVar);
CallOptions callOptions = new CallOptions(headers);
...
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - FIPS200 SI
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[6] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
desc.dataflow.dotnet.grpc_metadata_manipulation
Abstract
신뢰할 수 없는 소스에서 Google Remote Procedure Call(gRPC) Metadata 개체가 생성됩니다. 그러므로 공격자가 중요한 프로토콜 필드를 제어하게 될 수도 있습니다.
Explanation
Metadata 클래스는 Google Remote Procedure Call(gRPC)에서 사용하는 기본 프로토콜의 헤더 데이터를 저장하는 데 사용되는 경우가 많습니다. 기본 프로토콜이 HTTP일 때는 Metadata 개체의 데이터를 제어하면 시스템이 HTTP 헤더 조작에 취약해질 수 있습니다. 공격자가 다른 공격 벡터(대개 기본 프로토콜 기반)를 이용할 수 있기 때문입니다.

예제 1: 다음 코드는 gRPC Metadata 개체의 입력으로 사용되는 사용자 제어 가능 데이터를 보여줍니다.


...
String badData = getUserInput();
Metadata headers = new Metadata();
headers.put(Metadata.Key.of("sample", Metadata.ASCII_STRING_MARSHALLER), badData);
...
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - FIPS200 SI
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[6] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
desc.dataflow.java.grpc_metadata_manipulation
Abstract
프로그램을 통해 공격자는 클라이언트 응용 프로그램이 실행되는 Hadoop 클러스터의 핵심 구성 요소를 제어할 수 있습니다.
Explanation
Hadoop 클러스터 제어 오류는 다음 경우에 발생합니다.

- 신뢰할 수 없는 소스의 데이터가 프로그램에 입력됩니다.

- Hadoop 클러스터 핵심 구성 요소에서 사용하는 데이터(예: NameNode, DataNode, JobTraker)가 클러스터의 상태를 변경합니다.

Hadoop 클러스터는 위험한 환경입니다. 클라우드 노드에 무단으로 접근하지 못하도록 방지하는 보안 구성을 적절히 설정하지 않을 경우 공격자가 인프라를 제어할 수 있습니다. 이로 인해 Hadoop 클러스터에서 제공하는 모든 데이터가 조작될 수 있습니다.

예제 1: 다음 코드는 Hadoop 클러스터 마스터 컴퓨터의 명령줄에서 입력을 받는 일반적인 클라이언트 응용 프로그램에서의 Job 전송을 보여 줍니다.


public static void run(String args[]) throws IOException {

String path = "/path/to/a/file";
DFSclient client = new DFSClient(arg[1], new Configuration());
ClientProtocol nNode = client.getNameNode();

/* This sets the ownership of a file pointed by the path to a user identified
* by command line arguments.
*/
nNode.setOwner(path, args[2], args[3]);
...
}
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[5] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[6] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] 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
[15] 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
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.hadoop_cluster_manipulation
Abstract
Hadoop 클러스터에 전송되는 Job은 위험한 환경에서 조작될 수 있습니다.
Explanation
Hadoop 작업 조작 오류는 다음과 같은 경우에 발생합니다.

- 신뢰할 수 없는 소스의 데이터가 프로그램에 입력됩니다.

- 이러한 데이터를 사용하여 클라이언트 작업을 제어하는 JobConf의 값을 지정합니다.

Hadoop 클러스터는 위험한 환경입니다. 클러스터 컴퓨터의 HDFS에 무단으로 접근하지 못하도록 방지하는 보안 구성을 적절히 설정하지 않을 경우 공격자가 시스템을 제어할 수 있습니다. 이로 인해 Hadoop 클러스터에서 제공하는 모든 데이터가 조작될 수 있습니다.

예제 1: 다음 코드는 Hadoop 클러스터 마스터 컴퓨터의 명령줄에서 입력을 받는 일반적인 클라이언트 응용 프로그램에서의 Job 전송을 보여 줍니다.


public void run(String args[]) throws IOException {

String inputDir = args[0];
String outputDir = args[1];

// Untrusted command line argument
int numOfReducers = Integer.parseInt(args[3]);
Class mapper = getClassByName(args[4]);
Class reducer = getClassByName(args[5]);

Configuration defaults = new Configuration();
JobConf job = new JobConf(defaults, OptimizedDataJoinJob.class);
job.setNumMapTasks(1);
// An attacker may set random values that exceed the range of acceptable number of reducers
job.setNumReduceTasks(numOfReducers);

return job;
}
예제 2: 다음 코드는 공격자가 명령줄 인수를 통해 실행 중인 작업을 중단하도록 제어하는 경우를 보여 줍니다.


public static void main(String[] args) throws Exception {

JobID id = JobID.forName(args[0]);
JobConf conf = new JobConf(WordCount.class);
// configure this JobConf instance
...
JobClient.runJob(conf);
RunningJob job = JobClient.getJob(id);
job.killJob();

}
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[5] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[6] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] 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
[15] 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
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.hadoop_job_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 응용 프로그램 서버가 줄 바꿈 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 줄바꿈 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 HTTP 요청에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.


...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...


"Jane Smith"와 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 이 쿠키가 포함된 HTTP 응답은 다음과 같은 형식이 됩니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


하지만 쿠키의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirection: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 Cache-Poisoning, Cross-Site Scripting, Cross-User Defacement 또는 Page Hijacking, Cookie Manipulation 또는 Open Redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 웹 응용 프로그램에 들어갑니다.


2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 injection되는 것을 방지합니다. 예를 들어, Apache Tomcat의 최신 버전은 금지된 문자로 헤더를 설정할 경우 IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 Cookie Manipulation 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드는 공격자가 이름과 값을 제어할 수 있는 HTTP 헤더를 설정합니다.


@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();

RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}


이름/값 쌍이 authorJane Smith로 구성되어 있다고 가정할 때 이 헤더를 포함하는 HTTP 응답은 다음과 같은 형식일 수 있습니다.


HTTP/1.1 200 OK
...
author:Jane Smith
...


그러나 헤더 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 공격자가 HTTP/1.1 200 OK\r\n...foobar와 같은 악성 이름/값 쌍을 전송할 수 있습니다. 그러면 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보내 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특수하게 고안된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 콘텐트를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

Cookie Manipulation: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하고 해당 쿠키에 추가하거나 쿠키를 덮어쓰기도 할 수 있습니다.

Open Redirection: 리디렉션에 사용된 URL을 제어하도록 확인되지 않은 입력을 허용하면 피싱 공격에 도움이 됩니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버 및 프레임워크는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 예를 들어, 최근 Microsoft의 .NET 프레임워크 버전은 CR, LF 및 NULL 문자를 HttpResponse.AddHeader() 메서드로 보낼 때 %0d, %0a 및 %00으로 변환합니다. 새 줄 문자로 헤더를 설정하지 못하도록 방지하는 최신 .NET 프레임워크를 사용한다면, 응용 프로그램은 HTTP Response Splitting에 취약하지 않을 수도 있습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 HTTP 요청에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.


protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...


"Jane Smith"와 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 이 쿠키가 포함된 HTTP 응답은 다음과 같은 형식이 됩니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


하지만 쿠키의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 Author.Text에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirect: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking) 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 악성 문자 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 HTTP 폼에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.


...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.

EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...


"Jane Smith"와 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 이 쿠키가 포함된 HTTP 응답은 다음과 같은 형식이 됩니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


하지만 쿠키의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 AUTHOR에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirection: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cobol.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 웹 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 예를 들어, Apache Tomcat의 최신 버전은 금지된 문자로 헤더를 설정할 경우 IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 웹 폼에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.


<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">


"Jane Smith"와 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 이 쿠키가 포함된 HTTP 응답은 다음과 같은 형식이 됩니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


하지만 쿠키의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1/1 200 OK
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-Site Scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirection: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 Cache-Poisoning, Cross-Site Scripting, Cross-User Defacement 또는 Page Hijacking, Cookie Manipulation 또는 Open Redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 유효성 검사를 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 injection되는 것을 방지합니다. 예를 들어, Apache Tomcat의 최신 버전은 금지된 문자로 헤더를 설정할 경우 IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 Cookie Manipulation 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 HTTP 요청에서 'content-type'을 읽어들여 새 HTTP 요청의 헤더에 설정합니다.


final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});


'Content-Type' 헤더의 값은 유효성이 검사되지 않은 사용자 입력을 사용하여 생성되므로 악의적 작업자가 해당 값을 조작하여 취약성 악용, 코드 주입 공격 실행, 중요한 데이터 노출 등의 악의적인 행위를 할 수도 있고 악성 파일을 실행할 수 있도록 설정하거나 서비스 거부 상황을 유발할 수도 있습니다. 그러면 응용 프로그램의 보안과 안정성이 크게 저하되어 매우 위험해집니다.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dart.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 Cache-Poisoning, Cross-Site Scripting, Cross-User Defacement 또는 Page Hijacking, Cookie Manipulation 또는 Open Redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.


예제 1: 다음 코드 세그먼트는 HTTP 요청에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.


...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...


공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보내 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 콘텐트를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

Cookie Manipulation: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하고 해당 쿠키에 추가하거나 쿠키를 덮어쓰기도 할 수 있습니다.

Open Redirection: 리디렉션에 사용된 URL을 제어하도록 확인되지 않은 입력을 허용하면 피싱 공격에 도움이 됩니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Standards Mapping - Common Weakness Enumeration CWE ID 113
[3] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 예를 들어, Apache Tomcat의 최신 버전은 금지된 문자로 헤더를 설정할 경우 IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 HTTP 요청에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.


String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);


"Jane Smith"와 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 이 쿠키가 포함된 HTTP 응답은 다음과 같은 형식이 됩니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


하지만 쿠키의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirection: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 HTTP 요청에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.


author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...


"Jane Smith"와 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 이 쿠키가 포함된 HTTP 응답은 다음과 같은 형식이 됩니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


하지만 쿠키의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있는 능력이 생기면 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.


캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirection: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.


2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 예를 들어, Apache Tomcat의 최신 버전은 금지된 문자로 헤더를 설정할 경우 IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 namevalue가 공격자에 의해 제어될 수 있다고 가정합니다. 코드는 이름 및 값이 공격자에 의해 제어될 수 있는 HTTP 헤더를 설정합니다.


...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...


이름/값 쌍이 authorJane Smith로 구성되었다고 가정하면 이 헤더가 포함된 HTTP 응답의 형식은 다음과 같을 수 있습니다.


HTTP/1.1 200 OK
...
author:Jane Smith
...


하지만 헤더의 값이 확인되지 않은 사용자 입력의 형식이기 때문에 공격자가 HTTP/1.1 200 OK\r\n...foobar와 같은 악의적인 이름/값 쌍을 제출할 수 있고 그러면 HTTP 응답이 다음 형식의 두 응답으로 분할됩니다.


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirect: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.objc.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 예를 들어, 최근 PHP 버전은 새 줄이 header() 함수에 전달될 때 경고를 생성하고 헤더 생성을 중단합니다. 사용 중인 PHP 버전이 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 HTTP 요청에서 위치를 읽어들이며 이를 HTTP 응답의 헤더 위치 필드에 설정합니다.


<?php
$location = $_GET['some_location'];
...
header("location: $location");
?>


"index.html"과 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 이 쿠키가 포함된 HTTP 응답은 다음과 같은 형식이 됩니다.


HTTP/1.1 200 OK
...
location: index.html
...


하지만 위치의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 some_location에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "index.html\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirection: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 HTTP 요청에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.


...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...


"Jane Smith"와 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 이 쿠키가 포함된 HTTP 응답은 다음과 같은 형식이 됩니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


하지만 쿠키의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirect: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.sql.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 HTTP 요청에서 위치를 읽어들이며 이를 헤더에서 HTTP 응답의 위치 필드로 설정합니다.


location = req.field('some_location')
...
response.addHeader("location",location)


"index.html"과 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 이 쿠키가 포함된 HTTP 응답은 다음과 같은 형식이 됩니다.


HTTP/1.1 200 OK
...
location: index.html
...


하지만 위치의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 some_location에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "index.html\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirection: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 예를 들어, Apache Tomcat의 최신 버전은 금지된 문자로 헤더를 설정할 경우 IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 HTTP 요청에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 사이트의 다른 부분에 대한 get 요청에 사용합니다.


author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")


"Jane Smith"와 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 HTTP 응답은 다음과 같은 형식이 됩니다.


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...


하지만 URL의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker

POST /index.php HTTP/1.1
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirection: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] 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
[28] 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
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.ruby.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 Cache-Poisoning, Cross-Site Scripting, Cross-User Defacement 또는 Page Hijacking, Cookie Manipulation 또는 Open Redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 예를 들어 금지된 문자로 헤더를 설정하려고 하면 Play Framework에서 예외가 발생합니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 Cookie Manipulation 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.


2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 예를 들어, Apache Tomcat의 최신 버전은 금지된 문자로 헤더를 설정할 경우 IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.

예제 1: 다음 코드 세그먼트는 namevalue가 공격자에 의해 제어될 수 있다고 가정합니다. 코드는 이름 및 값이 공격자에 의해 제어될 수 있는 HTTP 헤더를 설정합니다.


...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...


이름/값 쌍이 authorJane Smith로 구성되었다고 가정하면 이 헤더가 포함된 HTTP 응답의 형식은 다음과 같을 수 있습니다.


HTTP/1.1 200 OK
...
author:Jane Smith
...


하지만 헤더의 값이 확인되지 않은 사용자 입력의 형식이기 때문에 공격자가 HTTP/1.1 200 OK\r\n...foobar와 같은 악의적인 이름/값 쌍을 제출할 수 있고 그러면 HTTP 응답이 다음 형식의 두 응답으로 분할됩니다.


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirect: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.swift.header_manipulation
Abstract
HTTP 응답 헤더에 확인되지 않은 데이터를 포함하면 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement) 또는 페이지 하이재킹(page hijacking), 쿠키 조작 또는 open redirection 공격을 유발할 수 있습니다.
Explanation
Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 확인 작업을 거치지 않고 웹 사용자에게 전달된 HTTP 응답 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 HTTP 응답 헤더에 데이터를 포함합니다.

가장 일반적인 Header Manipulation 공격의 하나는 HTTP Response Splitting 입니다. HTTP Response Splitting 익스플로이트가 성공하려면 응용 프로그램은 헤더에 CR(캐리지 리턴, %0d 또는 \r로도 표시) 및 LF(줄 바꿈, %0a 또는 \n으로도 표시) 문자가 있는 입력을 허용해야 합니다. 이들 문자는 공격자에게 응용 프로그램이 보내려는 응답의 나머지 헤더 및 본문에 대한 제어권을 부여할 뿐 아니라 추가 응답을 공격자 마음대로 만들 수 있게 합니다.

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지하지만 클래식 ASP를 지원하는 서버에는 대개 해당 보호 메커니즘이 없습니다.

예제 1: 다음 코드 세그먼트는 HTTP 요청에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.


...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...


"Jane Smith"와 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 이 쿠키가 포함된 HTTP 응답은 다음과 같은 형식이 됩니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


하지만 쿠키의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


두 번째 응답은 공격자가 완전히 제어하고 있으므로 원하는 헤더와 본문 내용으로 마음대로 작성할 수 있습니다. 공격자가 임의의 HTTP 응답을 작성할 수 있으므로 교차 사용자 변조(cross-user defacement), 웹 및 브라우저 캐시 감염(cache-poisoning), Cross-Site Scripting 및 페이지 하이재킹(page hijacking) 등의 다양한 공격을 할 수 있습니다.

교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.

캐시 감염(cache-poisoning): 여러 사용자가 사용하는 웹 캐시 또는 단일 사용자의 브라우저 캐시에서 악의적인 목적으로 생성된 응답을 캐시하는 경우 그 영향이 확대됩니다. 프록시 서버에서 흔히 볼 수 있는 것과 같이 공유 웹 캐시에 응답이 캐시되는 경우, 해당 캐시의 모든 사용자가 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받습니다. 마찬가지로 응답이 개인 사용자의 브라우저에 캐시되는 경우, 해당 사용자는 캐시 항목이 없어질 때까지 악성 콘텐트를 계속 받게 되지만 로컬 브라우저 인스턴스의 사용자만 영향을 받습니다.

Cross-Site Scripting: 공격자가 응용 프로그램이 보내는 응답을 제어하게 되면 다양한 악성 컨텐츠를 선택하여 사용자에게 보낼 수 있습니다. Cross-site scripting은 응답에 포함된 악의적인 JavaScript 또는 기타 코드가 사용자의 브라우저에서 실행되는 경우의 일반적인 공격 형태입니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다. 취약한 응용 프로그램의 사용자에게 가장 일반적이고 위험한 공격은 JavaScript를 사용하여 세션 및 authentication 정보를 공격자에게 전송하는 것입니다. 그러면 공격자는 피해자 계정을 완전히 장악할 수 있습니다.

페이지 하이재킹(page hijacking): 취약한 응용 프로그램을 사용하여 악성 콘텐트를 사용자에게 보내는 것 외에, 같은 취약점을 이용하여 서버가 사용자에게 보내기 위해 생성한 민감한 콘텐트를 공격자에게 리디렉션할 수도 있습니다. 공격자는 의도한 서버의 응답과 공격자가 생성한 응답 두 가지를 생성하는 요청을 전송하여, 공유 프록시 서버 같은 중간 노드에서 서버에서 생성되어 사용자에게 가야 할 응답을 공격자에게 보내도록 할 수 있습니다. 공격자가 만든 요청은 두 가지 응답을 생성하기 때문에 첫 번째는 공격자의 요청에 대한 응답으로 해석되고 두 번째는 불확실한 상태로 남게 됩니다. 사용자가 한 TCP 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

쿠키 조작: Cross-Site Request Forgery와 같은 공격과 결합된 경우, 공격자는 올바른 사용자의 쿠키를 변경하거나 해당 쿠키에 추가하거나 쿠키를 덮어쓸 수도 있습니다.

Open Redirect: 확인되지 않은 입력이 리디렉션에 사용되는 URL을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation