8 개 항목 찾음
취약점
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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 웹 폼에서 웹로그 엔트리의 작성자 이름인 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[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 Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] 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 응답 헤더에 데이터를 포함합니다.


예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[50] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[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 Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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를 지원하는 서버에는 대개 해당 보호 메커니즘이 없습니다.

예제: 다음 코드 세그먼트는 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 - 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation
Abstract
쿠키에 확인되지 않은 데이터를 포함하면 HTTP 응답 헤더를 조작할 수 있게 되며 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement), 페이지 하이재킹(page hijacking), 쿠키 조작, open redirection 등이 가능해집니다.
Explanation
쿠키 조작 취약점은 다음과 같은 경우에 발생합니다.

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

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

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

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

HTTP 응답 헤더를 대상으로 하는 쿠키 조작 공격은 다음과 같은 다른 유형의 공격으로 이어질 수 있습니다.

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

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

예제: 다음 코드 세그먼트는 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 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

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 - 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 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.1 - Web 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation_cookies
Abstract
쿠키에 확인되지 않은 데이터를 포함하면 HTTP 응답 Header Manipulation할 수 있게 되며 Cache-Poisoning, Cross-Site Scripting, Cross-User Defacement, Page Hijacking, Cookie Manipulation 또는 Open Redirection 등이 가능해집니다.
Explanation
Cookie Manipulation 취약점은 다음과 같은 경우에 발생합니다.

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



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



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

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

HTTP 응답 헤더를 대상으로 하는 Cookie Manipulation 공격은 다음과 같은 다른 유형의 공격으로 이어질 수 있습니다.

HTTP Response Splitting:
가장 일반적인 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 요청에서 웹로그 엔트리의 작성자 이름 author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.


...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...


"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 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

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 - 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 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.1 - Web 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation_cookies
Abstract
쿠키에 확인되지 않은 데이터를 포함하면 HTTP 응답 헤더를 조작할 수 있게 되며 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement), 페이지 하이재킹(page hijacking), 쿠키 조작, open redirection 등이 가능해집니다.
Explanation
쿠키 조작 취약점은 다음과 같은 경우에 발생합니다.

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

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

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

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

HTTP 응답 헤더를 대상으로 하는 쿠키 조작 공격은 다음과 같은 다른 유형의 공격으로 이어질 수 있습니다.

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

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

예제: 다음 코드 세그먼트는 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_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 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

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 - 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 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.1 - Web 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation_cookies
Abstract
쿠키에 확인되지 않은 데이터를 포함하면 HTTP 응답 헤더를 조작할 수 있게 되며 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement), 페이지 하이재킹(page hijacking), 쿠키 조작, open redirection 등이 가능해집니다.
Explanation
쿠키 조작 취약점은 다음과 같은 경우에 발생합니다.

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

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

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

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

HTTP 응답 헤더를 대상으로 하는 쿠키 조작 공격은 다음과 같은 다른 유형의 공격으로 이어질 수 있습니다.

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

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

예제: 다음 코드 세그먼트는 HTTP 요청에서 웹로그 엔트리의 작성자 이름 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 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

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 - 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 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.1 - Web 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation_cookies
Abstract
쿠키에 확인되지 않은 데이터를 포함하면 HTTP 응답 Header Manipulation할 수 있게 되며 Cache-Poisoning, Cross-Site Scripting, Cross-User Defacement, Page Hijacking, Cookie Manipulation 또는 Open Redirection 등이 가능해집니다.
Explanation
Cookie Manipulation 취약점은 다음과 같은 경우에 발생합니다.

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

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

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

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

HTTP 응답 헤더를 대상으로 하는 쿠키 조작 공격은 다음과 같은 다른 유형의 공격으로 이어질 수 있습니다.

HTTP Response Splitting:
가장 일반적인 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 헤더를 설정할 때는 여전히 주의해야 합니다.

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


...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &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 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

Open Redirection: 리디렉션에 사용된 URL을 제어하도록 확인되지 않은 입력을 허용하면 피싱 공격에 도움이 됩니다.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[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 Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation_cookies
Abstract
쿠키에 확인되지 않은 데이터를 포함하면 HTTP 응답 헤더를 조작할 수 있게 되며 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement), 페이지 하이재킹(page hijacking), 쿠키 조작, open redirection 등이 가능해집니다.
Explanation
쿠키 조작 취약점은 다음과 같은 경우에 발생합니다.

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

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

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

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

HTTP 응답 헤더를 대상으로 하는 쿠키 조작 공격은 다음과 같은 다른 유형의 공격으로 이어질 수 있습니다.

HTTP Response Splitting:
가장 일반적인 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) 등의 다양한 공격을 할 수 있습니다.

모바일 환경에서는 Header Manipulation 및 쿠키 조작과 같은 전형적인 웹 응용 프로그램 취약성이 발생하지 않는다고 생각하는 사용자도 있습니다. 자기 자신을 공격하는 사용자는 없을 것이라 여기기 때문입니다. 그러나 모바일 플랫폼의 핵심 요소는 다양한 소스에서 다운로드되어 같은 장치에서 함께 실행되는 응용 프로그램이라는 점을 유념해야 합니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 프로세스 간 통신을 포함하도록 모바일 응용 프로그램의 공격 표면을 확장해야 합니다.

예제 2: 다음 코드는 Example 1을 Android 플랫폼에 맞게 조정합니다.


...
CookieManager webCookieManager = CookieManager.getInstance();
String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
webCookieManager.setCookie(url, setCookie);

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

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

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

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

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 - 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 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.1 - Web 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation_cookies
Abstract
쿠키에 확인되지 않은 데이터를 포함하면 HTTP 응답 헤더를 조작할 수 있게 되며 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement), 페이지 하이재킹(page hijacking), 쿠키 조작, open redirection 등이 가능해집니다.
Explanation
쿠키 조작 취약점은 다음과 같은 경우에 발생합니다.

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

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

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

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

HTTP 응답 헤더를 대상으로 하는 쿠키 조작 공격은 다음과 같은 다른 유형의 공격으로 이어질 수 있습니다.

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

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

예제: 다음 코드 세그먼트는 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 응답을 작성할 수 있으므로 교차 사용자 변조(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 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

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 - 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 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.1 - Web 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation_cookies
Abstract
쿠키에 확인되지 않은 데이터를 포함하면 HTTP 응답 헤더를 조작할 수 있게 되며 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement), 페이지 하이재킹(page hijacking), 쿠키 조작, open redirection 등이 가능해집니다.
Explanation
쿠키 조작 취약점은 다음과 같은 경우에 발생합니다.

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

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

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

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

HTTP 응답 헤더를 대상으로 하는 쿠키 조작 공격은 다음과 같은 다른 유형의 공격으로 이어질 수 있습니다.

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

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

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


<?php
$author = $_GET['AUTHOR_PARAM'];
...
header("author: $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 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

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 - 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 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.1 - Web 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation_cookies
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 헤더를 설정할 때는 여전히 주의해야 합니다.

예제: 다음 코드 세그먼트는 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 - 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 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.1 - Web 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] 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, Cookie Manipulation 또는 Open Redirection 등이 가능해집니다.
Explanation
Cookie Manipulation 취약점은 다음과 같은 경우에 발생합니다.

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

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

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

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

HTTP 응답 헤더를 대상으로 하는 Cookie Manipulation 공격은 다음과 같은 다른 유형의 공격으로 이어질 수 있습니다.

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

현대의 많은 응용 프로그램 서버는 악성 문자가 HTTP 헤더에 삽입되는 것을 방지합니다. 예를 들어, Apache Tomcat의 최신 버전은 금지된 문자로 헤더를 설정할 경우 IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 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 - 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 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.1 - Web 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation_cookies
Abstract
쿠키에 확인되지 않은 데이터를 포함하면 HTTP 응답 헤더를 조작할 수 있게 되며 캐시 감염(cache-poisoning), cross-site scripting, 교차 사용자 변조(cross-user defacement), 페이지 하이재킹(page hijacking), 쿠키 조작, open redirection 등이 가능해집니다.
Explanation
쿠키 조작 취약점은 다음과 같은 경우에 발생합니다.

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

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

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

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

HTTP 응답 헤더를 대상으로 하는 쿠키 조작 공격은 다음과 같은 다른 유형의 공격으로 이어질 수 있습니다.

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

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

예제: 다음 코드 세그먼트는 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 연결을 통해 올바른 요청을 할 때 공격자의 요청이 이미 대기하고 있다가 사용자의 요청에 대한 응답으로 해석됩니다. 그런 다음, 공격자가 서버에 두 번째 요청을 보내면 프록시 서버가 피해자에게 보내기 위해 서버가 생성해 놓은 요청으로 응답합니다. 따라서 피해자가 수신해야 할 응답의 헤더와 본문에 있는 민감한 정보가 노출되는 것입니다.

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 - 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 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.1 - Web 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation_cookies
Abstract
SMTP 헤더에 확인되지 않은 데이터를 포함하면 공격자가 메일 서버를 스팸 봇으로 사용하거나 메일 내용을 자신에게 누출시키는 데 사용할 수 있는 CC, BCC 등의 임의 헤더를 추가할 수 있습니다.
Explanation
SMTP Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.
1. 데이터가 신뢰할 수 없는 소스, 주로 웹 응용 프로그램의 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터가 확인 작업을 거치지 않고 메일 서버로 전송되는 SMTP 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 SMTP Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 SMTP 헤더에 데이터를 포함합니다.
가장 일반적인 SMTP Header Manipulation 공격 중 하나는 스팸 전자 메일 유포입니다. 전자 메일의 제목과 본문을 설정하도록 허용하는 취약한 "문의처" 양식이 응용 프로그램에 있는 경우, 전자 메일이 공격을 당한 서버로부터 전송되기 때문에 공격자는 임의의 콘텐트를 설정하고 익명으로 스팸을 발송할 전자 메일 주소 목록이 포함된 CC 헤더를 삽입할 수 있습니다.
예제: 다음 코드 세그먼트는 "문의처" 양식의 제목과 본문을 읽습니다.

func handler(w http.ResponseWriter, r *http.Request) {
subject := r.FormValue("subject")
body := r.FormValue("body")
auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
to := []string{"recipient@example.net"}
msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
if err != nil {
log.Fatal(err)
}
}

"Page not working"과 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 SMTP 헤더는 다음과 같은 형식이 될 수 있습니다.

...
subject: [Contact us query] Page not working
...

하지만 헤더의 값이 확인되지 않은 사용자 입력에서 생성되기 때문에 응답은 subject에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..."과 같은 악의적인 문자열을 제출하는 경우 SMTP 헤더는 다음과 같은 형식이 됩니다.

...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...

따라서 공격자는 실제로 스팸 메시지를 작성하거나 익명 전자 메일을 전송하는 등의 다양한 공격을 진행할 수 있습니다.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 93
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[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 Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.golang.header_manipulation_smtp
Abstract
SMTP 헤더에 확인되지 않은 데이터를 포함하면 해커는 메일 콘텐트를 자신에게 누출하거나 메일 서버를 스팸 봇으로 이용하는 데 사용할 수 있는 CC 또는 BCC와 같은 임의의 헤더를 추가할 수 있습니다.
Explanation
SMTP Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

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

2. 데이터가 확인을 거치지 않고 메일 서버에 전송된 SMTP 헤더에 포함됩니다.

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

가장 일반적인 SMTP Header Manipulation 공격 중 하나는 스팸 전자 메일의 유포에 사용됩니다. 전자 메일의 제목과 본문을 설정하도록 허용하는 취약한 "문의처" 양식이 응용 프로그램에 있는 경우, 전자 메일이 공격을 당한 서버로부터 전송되기 때문에 공격자는 임의의 콘텐트를 설정하고 익명으로 스팸을 발송할 전자 메일 주소 목록이 포함된 CC 헤더를 삽입할 수 있습니다.

예제: 다음 코드 세그먼트는 "문의처" 양식의 제목 및 본문을 읽습니다.


String subject = request.getParameter("subject");
String body = request.getParameter("body");
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("webform@acme.com"));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
message.setSubject("[Contact us query] " + subject);
message.setText(body);
Transport.send(message);


"Page not working"과 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 SMTP 헤더는 다음과 같은 형식이 될 수 있습니다.


...
subject: [Contact us query] Page not working
...


하지만 헤더의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 subject에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..."과 같은 악성 문자열을 전송하는 경우 SMTP 헤더의 형식은 다음 중 하나가 됩니다.


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


이 경우 공격자는 스팸 메시지를 만들거나 익명 전자 메일을 전송할 수 있게 됩니다.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[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 Mobile 2014 M1 Weak Server Side Controls
[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 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 - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.java.header_manipulation_smtp
Abstract
SMTP 헤더에 확인되지 않은 데이터를 포함하면 해커는 메일 콘텐트를 자신에게 누출하거나 메일 서버를 스팸 봇으로 이용하는 데 사용할 수 있는 CC 또는 BCC와 같은 임의의 헤더를 추가할 수 있습니다.
Explanation
SMTP Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

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

2. 데이터가 확인을 거치지 않고 메일 서버에 전송된 SMTP 헤더에 포함됩니다.

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

가장 일반적인 SMTP Header Manipulation 공격 중 하나는 스팸 전자 메일 유포의 사용입니다. 전자 메일의 제목과 본문을 설정하도록 허용하는 취약한 "문의처" 양식이 응용 프로그램에 있는 경우, 전자 메일이 공격을 당한 서버로부터 전송되기 때문에 공격자는 임의의 콘텐트를 설정하고 익명으로 스팸을 발송할 전자 메일 주소 목록이 포함된 CC 헤더를 삽입할 수 있습니다.

예제: 다음 코드 세그먼트는 "문의처" 양식의 제목 및 본문을 읽습니다.


$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);


"Page not working"과 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 SMTP 헤더는 다음과 같은 형식이 될 수 있습니다.


...
subject: [Contact us query] Page not working
...


하지만 헤더의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 subject에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..."과 같은 악성 문자열을 전송하는 경우 SMTP 헤더의 형식은 다음 중 하나가 됩니다.


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


이 경우 공격자는 스팸 메시지를 만들거나 익명 전자 메일을 전송할 수 있게 됩니다.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[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 Mobile 2014 M1 Weak Server Side Controls
[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 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 - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.php.header_manipulation_smtp
Abstract
SMTP 헤더에 확인되지 않은 데이터를 포함하면 해커는 메일 콘텐트를 자신에게 누출하거나 메일 서버를 스팸 봇으로 이용하는 데 사용할 수 있는 CC 또는 BCC와 같은 임의의 헤더를 추가할 수 있습니다.
Explanation
SMTP Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

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

2. 데이터가 확인을 거치지 않고 메일 서버에 전송된 SMTP 헤더에 포함됩니다.

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

가장 일반적인 SMTP Header Manipulation 공격 중 하나는 스팸 전자 메일 유포의 사용입니다. 전자 메일의 제목과 본문을 설정하도록 허용하는 취약한 "문의처" 양식이 응용 프로그램에 있는 경우, 전자 메일이 공격을 당한 서버로부터 전송되기 때문에 공격자는 임의의 콘텐트를 설정하고 익명으로 스팸을 발송할 전자 메일 주소 목록이 포함된 CC 헤더를 삽입할 수 있습니다.

예제: 다음 코드 세그먼트는 "문의처" 양식의 제목 및 본문을 읽습니다.


body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
"subject: [Contact us query] " + subject,
"to: support@acme.com",
"mime-version: 1.0",
"content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)


"Page not working"과 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 SMTP 헤더는 다음과 같은 형식이 될 수 있습니다.


...
subject: [Contact us query] Page not working
...


하지만 헤더의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 subject에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..."과 같은 악성 문자열을 전송하는 경우 SMTP 헤더의 형식은 다음 중 하나가 됩니다.


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


이 경우 공격자는 스팸 메시지를 만들거나 익명 전자 메일을 전송할 수 있게 됩니다.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[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 Mobile 2014 M1 Weak Server Side Controls
[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 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 - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
이 함수는 해당 매개 변수와 null을 비교해야 하는 약정을 위반합니다.
Explanation
Java 표준에 따르면 해당 매개 변수가 null인 경우 Object.equals(), Comparable.compareTo()Comparator.compare()의 구현은 지정된 값을 반환해야 합니다. 이 약정을 따르지 않으면 예기치 못한 동작이 발생할 수 있습니다.

예제 1: 다음 equals() 메서드의 구현은 해당 매개 변수와 null을 비교하지 않습니다.


public boolean equals(Object object)
{
return (toString().equals(object.toString()));
}
References
[1] MET10-J. Follow the general contract when implementing the compareTo() method CERT
[2] MET08-J. Preserve the equality contract when overriding the equals() method CERT
[3] Standards Mapping - Common Weakness Enumeration CWE ID 398
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
desc.controlflow.java.missing_check_for_null_parameter
Abstract
사용자 입력을 포함하고 있는 SimpleDB 선택 문을 생성하면 공격자가 허가 받지 않은 레코드를 볼 수 있습니다.
Explanation
Query string injection 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.



2. 데이터를 사용하여 SimpleDB 쿼리 문자열을 동적으로 생성합니다.

예제 1: 다음 코드는 사용자가 지정한 제품 카테고리와 일치하는 송장을 검색하는 SimpleDB select() 쿼리를 동적으로 생성하고 실행합니다. 또한 사용자는 결과가 정렬되는 열을 지정할 수도 있습니다. 응용 프로그램이 이미 적절하게 인증되고 이 코드 세그먼트 전에 customerID의 값을 설정했다고 가정합니다.


...
String customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
...
AmazonSimpleDBClient sdbc = new AmazonSimpleDBClient(appAWSCredentials);
String query = "select * from invoices where productCategory = '"
+ productCategory + "' and customerID = '"
+ customerID + "' order by '"
+ sortColumn + "' asc";
SelectResult sdbResult = sdbc.select(new SelectRequest(query));
...


이 코드가 실행하려는 쿼리는 다음과 같습니다.


select * from invoices
where productCategory = 'Fax Machines'
and customerID = '12345678'
order by 'price' asc


하지만 상수인 기본 쿼리 문자열과 사용자 입력 문자열을 연결하여 쿼리를 동적으로 생성하기 때문에, 쿼리는 productCategoryprice에 작은따옴표 문자가 들어 있지 않은 경우에만 정확하게 동작합니다. 그러나, 공격자가 productCategory에 대한 "Fax Machines' or productCategory = \"" 문자열 및 sortColumn에 대한 "\" order by 'price" 문자열을 제공하면, 쿼리는 다음과 같습니다.


select * from invoices
where productCategory = 'Fax Machines' or productCategory = "'
and customerID = '12345678'
order by '" order by 'price' asc


또는, 다음과 같이 보다 읽기 쉬운 형식을 사용합니다.


select * from invoices
where productCategory = 'Fax Machines'
or productCategory = "' and customerID = '12345678' order by '"
order by 'price' asc


이러한 입력을 통해 공격자는 customerID에 필요한 authentication을 무시할 수 있으며, 모든 고객에 대한 'Fax Machines'와 일치하는 송장 레코드를 볼 수 있습니다.
References
[1] Secure Use of Cloud Storage
[2] Standards Mapping - Common Weakness Enumeration CWE ID 89
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] 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
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.dataflow.java.query_string_injection_amazon_web_services
Abstract
사용자 입력을 포함하고 있는 SQLite 쿼리 문을 생성하면 공격자가 허가 받지 않은 레코드를 볼 수 있습니다.
Explanation
Query string injection 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.



이런 경우, Fortify Static Code Analyzer는 데이터 소스를 신뢰할 수 있는 것으로 판단하지 않습니다.

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

SQLite query string injection으로 인해 악의적인 사용자가 무단으로 레코드를 볼 수 있으나, 어떤 방식으로도 데이터베이스의 상태를 변경할 수는 없습니다.

예제 1: 다음 코드는 고객 및 사용자가 지정한 제품 카테고리와 관련된 송장을 검색하는 SQLite 쿼리를 동적으로 생성하고 실행합니다. 또한 사용자는 결과가 정렬되는 열을 지정할 수도 있습니다. 프로그램이 이미 적절하게 인증되고 이 코드 세그먼트 전에 customerID의 값을 설정했다고 가정합니다.


...
productCategory = this.getIntent().getExtras().getString("productCategory");
sortColumn = this.getIntent().getExtras().getString("sortColumn");
customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
c = invoicesDB.query(Uri.parse(invoices), columns, "productCategory = '" + productCategory + "' and customerID = '" + customerID + "'", null, null, null, "'" + sortColumn + "'asc", null);
...


이 코드가 실행하려는 쿼리는 다음과 같습니다.


select * from invoices
where productCategory = 'Fax Machines'
and customerID = '12345678'
order by 'price' asc


그러나, 쿼리는 상수 기반 쿼리 문자열 및 사용자 입력 문자열 productCategory를 연결하여 동적으로 생성됩니다. 그러므로 쿼리는 productCategorysortColumn가 작은 따옴표 문자를 포함하지 않은 경우에만 올바르게 작동합니다. 공격자가 productCategory에 대한 "Fax Machines' or productCategory = \"" 문자열 및 sortColumn에 대한 "\" order by 'price" 문자열을 제공하면, 쿼리는 다음과 같습니다.


select * from invoices
where productCategory = 'Fax Machines' or productCategory = "'
and customerID = '12345678'
order by '" order by 'price' asc


또는 다음과 같이 보다 읽기 쉬운 형식을 사용합니다.


select * from invoices
where productCategory = 'Fax Machines'
or productCategory = "' and customerID = '12345678' order by '"
order by 'price' asc


이러한 입력을 통해 공격자는 customerID에 필요한 authentication을 무시할 수 있으며, 모든 고객에 대한 'Fax Machines'와 일치하는 송장 레코드를 볼 수 있습니다.
References
[1] Android Developers-Reference: SQLite Database
[2] SQL as Understood by SQLite
[3] Standards Mapping - Common Weakness Enumeration CWE ID 89
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, 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.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection 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 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[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 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.semantic.java.query_string_injection_android_provider
Abstract
프로그램이 모호한 방식으로 변수에 액세스하므로 공격에 노출될 수 있습니다.
Explanation
HttpRequest 클래스는 배열 액세스의 형태로 QueryString, Form, Cookies 또는 ServerVariables 컬렉션의 변수에 대한 프로그래밍 방식의 액세스를 제공합니다(예: Request["myParam"]). 동일한 이름을 가진 변수가 두 개 이상 존재할 경우, .NET Framework는 다음 순서로 컬렉션을 검색할 때 먼저 나타나는 변수의 값을 반환합니다. 즉, QueryString, Form, Cookies, ServerVariables의 순서로 반환합니다. 검색 순서에서 QueryString이 먼저 오므로 QueryString 매개 변수가 폼, 쿠키 및 서버 변수의 값을 대체할 수 있습니다. 마찬가지로 폼 값은 CookiesServerVariables 컬렉션의 변수를 대체할 수 있고 Cookies 컬렉션의 변수는 ServerVariables의 변수를 대체할 수 있습니다.
예제 1: 뱅킹 응용 프로그램이 일시적으로 사용자의 전자 메일 주소를 쿠키에 저장하고 사용자에게 연락하고자 할 때 이 값을 읽는다고 가정합니다. 다음 코드는 쿠키 값을 읽고 지정된 전자 메일 주소로 잔고를 전송합니다.

...
String toAddress = Request["email"]; //Expects cookie value
Double balance = GetBalance(userID);
SendAccountBalance(toAddress, balance);
...
http://www.example.com/GetBalance.aspx 방문 시 Example 1의 코드가 실행된다고 가정합니다. 공격자가 인증된 사용자로 하여금 http://www.example.com/GetBalance.aspx?email=evil%40evil.com을 요청하는 링크를 클릭하도록 할 수 있는 경우, 사용자의 잔고 정보가 있는 전자 메일이 evil@evil.com으로 전송됩니다.
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[2] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[3] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[9] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[10] 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
[11] 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
[12] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
desc.semantic.dotnet.value_shadowing
Abstract
프로그램이 모호한 방식으로 서버 변수에 액세스하므로 공격에 노출될 수 있습니다.
Explanation
HttpRequest 클래스는 배열 액세스의 형태로 QueryString, Form, Cookies 또는 ServerVariables 컬렉션의 변수에 대한 프로그래밍 방식의 액세스를 제공합니다(예: Request["myParam"]). 동일한 이름을 가진 변수가 두 개 이상 존재할 경우, .NET Framework는 다음 순서로 컬렉션을 검색할 때 먼저 나타나는 변수의 값을 반환합니다. 즉, QueryString, Form, Cookies, ServerVariables의 순서로 반환합니다. 검색 순서에서 QueryString이 먼저 오므로 QueryString 매개 변수가 폼, 쿠키 및 서버 변수의 값을 대체할 수 있습니다. 마찬가지로 폼 값은 CookiesServerVariables 컬렉션의 변수를 대체할 수 있고 Cookies 컬렉션의 변수는 ServerVariables의 변수를 대체할 수 있습니다.
예제 1: 다음 코드는 콘텐트를 제공하기 전에 HTTP 리퍼러 헤더 서버 변수를 검사하여 해당 요청이 www.example.com으로부터 왔는지 확인합니다.

...
if (Request["HTTP_REFERER"].StartsWith("http://www.example.com"))
ServeContent();
else
Response.Redirect("http://www.example.com/");
...
http://www.example.com/ProtectedImages.aspx 방문 시 Example 1의 코드가 실행된다고 가정합니다. 공격자가 URL에 대해 직접 요청하는 경우, 적절한 리퍼러 헤더가 전송되지 않으며 요청이 실패합니다. 그러나 공격자가 http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com과 같은 필요한 값을 가진 거짓 HTTP_REFERER 매개변수를 전송하는 경우, 조회하면 ServerVariables 대신 QueryString에서 값이 반환되며 검사가 성공합니다.
References
[1] Microsoft IIS Server Variables
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[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 - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[10] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[11] 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
[12] 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
[13] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
desc.semantic.dotnet.value_shadowing_server_variable