222 개 항목 찾음
취약점
Abstract
사용자 입력이 파일 권한을 직접 변경하는 것을 허용하면 공격자가 보호된 시스템 리소스에 접근할 수 있습니다.
Explanation
File permission manipulation 오류는 다음 조건 중 하나를 만족할 때 발생합니다.

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

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

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


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

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

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

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


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

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

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

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


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


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

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


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

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

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

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


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

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

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

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


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


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

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


...
mask = config_params['perms']
File.chmod(filename, mask)
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[18] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 5.4 - Authentication and Access Control
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.file_permission_manipulation
Abstract
프로그램은 지나치게 허용적인 도메인 간 정책을 정의합니다.
Explanation
기본적으로, 동일한 도메인에서 나오는 경우에만 두 개의 SWF 응용 프로그램이 서로의 데이터에 접근할 수 있는지 확인하는 동일 출처 정책(Same Origin Policy)이 Flash 응용 프로그램에 적용됩니다. Adobe Flash를 사용하면 개발자는 프로그래밍 방식으로 또는 crossdomain.xml 구성 파일의 적절한 설정을 통해 정책을 수정할 수 있습니다. 그러나, 지나치게 허용적인 도메인 간 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 설정 변경 시 주의해야 합니다.

예제 1: 발췌한 다음 내용은 응용 프로그램과 통신이 허용되는 도메인을 프로그래밍 방식으로 지정하는 와일드카드 사용 예입니다.


flash.system.Security.allowDomain("*");
*allowDomain()에 대한 인수로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 다른 SWF 응용 프로그램으로 접근할 수 있음을 나타냅니다.
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 942
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_overly_permissive_cross_domain_policy
Abstract
이 프로그램은 지나치게 허용적인 사용자 지정 헤더 정책을 정의합니다.
Explanation
기본적으로, 동일한 도메인에서 나오는 경우에만 두 개의 SWF 응용 프로그램이 서로의 데이터에 접근할 수 있는지 확인하는 동일 출처 정책(Same Origin Policy)이 Flash 응용 프로그램에 적용됩니다. Adobe Flash를 사용하면 개발자는 프로그래밍 방식으로 또는 crossdomain.xml 구성 파일의 적절한 설정을 통해 정책을 수정할 수 있습니다. Flash Player 9,0,124,0부터 Adobe는 Flash Player에서 여러 도메인에 걸쳐 보낼 수 있는 사용자 지정 헤더를 정의하는 기능도 도입했습니다. 그러나 지나치게 허용적인 도메인 간 정책과 함께 적용할 경우, 지나치게 허용적인 사용자 지정 헤더 정책은 선택된 헤더를 악성 응용 프로그램이 대상 응용 프로그램으로 전송할 수 있어, 수신한 헤더를 처리하지 못하는 응용 프로그램 실행 시 다양한 공격으로 이어지거나 오류가 발생할 수 있기 때문에 이러한 설정 정의 시 주의해야 합니다.

예제 1: 다음 구성은 Flash Player가 도메인 간에 전송할 수 있는 헤더를 지정하는 와일드카드 사용을 보여줍니다.


<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
*headers 속성 값으로 사용하면 모든 헤더가 여러 도메인에 걸쳐 전송됨을 나타냅니다.
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.actionscript.flash_misconfiguration_overly_permissive_custom_headers_policy
Abstract
프로그램에서 확인되지 않은 사용자 입력을 사용하여 의도한 도메인 간 정책 제한을 무시합니다.
Explanation
기본적으로, 동일한 도메인에서 나오는 경우에만 두 개의 SWF 응용 프로그램이 서로의 데이터에 접근할 수 있는지 확인하는 동일 출처 정책(Same Origin Policy)이 Flash 응용 프로그램에 적용됩니다. Adobe Flash를 사용하면 개발자는 프로그래밍 방식으로 또는 crossdomain.xml 구성 파일의 적절한 설정을 통해 정책을 수정할 수 있습니다. 그러나, 지나치게 허용적인 도메인 간 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 설정에 영향을 미칠 수 있는 사람을 결정할 때 주의해야 합니다. 정책 제한 무시 취약점은 다음과 같은 경우 발생합니다.

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

2. 데이터는 도메인 간 정책 설정을 로드하거나 수정하는 데 사용됩니다.
예제 1: 다음 코드는 로드한 SWF 파일에 대한 매개 변수 중 하나의 값을 URL로 사용하여 그로부터 도메인 간 정책 파일을 로드합니다.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var url:String = String(params["url"]);
flash.system.Security.loadPolicyFile(url);
...
예제 2: 다음 코드는 로드한 SWF 파일에 대한 매개변수 중 하나의 값을 사용하여 신뢰할 수 있는 도메인 목록을 정의합니다.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var domain:String = String(params["domain"]);
flash.system.Security.allowDomain(domain);
...
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[24] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.actionscript.flash_misconfiguration_policy_restrictions_bypass
Abstract
프로그램은 HTTP와 HTTPS SWF 응용 프로그램이 통신하도록 허용합니다.
Explanation
Flash Player 7로 시작하면 HTTP를 통해 로드된 SWF 응용 프로그램은 기본적으로 HTTPS를 통해 로드된 SWF 응용 프로그램의 데이터에 접근할 수 없습니다. Adobe Flash를 사용하면 개발자는 프로그래밍 방식으로 또는 crossdomain.xml 구성 파일의 적절한 설정을 통해 이 제한을 수정할 수 있습니다. 그러나 HTTP로 로드한 SWF 응용 프로그램은 MITM(Man-In-The-Middle) 공격을 받을 수 있으므로 이러한 설정 정의 시 주의해야 하며, 따라서 신뢰하지 말아야 합니다.

예제: 다음 코드는 allowInsecureDomain()을 호출하여 HTTP로 로드된 SWF 응용 프로그램이 HTTPS로 로드된 SWF 응용 프로그램의 데이터에 접근하는 것을 막는 제한을 끕니다.


flash.system.Security.allowInsecureDomain("*");
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.4, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.4, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.4, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.4, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.4.1 - Web Software Communications
[25] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 862
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_unauthorized_data_access
Abstract
프로그램을 통해 공격자는 클라이언트 응용 프로그램이 실행되는 Hadoop 클러스터의 핵심 구성 요소를 제어할 수 있습니다.
Explanation
Hadoop 클러스터 제어 오류는 다음 경우에 발생합니다.

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

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

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

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


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

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

/* This sets the ownership of a file pointed by the path to a user identified
* by command line arguments.
*/
nNode.setOwner(path, args[2], args[3]);
...
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] 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
[21] 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
[22] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.hadoop_cluster_manipulation
Abstract
다른 도메인의 스크립트를 포함시키는 것은 이 웹 페이지의 보안이 다른 도메인의 보안에 따라 달라지게 된다는 것을 의미합니다.
Explanation
다른 웹 사이트의 실행 가능 콘텐트를 포함시키는 것은 위험한 발상입니다. 이는 다른 사이트와 사용자의 사이트 보안을 함께 묶는 행위입니다.

예제: 다음 script 태그를 보겠습니다.

<script src="http://www.example.com/js/fancyWidget.js"></script>


이 태그가 www.example.com이 아닌 다른 웹 사이트에 나타나는 경우, 이 사이트의 정확한 비 악성 코드 사용 여부는 www.example.com에 따라 달라지게 됩니다. 공격자가 www.example.com을 손상시킨 경우, fancyWidget.js의 내용을 변경하여 사이트 보안을 침해할 수 있습니다. 예를 들어 fancyWidget.js에 코드를 추가하여 사용자의 기밀 데이터를 훔칠 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 494, CWE ID 829
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.3 Dependency (L1 L2 L3), 14.2.4 Dependency (L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[13] Standards Mapping - OWASP Mobile 2024 M7 Insufficient Binary Protections
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2
[15] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[16] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[30] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
[31] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Process Validation
desc.content.html.hardcoded_domain
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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 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 Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 113
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[56] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 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 Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 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 Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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 - CIS Azure Kubernetes Service Benchmark 2.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 93
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Top 10 2004 A1 Unvalidated Input
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] 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 - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry 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 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 - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry 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 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 - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry 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 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
민감한 정보를 저장하는 버퍼의 크기를 조절할 때는 realloc()를 사용하지 마십시오. 이 함수를 사용하면 민감한 정보의 사본이 덮어쓰기가 안 되는 메모리에 남겨질 수 있습니다.
Explanation
Heap inspection 취약점은 암호나 암호화 키 같은 민감한 데이터가 메모리에서 삭제되지 않기 때문에 공격자에게 노출될 때 발생합니다.

realloc() 함수는 일반적으로 할당된 메모리 블록의 크기를 증가시킬 때 사용합니다. 이 작업을 수행할 때 이전 메모리 블록의 내용을 더 큰 새 블록에 복사해야 합니다. 이 작업은 원래 블록의 내용을 그대로 유지하지만 프로그램이 접근할 수 없게 하여 프로그램이 메모리의 민감한 데이터를 초기화하는 것을 방지합니다. 이후에 공격자가 메모리 덤프의 내용을 검사하게 되면 민감한 데이터가 노출될 수 있습니다.

예제: 다음 코드는 민감한 데이터가 들어 있는 버퍼에 대해 realloc()을 호출합니다.


plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);


메모리에서 민감한 데이터를 초기화하려고 하지만 realloc()를 사용하기 때문에 처음에 plaintext_buffer에 할당된 메모리에서 데이터의 복사본이 노출될 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 244
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090, CCI-001199
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1), SC-28 Protection of Information at Rest (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources, SC-28 Protection of Information at Rest
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 8.3.6 Sensitive Private Data (L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[23] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.4, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.5 - Sensitive Data Retention
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.5 - Sensitive Data Retention
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.5 - Sensitive Data Retention
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3230.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3230.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3230.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3230.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3230.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3230.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3230.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.cpp.heap_inspection
Abstract
민감한 데이터가 있는 페이지를 고정시키기 위해 VirtualLock을 사용하지 마십시오. 함수가 항상 구현되는 것은 아닙니다.
Explanation
Heap inspection 취약점은 암호나 암호화 키 같은 민감한 데이터가 메모리에서 삭제되지 않기 때문에 공격자에게 노출될 때 발생합니다.

VirtualLock 함수는 메모리의 페이지가 디스크에 페이지되는 것을 방지하기 위한 것입니다. 하지만, Windows 95/98/ME에서 이 함수는 스텁(stub)으로 구현되며 아무런 영향을 끼치지 않습니다.

References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 591
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090, CCI-001199
[8] Standards Mapping - FIPS200 MP
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1), SC-28 Protection of Information at Rest (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources, SC-28 Protection of Information at Rest
[12] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[13] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[18] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[19] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.4, Requirement 6.5.8, Requirement 8.4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3230.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3230.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3230.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3230.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3230.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3230.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3230.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.cpp.heap_inspection_swappable_memory
Abstract
프로그램에서 숨겨진 폼 필드를 생성합니다.
Explanation
프로그래머는 흔히 사용자가 내용을 보거나 조작할 수 없을 것으로 기대하며 숨겨진 필드의 내용을 신뢰합니다. 공격자는 이러한 가정을 위반합니다. 공격자는 숨겨진 필드에 기록된 값을 관찰하고 수정하거나 공격 데이터로 내용을 교체합니다.

예제:

HtmlInputHidden hidden = new HtmlInputHidden();


숨겨진 필드에 민감한 정보가 있는 경우, 이 정보는 페이지의 나머지 부분 캐시 방법과 동일한 방법으로 캐시됩니다. 그러면 사용자에게 알리지 않고 민감한 정보가 브라우저 캐시에서 숨겨질 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 472
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[10] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[13] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[14] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[35] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[36] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.hidden_field
Abstract
프로그램에서 숨겨진 폼 필드를 생성합니다.
Explanation
프로그래머는 흔히 사용자가 내용을 보거나 조작할 수 없을 것으로 기대하며 숨겨진 필드의 내용을 신뢰합니다. 공격자는 이러한 가정을 위반합니다. 공격자는 숨겨진 필드에 기록된 값을 관찰하고 수정하거나 공격 데이터로 내용을 교체합니다.

예제:

Hidden hidden = new Hidden(element);


숨겨진 필드에 민감한 정보가 있는 경우, 이 정보는 페이지의 나머지 부분 캐시 방법과 동일한 방법으로 캐시됩니다. 그러면 사용자에게 알리지 않고 민감한 정보가 브라우저 캐시에서 숨겨질 수 있습니다.
References
[1] IDS14-J. Do not trust the contents of hidden form fields CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 472
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[11] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[12] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[14] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[15] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[36] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[37] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.hidden_field
Abstract
숨겨진 폼 필드가 사용됩니다.
Explanation
프로그래머는 흔히 사용자가 내용을 보거나 조작할 수 없을 것으로 기대하며 숨겨진 필드의 내용을 신뢰합니다. 공격자는 이러한 가정을 위반합니다. 공격자는 숨겨진 필드에 기록된 값을 관찰하고 수정하거나 공격 데이터로 내용을 교체합니다.

예제:hidden 형식의 <input> 태그는 숨겨진 필드를 사용하고 있음을 나타냅니다.

<input type="hidden">


숨겨진 필드에 민감한 정보가 있는 경우, 이 정보는 페이지의 나머지 부분 캐시 방법과 동일한 방법으로 캐시됩니다. 그러면 사용자에게 알리지 않고 민감한 정보가 브라우저 캐시에서 숨겨질 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 472
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[10] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[13] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[14] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[35] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[36] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.content.html.hidden_field
Abstract
X-XSS-Protection 헤더가 명시적으로 비활성화되어 있어 Cross-Site Scripting 공격의 위험이 증가할 수 있습니다.
Explanation
X-XSS-Protection 헤더는 최신 브라우저에서 기본적으로 활성화됩니다. 이 헤더 값을 false(0)로 설정하면 Cross-Site Scripting 보호가 비활성화됩니다.

이 헤더는 여러 위치에서 설정할 수 있으며 구성 오류 및 악의적인 조작이 있지 않은지 확인되어야 합니다.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] HttpResponse.AppendHeader Method
[4] How to prevent cross-site scripting security issues
[5] HOW TO: Disable the Documentation Protocol for ASP.NET Web Services
[6] Configuring Services Using Configuration Files
[7] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[11] Standards Mapping - CIS Kubernetes Benchmark complete
[12] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[19] Standards Mapping - FIPS200 CM
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[23] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[24] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[25] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[26] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[27] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[28] 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)
[29] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[30] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[40] 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
[41] 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
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.dotnet.html5_xss_protection
Abstract
X-XSS-Protection 헤더가 명시적으로 비활성화되어 있어 Cross-Site Scripting 공격의 위험이 증가할 수 있습니다.
Explanation
X-XSS-Protection 헤더는 최신 브라우저에서 기본적으로 활성화됩니다. 이 헤더 값을 false(0)로 설정하면 Cross-Site Scripting 보호가 비활성화됩니다.

이 헤더는 여러 위치에서 설정할 수 있으며 구성 오류 및 악의적인 조작이 있지 않은지 확인되어야 합니다.

예제: 다음 코드는 XSS 보호를 사용하지 않도록 Spring Security로 보호된 응용 프로그램을 구성합니다.

<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[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, CWE ID 1173
[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.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[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 Application Misconfiguration (WASC-15)
desc.config.java.html5_cross_site_scripting_protection
Abstract
X-XSS-Protection 헤더가 명시적으로 비활성화되어 있어 cross-site scripting 공격의 위험이 증가할 수 있습니다.
Explanation
X-XSS-Protection 헤더는 최신 브라우저에서 기본적으로 활성화됩니다. 이 헤더 값을 false(0)로 설정하면 Cross-Site Scripting 보호가 비활성화됩니다.
이 헤더는 여러 위치에서 설정할 수 있으며 구성 오류 및 악의적인 조작이 있지 않은지 확인되어야 합니다.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] Node.js Security Checklist
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[16] Standards Mapping - FIPS200 CM
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[20] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[21] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[25] 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)
[26] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[27] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] 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
[38] 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
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 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 4.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.javascript.html5_cross_site_scripting_protection
Abstract
X-XSS-Protection 헤더가 명시적으로 비활성화되어 있어 cross-site scripting 공격의 위험이 증가할 수 있습니다.
Explanation
X-XSS-Protection 헤더는 최신 브라우저에서 기본적으로 활성화됩니다. 이 헤더 값을 false(0)로 설정하면 Cross-Site Scripting 보호가 비활성화됩니다.

이 헤더는 여러 위치에서 설정할 수 있으며 구성 오류 및 악의적인 조작이 있지 않은지 확인되어야 합니다.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] django-secure
[4] SECURE_BROWSER_XSS_FILTER
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[11] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[15] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[16] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[17] Standards Mapping - FIPS200 CM
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[20] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[21] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[22] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[25] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[26] 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)
[27] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[28] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] 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
[39] 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
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_cross_site_scripting_protection
Abstract
Web SQL 데이터베이스 이름을 추측하기 쉬우면 승인되지 않은 사용자가 데이터 도난 및 데이터베이스 손상을 초래할 수 있습니다.
Explanation
HTML5 기능 중 하나는 클라이언트 쪽 SQL 데이터베이스에 데이터를 저장하는 기능입니다. 데이터베이스에 작성하고 데이터베이스에서 읽기 시작하는 데 필요한 주요 정보는 해당 이름입니다. 따라서 데이터베이스의 이름이 사용자마다 다른, 고유한 문자열이어야 합니다. 데이터베이스의 이름을 추측하기 쉬운 경우, 다른 사용자와 마찬가지로 승인되지 않은 사용자가 민감한 데이터를 훔치거나 데이터베이스 항목을 손상시킬 수 있습니다.
예제: 다음 코드는 추측하기 쉬운 데이터베이스 이름을 사용합니다.


...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...


이 코드는 성공적으로 실행되지만 데이터베이스 이름을 'mydb'로 추측할 수 있는 사람은 누구나 데이터베이스에 액세스할 수 있습니다.
References
[1] HTML5 Security Cheatsheet
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 330
[8] Standards Mapping - FIPS200 MP
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[12] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[13] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[19] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7 - Use of Cryptography
[32] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[40] Standards Mapping - Web Application Security Consortium Version 2.00 Predictable Resource Location (WASC-34)
[41] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.javascript.html5_easy_to_guess_database_name
Abstract
입력 폼 필드의 HTML5 검증이 비활성화됩니다.
Explanation
HTML5는 단순한 입력 폼 검증을 수행할 수 있는 새로운 기능을 제공합니다. required 속성을 사용하여 입력 폼 필드가 필요한지 지정할 수 있습니다. 필드 유형을 지정하면 해당 유형에 대하여 입력이 확실히 검사됩니다. 정규식에 대하여 입력을 검사하는 사용자 지정 가능 pattern 속성까지 제공할 수 있습니다. 그러나 이 검증은 폼 태그의 novalidate 속성과 제출 입력 태그의 formnovalidate 속성 추가 시 비활성화됩니다.

예제 1: 다음 샘플은 novalidate 속성을 통해 폼 검증을 비활성화합니다.


<form action="demo_form.asp" novalidate="novalidate">
E-mail: <input type="email" name="user_email" />
<input type="submit" />
</form>
예제 2: 다음 샘플은 formnovalidate 속성을 통해 폼 검증을 비활성화합니다.


<form action="demo_form.asp" >
E-mail: <input type="email" name="user_email" />
<input type="submit" formnovalidate="formnovalidate"/>
</form>


검증이 비활성화된 HTML 폼은 사용자 친화적이지 않고 서버가 수많은 종류의 공격에 노출될 수 있습니다. 검증되지 않은 입력은 cross-site scripting, process control 및 SQL injection과 같은 취약점의 원인이 됩니다.
References
[1] HTML5 form novalidate Attribute W3Schools
[2] HTML5 input formnovalidate Attribute W3Schools
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 1173
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[16] Standards Mapping - FIPS200 SI
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[20] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[21] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[25] 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)
[26] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.6
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] 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
[39] 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
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.content.html.html5_form_validation_turned_off
Abstract
프로그램이 지나치게 허용적인 COOP(Cross-Origin Opener Policy)를 정의합니다.
Explanation
Spectre, Meltdown 등의 취약성으로 인해 부채널 악용이 발생할 수도 있으므로 특정 웹 문서의 데이터 개인 정보를 보호하는 정책 적용 작업의 중요성이 높아졌습니다. COOP(Cross-Origin Opener Policy)는 부채널 공격에 따른 중요한 정보 노출을 방지하기 위해 제작되었습니다. 구체적으로는 COOP를 통해 팝업 등의 기타 외부 문서와 관련한 문서 검색 컨텍스트 그룹을 격리할 수 있습니다.

예제 1: 다음 코드에는 Django 프레임워크의 안전하지 않은 COOP 설정인 'unsafe-none'이 나와 있습니다. 이 설정을 사용하는 경우 부채널 공격이 발생하면 외부 문서가 소스 문서의 검색 컨텍스트 그룹에 포함된 개인 데이터에 액세스하게 될 수도 있습니다.


SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'
References
[1] Eiji Kitamura, Domenic Denicola Why you need "cross-origin isolated" for powerful features
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 346
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[11] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[14] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.6 - Web Software Attack Mitigation
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.structural.python.html5_insecure_cross_origin_opener_policy
Abstract
Application_BeginRequest 메서드가 비어 있거나 X-Content-Type-Optionsnosniff로 설정하는 함수 호출을 포함하지 않거나 해당 헤더를 제거하려고 합니다.
Explanation
MIME 염탐은 바이트 스트림의 콘텐트를 검사하여 포함된 데이터의 파일 형식을 추론하는 공격입니다.

MIME 염탐을 명시적으로 비활성화하지 않으면 의도하지 않은 방식으로 데이터를 해석하도록 일부 브라우저가 조작될 수 있으며, 이를 통해 Cross-Site Scripting 공격이 이루어질 수 있습니다.

사용자가 제어 가능한 콘텐트를 포함할 수 있는 모든 페이지에는 X-Content-Type-Options: nosniff라는 HTTP 헤더를 사용해야 합니다.
References
[1] Reducing MIME type security risks
[2] ASP.NET Configuration Files
[3] Global.asax Syntax
[4] IE8 Security Part V: Comprehensive Protection
[5] Custom HttpModule Example
[6] HttpResponse Class
[7] MIME types and stylesheets
[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[9] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[10] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[11] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[12] Standards Mapping - CIS Kubernetes Benchmark complete
[13] Standards Mapping - Common Weakness Enumeration CWE ID 554
[14] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[15] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[16] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[17] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[18] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[19] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[20] Standards Mapping - FIPS200 CM
[21] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[22] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[23] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[24] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[25] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[26] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[27] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[28] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[29] 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)
[30] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[31] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[43] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[64] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.dotnet.html5_mime_sniffing
Abstract
응용 프로그램은 MIME 염탐 알고리즘을 적용하거나 X-Content-Type-Optionsnosniff로 설정하지 않습니다.
Explanation
MIME 염탐은 바이트 스트림의 콘텐트를 검사하여 포함된 데이터의 파일 형식을 추론하는 공격입니다.

MIME 염탐을 명시적으로 비활성화하지 않으면 의도하지 않은 방식으로 데이터를 해석하도록 일부 브라우저가 조작될 수 있으며, 이를 통해 Cross-Site Scripting 공격이 이루어질 수 있습니다.
웹 응용 프로그램을 작성할 때 사용자가 제어 가능한 콘텐트를 포함할 수 있는 각 페이지에 HTTP 헤더 X-Content-Type-Options: nosniff를 사용합니다.
클라이언트 응용 프로그램을 작성할 때 서버의 응답 Content-Type을 결정하는 데 MIME 염탐 알고리즘을 사용해서는 안 됩니다.

예제: 다음 코드는 net.http.DetectContentType()을 사용하여 응답 Content-Type을 결정합니다.


...
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)

content_type := DetectContentType(body)
...
References
[1] OWASP OWASP Secure Headers Project
[2] WHATWG MIME Sniffing
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[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.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.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
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[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-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.golang.html5_mime_sniffing
Abstract
응용 프로그램에서는 X-Content-Type-Optionsnosniff로 설정하거나 이 보안 헤더를 명시적으로 비활성화하지 않습니다.
Explanation
MIME 염탐은 바이트 스트림의 콘텐트를 검사하여 포함된 데이터의 파일 형식을 추론하는 것입니다.

MIME 염탐을 명시적으로 비활성화하지 않으면 공격자는 의도하지 않은 방식으로 데이터를 해석하도록 일부 브라우저를 조작할 수 있으며, 이를 통해 Cross-Site Scripting 공격이 이루어질 수 있습니다. 사용자가 제어 가능한 콘텐트를 포함할 수 있는 모든 페이지에는 X-Content-Type-Options: nosniff라는 HTTP 헤더를 사용해야 합니다.

예제: 다음 코드는 MIME 염탐 보호를 사용하지 않도록 Spring Security로 보호된 응용 프로그램을 구성합니다.

<http auto-config="true">
...
<headers>
...
<content-type-options disabled="true"/>
</headers>
</http>
References
[1] OWASP OWASP Secure Headers Project
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark complete
[7] Standards Mapping - Common Weakness Enumeration CWE ID 554
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[14] Standards Mapping - FIPS200 CM
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] 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)
[24] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[25] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 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 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_mime_sniffing
Abstract
Node.js 응용 프로그램에서는 X-Content-Type-Optionsnosniff로 설정하거나 이 보안 헤더를 명시적으로 비활성화하지 않습니다.
Explanation
MIME 염탐은 바이트 스트림의 콘텐트를 검사하여 포함된 데이터의 파일 형식을 추론하는 공격입니다.

MIME 염탐을 명시적으로 비활성화하지 않으면 의도하지 않은 방식으로 데이터를 해석하도록 일부 브라우저가 조작될 수 있으며, 이를 통해 Cross-Site Scripting 공격이 이루어질 수 있습니다.

사용자가 제어 가능한 콘텐트를 포함할 수 있는 모든 페이지에는 X-Content-Type-Options: nosniff라는 HTTP 헤더를 사용해야 합니다.
References
[1] Node.js Security Checklist
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[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.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.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
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[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-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.javascript.html5_mime_sniffing
Abstract
Django 응용 프로그램에서는 X-Content-Type-Optionsnosniff로 설정하거나 이 보안 헤더를 명시적으로 비활성화하지 않습니다.
Explanation
MIME 염탐은 바이트 스트림의 콘텐트를 검사하여 포함된 데이터의 파일 형식을 추론하는 공격입니다.

MIME 염탐을 명시적으로 비활성화하지 않으면 의도하지 않은 방식으로 데이터를 해석하도록 일부 브라우저가 조작될 수 있으며, 이를 통해 Cross-Site Scripting 공격이 이루어질 수 있습니다.

사용자가 제어 가능한 콘텐트를 포함할 수 있는 모든 페이지에는 X-Content-Type-Options: nosniff라는 HTTP 헤더를 사용해야 합니다.
References
[1] SECURE_CONTENT_TYPE_NOSNIFF
[2] django-secure
[3] OWASP OWASP Secure Headers Project
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 554
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[16] Standards Mapping - FIPS200 CM
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[20] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[21] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[25] 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)
[26] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[27] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 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 4.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_mime_sniffing
Abstract
CSP를 잘못 구성하면 응용 프로그램이 cross-site scripting, cross-frame scripting, cross-site request forgery를 포함한 클라이언트 쪽 위협에 노출될 수 있습니다.
Explanation
CSP(Content Security Policy)는 웹 브라우저에서 렌더링될 때 사이트에서 콘텐트를 로드하거나 연결을 시작할 수 있도록 허용된 도메인을 지정하는, 선언적 보안 헤더입니다. CSP는 코드의 허용 목록 검사 및 입력 확인 외에 Cross-Site Scripting, 클릭재킹(Clickjacking), Cross-Origin 접근 등의 중요한 취약점을 차단하기 위한 추가 보안 계층 역할을 합니다. 하지만 헤더를 잘못 구성하면 이러한 추가 보안 계층이 형성되지 않습니다. 정책은 15개의 지정자를 사용하여 정의하는데, 이 가운데 다음 8개는 리소스 접근을 제어합니다. script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src.

이러한 각 지정자는 사이트가 해당 지정자에서 관여하는 기능에 접근할 수 있는 도메인을 지정하는 값으로 소스 목록을 사용합니다. 개발자는 전체 또는 일부 소스를 나타내기 위해 와일드카드인 *를 사용할 수도 있습니다. 지정자를 반드시 사용해야 하는 것은 아닙니다. 브라우저는 목록에 나열되지 않은 지정자에 대해 모든 소스를 허용하기도 하고 선택적 default-src 지정자에서 값을 파생하기도 합니다. 또한, 이 헤더의 사양은 시간이 지남에 따라 발전해 왔습니다. Firefox(버전 23까지)와 IE(버전 10까지)에서는 X-Content-Security-Policy로 구현되어 있었으며 Chrome(버전 25까지)에서는 X-Webkit-CSP로 구현되어 있었습니다. 하지만 이제는 새 표준 이름인 Content Security Policy를 사용하기 위해 두 이름 모두 더 이상 사용되지 않습니다. 지정자의 수, 더 이상 사용되지 않는 2개의 대체 이름, 그리고 단일 헤더에서 여러 번 나타나는 동일한 헤더와 반복되는 지정자가 처리되는 방식을 감안하면 개발자가 이 헤더를 잘못 구성할 확률이 높습니다.

다음과 같은 구성 오류 시나리오를 살펴보십시오.

- unsafe-inline 또는 unsafe-eval이 포함된 지정자는 CSP를 사용하는 목적을 무효화합니다.
- script-src 지정자가 설정되어 있지만 nonce 스크립트는 구성되어 있지 않습니다.
- frame-src가 설정되어 있지만 sandbox는 구성되어 있지 않습니다.
- 동일한 응답에서 이 헤더의 여러 인스턴스가 허용됩니다. 개발 팀과 보안 팀이 모두 헤더를 설정한 상황에서 어느 한 팀이 더 이상 사용되지 않는 이름 중 하나를 사용할 수도 있습니다. 최신 이름(즉, Content Security Policy)이 지정된 헤더가 없는 경우에는 더 이상 사용되지 않는 헤더가 허용되지만 이름이 content-security-header로 지정된 정책이 있는 경우에는 이러한 헤더가 무시됩니다. 이전 버전에서는 더 이상 사용되지 않는 이름만 인식하므로 원하는 지원 수준을 확보하려면 응답에 포함된 동일한 정책에 3개의 이름이 모두 지정되어 있어야 합니다.
- 헤더의 동일한 인스턴스에서 지정자가 반복되는 경우 이후에 사용되는 지정자는 모두 무시됩니다.

예제 1: 다음 django-csp 구성에서는 안전하지 않은 unsafe-inlineunsafe-eval 지정자를 사용하여 인라인 스크립트 및 코드 평가를 허용합니다.


...
MIDDLEWARE_CLASSES = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...
References
[1] OWASP Content Security Policy
[2] W3C Content Security Policy 1.1
[3] Mozilla django-csp
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - Common Weakness Enumeration CWE ID 942, CWE ID 1173
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020, [24] CWE ID 863
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] 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.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[25] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[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
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_misconfigured_content_security_policy
Abstract
CSP(Content Security Policy)가 구성되지 않았습니다.
Explanation
CSP는 웹 브라우저에서 렌더링될 때 사이트에서 콘텐트를 로드하거나 연결을 시작할 수 있도록 허용된 도메인을 지정하는, 선언적 보안 헤더입니다. CSP는 코드의 허용 목록 검사 및 입력 확인 외에 Cross-Site Scripting, 클릭재킹(Clickjacking), Cross-Origin 접근 등의 중요한 취약점을 차단하기 위한 추가 보안 계층 역할을 합니다.

Spring Security 및 기타 프레임워크는 기본적으로 Content Security Policy 헤더를 추가하지 않습니다. 웹 응용 프로그램 작성자는 이 추가 보안 계층의 혜택을 받으려면 보호된 리소스를 적용하거나 모니터링하기 위한 보안 정책을 선언해야 합니다.
References
[1] OWASP Content Security Policy
[2] W3C Content Security Policy 1.1
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 1173
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[17] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] 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)
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_missing_content_security_policy