계: Input Validation and Representation

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

175 개 항목 찾음
취약점
Abstract
사용자가 제공하는 데이터를 apex:iframe 소스 URL로 수락하면 Visualforce 페이지 내에서 악성 콘텐트가 로드될 수 있습니다.
Explanation
Frame Spoofing 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다.

2. 데이터는 확인 작업을 거치지 않고 iframe URL로 사용됩니다.

이러한 방식으로 공격자는 인라인 프레임으로 렌더링되는 항목을 제어할 수 있습니다. 악성 사이트를 가리키도록 프레임 URL을 수정하면, 자격 증명 또는 다른 민감한 데이터를 포함하는 사용자 정보를 도용하기 위해 피싱 공격이 수행될 수 있습니다. 기본 도메인을 신뢰할 수 있는 경우 - Salesforce.com, 피해자는 해당 페이지를 신뢰하고 요청된 모든 정보를 제공합니다.

예제 1: 다음 코드 예제에서, iframesrc URL 매개 변수는 apex:iframe 대상 URL로 직접 사용됩니다.

<apex:page>
<apex:iframe src="{!$CurrentPage.parameters.iframesrc}"></apex:iframe>
</apex:page>


이러한 방식으로 공격자가 피해자에게 악성 웹 사이트로 설정된 iframesrc 매개 변수를 제공하는 경우, 프레임은 악성 웹 사이트의 콘텐트로 렌더링됩니다.

<iframe src="http://evildomain.com/">
References
[1] Ryan C. Barnett Content Spoofing - TechTarget
[2] Salesforce Developers Technical Library Secure Coding Guidelines
desc.dataflow.apex.frame_spoofing
Abstract
신뢰할 수 없는 소스에서 Google Remote Procedure Call(gRPC) Metadata 개체가 생성됩니다. 그러므로 공격자가 중요한 프로토콜 필드를 제어하게 될 수도 있습니다.
Explanation
Metadata 클래스는 Google Remote Procedure Call(gRPC)에서 사용하는 기본 프로토콜의 헤더 데이터를 저장하는 데 사용되는 경우가 많습니다. 기본 프로토콜이 HTTP일 때는 Metadata 개체의 데이터를 제어하면 시스템이 HTTP 헤더 조작에 취약해질 수 있습니다. 공격자가 다른 공격 벡터(대개 기본 프로토콜 기반)를 이용할 수 있기 때문입니다.

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


...
String badData = getUserInput();
Metadata headers = new Metadata();
headers.put(Metadata.Key.of("sample", Metadata.ASCII_STRING_MARSHALLER), badData);
...
desc.dataflow.java.grpc_metadata_manipulation
Abstract
프로그램을 통해 공격자는 클라이언트 응용 프로그램이 실행되는 Hadoop 클러스터의 핵심 구성 요소를 제어할 수 있습니다.
Explanation
Hadoop 클러스터 제어 오류는 다음 경우에 발생합니다.

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

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

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

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


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

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

/* This sets the ownership of a file pointed by the path to a user identified
* by command line arguments.
*/
nNode.setOwner(path, args[2], args[3]);
...
}
desc.dataflow.java.hadoop_cluster_manipulation
Abstract
Hadoop 클러스터에 전송되는 Job은 위험한 환경에서 조작될 수 있습니다.
Explanation
Hadoop 작업 조작 오류는 다음과 같은 경우에 발생합니다.

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

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

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

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


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

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

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

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

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


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

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

}
desc.dataflow.java.hadoop_job_manipulation
Abstract
Handlebars 템플릿에서 이스케이프가 처리가 비활성화되어 여러 가지 새로운 취약점이 발생할 수 있습니다.
Explanation
Handlebars 템플릿에서 수행되는 기본 이스케이프 처리는 공격자로부터 응용 프로그램을 보호하는 데 도움이 됩니다. 이렇게 하면 다양한 유형의 취약성에서 많은 공격 벡터를 방지할 수 있습니다. 가장 두드러진 기능은 특정 유형의 Cross-Site Scripting 공격으로부터 보호하는 것입니다. 이 응용 프로그램에서는 이 보호 메커니즘이 비활성화되어 있습니다.

예제 1: 다음 예제는 이스케이프 처리가 비활성화되어 있는 Handlebars 템플릿을 보여줍니다.

let template = Handlebars.compile('{{foo}}', { noEscape: true })
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark complete
[6] Standards Mapping - Common Weakness Enumeration CWE ID 554
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[13] Standards Mapping - FIPS200 CM
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[24] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.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 3.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.handlebars_misconfiguration_escaping_disabled
Abstract
Handlebars 템플릿에서 프로토타입이 허용되어 프로토타입 오염 공격에 노출됩니다.
Explanation
Handlebars 템플릿은 응용 프로그램을 Prototype Pollution 공격에 취약하게 만들기 때문에 개체의 프로토타입에 액세스할 수 없습니다.

프로토타입 오염 공격은 악의적인 사용자가 개체 프로토타입의 함수나 속성을 제어할 수 있을 때 발생합니다. 템플릿으로 전달되는 개체의 프로토타입을 제어하면 Dynamic Code Evaluation, Cross-Site Scripting, 원격 코드 실행을 비롯한 많은 취약점에 노출되게 됩니다.

예제 1: Handlebars 템플릿을 구성하는 다음 예제에서는 기본적으로 프로토타입 메서드와 특수 __defineGetter__ 함수가 허용됩니다.

let template2 = Handlebars.compile('{{foo}}')
console.log(template2({ foo: argument }, {
allowProtoMethodsByDefault: true,
allowedProtoMethods: {
__defineGetter__: true
}
}))
References
[1] Handlebars Runtime Options: Options to Control Prototype Access Handlebars
[2] Mahmoud Gamal Handlebars template injection and RCE in a Shopify app
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 554
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[15] Standards Mapping - FIPS200 CM
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[26] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[37] 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
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 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 4.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.javascript.handlebars_misconfiguration_prototypes_allowed
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
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
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
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
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
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' 헤더의 값은 유효성이 검사되지 않은 사용자 입력을 사용하여 생성되므로 악의적 작업자가 해당 값을 조작하여 취약성 악용, 코드 주입 공격 실행, 중요한 데이터 노출 등의 악의적인 행위를 할 수도 있고 악성 파일을 실행할 수 있도록 설정하거나 서비스 거부 상황을 유발할 수도 있습니다. 그러면 응용 프로그램의 보안과 안정성이 크게 저하되어 매우 위험해집니다.
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
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
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
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
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
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
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
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을 제어하도록 허용하면 피싱 공격에 취약해질 수 있습니다.
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
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
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
desc.dataflow.vb.header_manipulation