계: Input Validation and Representation
입력 검증 및 표현 문제는 메타 문자, 대체 인코딩 및 숫자 표현 때문에 발생합니다. 보안 문제는 입력을 신뢰하기 때문에 발생합니다. 문제로는 "Buffer Overflows", "Cross-Site Scripting" 공격, "SQL Injection", 그 외 여러 가지가 있습니다.
Cross-Site Scripting: Poor Validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
cl_http_utility=>escape_html
과 같은 특정 인코딩 함수 모듈을 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수 모듈을 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우, 신뢰할 수 없는 소스는 주로 웹 요청이며, Persistent(Stored라고도 알려짐) XSS의 경우에는 데이터베이스 쿼리의 결과입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 ABAP 코드 세그먼트는 HTTP 요청에서 직원 ID 인
eid
를 읽고 HTML 인코딩하여 사용자에게 표시합니다.
...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = eid
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_eid ).
...
다음 예제의 코드는
eid
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 ABAP 코드 세그먼트는 주어진 ID를 가진 직원을 데이터베이스에 쿼리하여 HTML 인코딩한 해당 직원의 이름을 인쇄합니다.
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = itab_employees-name
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_name ).
...
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] SAP OSS notes 1582870, 1582867 and related notes for ABAP XSS support
[2] SAP OSS Notes 822881, 1600317, 1640092, 1671470 and 1638779 for XSS support in BSPs
[3] Understanding Malicious Content Mitigation for Web Developers CERT
[4] HTML 4.01 Specification W3
[5] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[18] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[19] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[20] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2021 A03 Injection
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[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 - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.abap.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 ActionScript 코드 세그먼트는 HTTP 요청에서 직원 ID 인
다음 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 ActionScript 코드 세그먼트는 주어진 ID를 가진 직원을 데이터베이스에 쿼리하여 HTML 인코딩한 해당 직원의 이름을 인쇄합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
-
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 ActionScript 코드 세그먼트는 HTTP 요청에서 직원 ID 인
eid
를 읽고 HTML 인코딩하여 사용자에게 표시합니다.
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + escape(eid);
...
다음 예제의 코드는
eid
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 ActionScript 코드 세그먼트는 주어진 ID를 가진 직원을 데이터베이스에 쿼리하여 HTML 인코딩한 해당 직원의 이름을 인쇄합니다.
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + escape(name);
}
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.actionscript.cross_site_scripting_poor_validation
Abstract
확인되지 않은 데이터를 웹 브라우저에 전송하면 악성 코드의 실행을 초래할 수 있습니다.
Explanation
사용자가 제공하는 데이터와 웹 브라우저 파서 간의 발생 가능한 대량의 상호 작용으로 인해, 적용된 인코딩이 XSS 취약점으로부터 보호하기에 충분한지를 항상 적절하게 평가할 수는 없습니다. 따라서 Fortify Static Code Analyzer는 인코딩이 적용되는 경우에도 Cross-Site Scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우, 신뢰할 수 없는 소스는 주로 웹 요청이며, Persistent(Stored라고도 알려짐) XSS의 경우에는 데이터베이스 쿼리의 결과입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
악성 컨텐츠는 일반적으로 JavaScript 코드의 일부이지만 HTML, Flash 또는 브라우저에서 실행할 수 있는 기타 활성 컨텐츠일 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 Apex 코드 세그먼트는 지정된 ID를 가진 연락처 이름을 데이터베이스에 쿼리하고 해당 직원의 이름을 반환하며, 이는 나중에 Visualforce 코드에 의해 인쇄됩니다.
이 코드는
예제 2: 다음 Visualforce 코드 세그먼트는 HTTP 요청 매개 변수(
이 예제의 코드는 영숫자 텍스트만 수신하고 표시하도록 의도되었습니다. 하지만
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 실행되는 방식은 두 가지가 있습니다.
-
-
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우, 신뢰할 수 없는 소스는 주로 웹 요청이며, Persistent(Stored라고도 알려짐) XSS의 경우에는 데이터베이스 쿼리의 결과입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
악성 컨텐츠는 일반적으로 JavaScript 코드의 일부이지만 HTML, Flash 또는 브라우저에서 실행할 수 있는 기타 활성 컨텐츠일 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 Apex 코드 세그먼트는 지정된 ID를 가진 연락처 이름을 데이터베이스에 쿼리하고 해당 직원의 이름을 반환하며, 이는 나중에 Visualforce 코드에 의해 인쇄됩니다.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>
이 코드는
HTMLENCODE
의 사용에도 불구하고, 데이터베이스에서 제공하는 데이터를 적절하게 확인하지 않으며 XSS에 취약합니다. 이는 variable
콘텐트가 서로 다른 메커니즘(HTML 및 Javascript 파서)에 의해 구문 분석되기 때문에 발생하므로, 두 번 인코딩되어야 합니다. 이러한 방식으로 공격자는 Reflected XSS에서처럼 피해자와 상호 작용할 필요 없이 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. Stored XSS(또는 Persistent)로 알려진 이런 공격 유형은, 데이터가 취약한 기능에 간접적으로 제공되므로 감지하기 매우 어려울 수 있으며, 여러 사용자에게 영향을 줄 수 있으므로 더 큰 영향을 미칠 수도 있습니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제 2: 다음 Visualforce 코드 세그먼트는 HTTP 요청 매개 변수(
username
)를 읽고 사용자에게 표시합니다.
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
이 예제의 코드는 영숫자 텍스트만 수신하고 표시하도록 의도되었습니다. 하지만
username
에 메타 문자 또는 소스 코드가 포함되어 있으면 웹 브라우저에 의해 실행됩니다. 또한 이 예제에서 변수가 JavaScript 파서에 의해 처리되므로 HTMLENCODE
의 사용은 XSS 공격을 방지하기에 충분하지 않습니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 실행되는 방식은 두 가지가 있습니다.
-
Example 1
에서처럼 데이터베이스 또는 다른 데이터 저장소는 동적 콘텐트에 포함될 위험한 데이터를 응용 프로그램에 제공할 수 있습니다. 공격자의 관점에서 악성 콘텐트를 저장할 최적의 장소는 모든 사용자 특히 높은 권한을 가진 사용자(민감한 정보를 처리하고 중요한 작업을 수행할 가능성이 높은 사용자)가 액세스할 수 있는 장소입니다.-
Example 2
에서처럼 데이터를 HTTP 요청에서 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. Reflected XSS는 공격자가 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공한 후 사용자에게 다시 적용하여 사용자의 브라우저에 의해 실행될 때 발생합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 공개적으로 게시되거나 피해자에게 직접 전자 메일로 전송되는 URL의 매개 변수로 악성 콘텐트를 포함하는 것입니다. 이러한 방식으로 생성된 URL은 공격자가 피해자를 속여 해당 URL을 방문하게 하는 많은 피싱 기법의 근간을 이룹니다. 사이트가 콘텐트를 사용자에게 다시 적용한 후, 해당 콘텐트가 실행되고 민감한 개인 정보 전달, 피해자 컴퓨터에서 권한이 없는 작업 실행 등과 같은 여러 작업을 수행할 수 있습니다.References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Salesforce Developers Technical Library Secure Coding Guidelines - Cross Site Scripting
[4] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, 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 Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.apex.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 ASP.NET 코드 세그먼트는 HTTP 요청에서 직원 ID 번호를 읽고 HTML 인코딩을 수행하여 사용자에게 표시합니다.
여기서
이러한 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 링크를 클릭하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 3: 다음 ASP.NET 코드 세그먼트는 지정된 직원 ID의 직원에 대한 데이터베이스를 쿼리하여 이 ID에 해당하는 HTML로 인코딩된 이름을 인쇄합니다.
여기서
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
-
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
많은 최신 웹 프레임워크는 사용자 입력의 검증을 수행하기 위한 메커니즘을 제공합니다(ASP.NET Request Validation 및 WCF 포함). 확인되지 않은 입력의 소스를 강조하기 위해, Fortify 보안 코딩 규칙 팩은 악용 가능성을 낮추고 프레임워크 검증 메커니즘이 사용 중일 때마다 지원하는 증거에 포인터를 제공하여 Fortify Static Code Analyzer에서 보고한 문제의 우선 순위를 동적으로 재지정합니다. ASP.NET Request Validation으로 검증이 명시적으로 비활성화된 경우에 대한 증거도 제공합니다. 이 기능을 Context-Sensitive Ranking(컨텍스트 감지 순위)이라고 부릅니다. Fortify 사용자의 감사 프로세스를 지원하기 위해, Fortify Software Security Research Group은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 ASP.NET 코드 세그먼트는 HTTP 요청에서 직원 ID 번호를 읽고 HTML 인코딩을 수행하여 사용자에게 표시합니다.
<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
...
</script>
여기서
Login
및 EmployeeID
는 다음과 같이 정의된 폼 컨트롤입니다.예제 2: 다음 ASP.NET 코드 세그먼트는 프로그래밍 방식이긴 해도
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1
과 동일한 기능을 구현합니다.
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
이러한 예제의 코드는
Login
에 표준 영숫자 텍스트만 있으면 올바르게 동작합니다. Login
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 링크를 클릭하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 3: 다음 ASP.NET 코드 세그먼트는 지정된 직원 ID의 직원에 대한 데이터베이스를 쿼리하여 이 ID에 해당하는 HTML로 인코딩된 이름을 인쇄합니다.
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
</script>
여기서
EmployeeName
은 다음과 같이 정의된 폼 컨트롤입니다.예제 4: 마찬가지로 다음 ASP.NET 코드 세그먼트는
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3
과 기능적으로 동일하지만 프로그래밍 방식으로 모든 form elements를 구현합니다.
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
Example 1
및 Example 2
에서처럼 이러한 코드 세그먼트는 name
의 값이 올바르게 동작할 때는 정확하게 수행하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무런 조치도 취하지 않습니다. 이러한 코드 예제는 name
의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
및 Example 2
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 3
및 Example 4
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
많은 최신 웹 프레임워크는 사용자 입력의 검증을 수행하기 위한 메커니즘을 제공합니다(ASP.NET Request Validation 및 WCF 포함). 확인되지 않은 입력의 소스를 강조하기 위해, Fortify 보안 코딩 규칙 팩은 악용 가능성을 낮추고 프레임워크 검증 메커니즘이 사용 중일 때마다 지원하는 증거에 포인터를 제공하여 Fortify Static Code Analyzer에서 보고한 문제의 우선 순위를 동적으로 재지정합니다. ASP.NET Request Validation으로 검증이 명시적으로 비활성화된 경우에 대한 증거도 제공합니다. 이 기능을 Context-Sensitive Ranking(컨텍스트 감지 순위)이라고 부릅니다. Fortify 사용자의 감사 프로세스를 지원하기 위해, Fortify Software Security Research Group은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Anti-Cross Site Scripting Library MSDN
[4] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, 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 Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.dotnet.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우, 신뢰할 수 없는 소스는 주로 웹 요청이며, Persistent(Stored라고도 알려짐) XSS의 경우에는 데이터베이스 쿼리의 결과입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 코드 세그먼트는 HTTP 요청으로부터
다음 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
- 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우, 신뢰할 수 없는 소스는 주로 웹 요청이며, Persistent(Stored라고도 알려짐) XSS의 경우에는 데이터베이스 쿼리의 결과입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 코드 세그먼트는 HTTP 요청으로부터
text
매개 변수를 읽어들이고 HTML 인코딩하여 이를 스크립트 태그 사이의 경고 상자에 표시합니다.
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
다음 예제의 코드는
text
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. text
에 작은 따옴표, 둥근 괄호 및 세미콜론이 있는 경우, 코드가 실행되는 이후로 alert
텍스트 상자를 종료합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.- 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.cfml.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-Site Scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 Ruby 코드 세그먼트는 HTTP 요청에서 사용자 이름인
다음 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 Go 코드 세그먼트는 주어진 ID를 가진 직원을 데이터베이스에 쿼리하여 해당 직원의 이름을 인쇄합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
-
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
XSS(Cross-Site Scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 Ruby 코드 세그먼트는 HTTP 요청에서 사용자 이름인
user
를 읽어 사용자에게 표시합니다.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(user))
}
다음 예제의 코드는
user
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. user
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 Go 코드 세그먼트는 주어진 ID를 가진 직원을 데이터베이스에 쿼리하여 해당 직원의 이름을 인쇄합니다.
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(name))
}
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서 볼 수 있듯이 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 반영합니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서 볼 수 있듯이 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.golang.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
escapeXml="true"
속성(기본 동작)과 함께 <c:out/>
태그와 같은 특정 인코딩 구성을 사용하면 일부 공격은 막을 수 있지만 모든 Cross-Site Scripting 공격은 막을 수 없습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 구성을 사용하는 것은 약한 거부 목록을 사용하여 Cross-Site Scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Static Code Analyzer는 인코딩이 적용되는 경우에도 Cross-Site Scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우, 신뢰할 수 없는 소스는 주로 웹 요청이며, Persistent(Stored라고도 알려짐) XSS의 경우에는 데이터베이스 쿼리의 결과입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 JSP 코드 세그먼트는 HTTP 요청에서 직원 ID인
eid
를 읽어 <c:out/>
태그를 통해 사용자에게 표시합니다.
Employee ID: <c:out value="${param.eid}"/>
다음 예제의 코드는
eid
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 JSP 코드 세그먼트는 지정된 직원 ID의 직원에 대한 데이터베이스를 쿼리하여
<c:out/>
태그를 통해 해당 직원의 이름을 인쇄합니다.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <c:out value="${name}"/>
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.모바일 환경에서는 Cross-Site Scripting과 같은 전형적인 웹 응용 프로그램 취약성이 발생하지 않는다고 생각하는 사용자도 있습니다. 자기 자신을 공격하는 사용자는 없을 것이라 여기기 때문입니다. 그러나 모바일 플랫폼의 핵심 요소는 다양한 소스에서 다운로드되어 같은 장치에서 함께 실행되는 응용 프로그램이라는 점을 유념해야 합니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 프로세스 간 통신을 포함하도록 모바일 응용 프로그램의 공격 표면을 확장해야 합니다.
예제 3: 다음 코드는 Android의 WebView에서 JavaScript를 활성화(기본적으로 JavaScript는 비활성화됨)하고 Android 인텐트에서 받은 값을 기준으로 페이지를 로드합니다.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(URLEncoder.encode(url));
...
url
값이 javascript:
로 시작하면 그 뒤에 오는 JavaScript 코드가 WebView 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.-
Example 3
과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.많은 최신 웹 프레임워크는 사용자 입력의 검증을 수행하기 위한 메커니즘을 제공합니다(Struts 및 Struts 2 포함). 확인되지 않은 입력의 소스를 강조하기 위해, Fortify 보안 코딩 규칙 팩은 악용 가능성을 낮추고 프레임워크 검증 메커니즘이 사용 중일 때마다 지원하는 증거에 포인터를 제공하여 Fortify Static Code Analyzer에서 보고한 문제의 우선 순위를 동적으로 재지정합니다. 이 기능을 Context-Sensitive Ranking(컨텍스트 감지 순위)이라고 부릅니다. Fortify 사용자의 감사 프로세스를 지원하기 위해, Fortify Software Security Research Group은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[61] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.java.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. DOM-based XSS의 경우, URL 매개 변수 또는 브라우저 내 다른 값에서 데이터를 읽어들이며 클라이언트 쪽 코드를 사용하여 페이지에 다시 씁니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다. DOM-based XSS의 경우, 피해자의 브라우저가 HTML 페이지를 구문 분석할 때마다 악성 콘텐트가 DOM(Document Object Model) 생성의 일부로 실행됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 JavaScript 코드 세그먼트는 HTTP 요청에서 직원 ID인
다음 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
- 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.
- 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. DOM-based XSS의 경우, URL 매개 변수 또는 브라우저 내 다른 값에서 데이터를 읽어들이며 클라이언트 쪽 코드를 사용하여 페이지에 다시 씁니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다. DOM-based XSS의 경우, 피해자의 브라우저가 HTML 페이지를 구문 분석할 때마다 악성 콘텐트가 DOM(Document Object Model) 생성의 일부로 실행됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 JavaScript 코드 세그먼트는 HTTP 요청에서 직원 ID인
eid
를 읽고 이스케이프 처리하여 사용자에게 표시합니다.
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>
다음 예제의 코드는
eid
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
- 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.
- 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.javascript.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
escapeXml="true"
속성(기본 동작)과 함께 <c:out/>
태그와 같은 특정 인코딩 구성을 사용하면 일부 공격은 막을 수 있지만 모든 Cross-Site Scripting 공격은 막을 수 없습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 구성을 사용하는 것은 약한 거부 목록을 사용하여 Cross-Site Scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Static Code Analyzer는 인코딩이 적용되는 경우에도 Cross-Site Scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.XSS(Cross-Site Scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 주로 웹 요청이며, Persistent(Stored라고도 함) XSS의 경우 데이터베이스 쿼리의 결과입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
다음 예제의 코드는
eid
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.모바일 환경에서는 Cross-Site Scripting과 같은 전형적인 웹 응용 프로그램 취약성이 발생하지 않는다고 생각하는 사용자도 있습니다. 자기 자신을 공격하는 사용자는 없을 것이라 여기기 때문입니다. 그러나 모바일 플랫폼의 핵심 요소는 다양한 소스에서 다운로드되어 같은 장치에서 함께 실행되는 응용 프로그램이라는 점을 유념해야 합니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 프로세스 간 통신을 포함하도록 모바일 응용 프로그램의 공격 표면을 확장해야 합니다.
예제 3: 다음 코드는 Android의 WebView에서 JavaScript를 활성화(기본적으로 JavaScript는 비활성화됨)하고 Android 인텐트에서 받은 값을 기준으로 페이지를 로드합니다.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(URLEncoder.encode(url))
...
url
값이 javascript:
로 시작하면 그 뒤에 오는 JavaScript 코드가 WebView 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.-
Example 3
과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.많은 최신 웹 프레임워크는 사용자 입력의 검증을 수행하기 위한 메커니즘을 제공합니다(Struts 및 Spring MVC 포함). 확인되지 않은 입력의 소스를 강조하기 위해, Fortify 보안 코딩 규칙 팩은 악용 가능성을 낮추고 프레임워크 검증 메커니즘이 사용 중일 때마다 지원하는 증거에 포인터를 제공하여 Fortify Static Code Analyzer에서 보고한 문제의 우선 순위를 동적으로 재지정합니다. 이 기능을 Context-Sensitive Ranking(컨텍스트 감지 순위)이라고 부릅니다. Fortify 사용자의 감사 프로세스를 지원하기 위해, Fortify Software Security Research Group은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[61] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.kotlin.cross_site_scripting_poor_validation
Abstract
이 메서드는 악성 코드가 웹 브라우저에 도달하는 것을 예방하기에는 충분하지 않은 HTML, XML 또는 기타 인코딩 유형을 사용합니다.
Explanation
ESAPI 또는 AntiXSS와 같은 특정 인코딩 구조를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 구성을 사용하는 것은 약한 거부 목록을 사용하여 Cross-Site Scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Static Code Analyzer는 인코딩이 적용되는 경우에도 Cross-Site Scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 페이지에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 사용자 구성 요소, URL 스키마 처리기 또는 알림을 통하지만, Persistent(Stored라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 확인 작업을 거치지 않고 UIWebView 구성 요소에 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
다음 예제는 인코딩 API를 사용하여 인코딩되는 익스플로이트 가능한 XSS 인스턴스를 보여줍니다.
예제 1: 다음 Objective-C 코드 세그먼트는 응용 프로그램에 전달되어 호출한 사용자 지정 URL 스키마의 텍스트 부분을 읽습니다(
예제에서처럼, XSS 취약점은 HTTP 콘텐트에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
-
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 페이지에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 사용자 구성 요소, URL 스키마 처리기 또는 알림을 통하지만, Persistent(Stored라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 확인 작업을 거치지 않고 UIWebView 구성 요소에 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
다음 예제는 인코딩 API를 사용하여 인코딩되는 익스플로이트 가능한 XSS 인스턴스를 보여줍니다.
예제 1: 다음 Objective-C 코드 세그먼트는 응용 프로그램에 전달되어 호출한 사용자 지정 URL 스키마의 텍스트 부분을 읽습니다(
myapp://input_to_the_application
). 그런 다음 URL의 신뢰할 수 없는 데이터가 UIWebView 구성 요소의 HTML 출력을 렌더링하는 데 사용됩니다.
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
...
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
[DefaultEncoder encodeForHTML:partAfterSlashSlash],
@"')\" />"];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:htmlPage baseURL:nil];
...
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 데이터베이스에서 읽어들이고 HTML로 인코딩하기 때문에 덜 위험한 것처럼 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 공격자가 제공하는 익스플로이트는 인코딩한 문자를 무시하거나 HTML 인코딩의 영향을 받지 않는 컨텍스트에 입력할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제에서처럼, XSS 취약점은 HTTP 콘텐트에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터는 사용자 지정 URL 스키마에서 직접 읽어 들여 UIWebView 응답의 콘텐트에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 iOS 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 사용자 지정 스키마 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 취약한 응용 프로그램을 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 앱이 공격자의 컨텐츠를 사용자에게 보내면, 컨텐츠가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] W/Labs Continued Adventures with iOS UIWebViews
[4] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, 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 Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.objc.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
htmlspecialchars()
또는 htmlentities()
와 같은 특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 '(ENT_QUOTES
가 설정된 경우에만) 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우, 신뢰할 수 없는 소스는 주로 웹 요청이며, Persistent(Stored라고도 알려짐) XSS의 경우에는 데이터베이스 쿼리의 결과입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 코드 세그먼트는 HTTP 요청으로부터
text
매개 변수를 읽어들이고 HTML 인코딩하여 이를 스크립트 태그 사이의 경고 상자에 표시합니다.
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
다음 예제의 코드는
text
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. text
에 작은 따옴표, 둥근 괄호 및 세미콜론이 있는 경우, 코드가 실행되는 이후로 alert
텍스트 상자를 종료합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.- 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.php.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 코드 세그먼트는 HTTP 요청에서 직원 ID 인
다음 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 코드 세그먼트는 주어진 직원 ID를 가진 직원을 데이터베이스에 쿼리하여 해당 URL 인코딩한 직원의 이름을 인쇄합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
-
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 코드 세그먼트는 HTTP 요청에서 직원 ID 인
eid
를 읽고 URL 인코딩하여 사용자에게 표시합니다.
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || HTMLDB_UTIL.url_encode(eid) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
다음 예제의 코드는
eid
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 코드 세그먼트는 주어진 직원 ID를 가진 직원을 데이터베이스에 쿼리하여 해당 URL 인코딩한 직원의 이름을 인쇄합니다.
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || HTMLDB_UTIL.url_encode(name) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.sql.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 Python 코드 세그먼트는 HTTP 요청에서 직원 ID 인
다음 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 Python 코드 세그먼트는 주어진 직원 ID를 가진 직원을 데이터베이스에 쿼리하여 HTML 인코딩한 해당 직원의 이름을 인쇄합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
-
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 Python 코드 세그먼트는 HTTP 요청에서 직원 ID 인
eid
를 읽고 HTML 인코딩하여 사용자에게 표시합니다.
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + escape(eid))
다음 예제의 코드는
eid
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 Python 코드 세그먼트는 주어진 직원 ID를 가진 직원을 데이터베이스에 쿼리하여 HTML 인코딩한 해당 직원의 이름을 인쇄합니다.
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.python.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 Ruby 코드 세그먼트는 HTTP 요청에서 직원 ID 인
다음 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 이러한 메커니즘을 Reflected XSS라고 합니다. 하지만
예제 2: 다음 Ruby 코드 세그먼트는 주어진 ID를 가진 직원을 데이터베이스에 쿼리하여 HTML 인코딩한 해당 직원의 이름을 인쇄합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
-
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 Ruby 코드 세그먼트는 HTTP 요청에서 직원 ID 인
eid
를 읽고 HTML 인코딩하여 사용자에게 표시합니다.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
다음 예제의 코드는
eid
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 이러한 메커니즘을 Reflected XSS라고 합니다. 하지만
Rack::Request#params()
를 Example 1
에서처럼 사용하는 경우에는 GET
매개 변수와 POST
매개 변수가 모두 있으므로 URL에 악의적인 코드가 추가되는 것 외에도 다양한 유형의 공격에 취약해질 수 있습니다.예제 2: 다음 Ruby 코드 세그먼트는 주어진 ID를 가진 직원을 데이터베이스에 쿼리하여 HTML 인코딩한 해당 직원의 이름을 인쇄합니다.
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.ruby.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
특정 인코딩 구문을 사용하면 일부 Cross-Site Scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 구성을 사용하는 것은 약한 거부 목록을 사용하여 Cross-Site Scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Static Code Analyzer는 인코딩이 적용되는 경우에도 Cross-Site Scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-Site Scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우, 신뢰할 수 없는 소스는 주로 웹 요청이며, Persistent(Stored라고도 알려짐) XSS의 경우에는 데이터베이스 쿼리의 결과입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 Play 컨트롤러 코드 세그먼트는 HTTP 요청에서 직원 ID인
다음 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
XSS(Cross-Site Scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우, 신뢰할 수 없는 소스는 주로 웹 요청이며, Persistent(Stored라고도 알려짐) XSS의 경우에는 데이터베이스 쿼리의 결과입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 Play 컨트롤러 코드 세그먼트는 HTTP 요청에서 직원 ID인
eid
를 읽어 사용자에게 표시합니다.
def getEmployee = Action { implicit request =>
var eid = request.getQueryString("eid")
eid = StringEscapeUtils.escapeHtml(eid); // insufficient validation
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
다음 예제의 코드는
eid
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] INJECT-3: XML and HTML generation requires care Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, 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 Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.scala.cross_site_scripting_poor_validation
Abstract
이 메서드는 악성 코드가 웹 브라우저에 도달하는 것을 예방하기에는 충분하지 않은 HTML, XML 또는 기타 인코딩 유형을 사용합니다.
Explanation
ESAPI 또는 AntiXSS와 같은 특정 인코딩 구조를 사용하면 일부 Cross-Site Scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 구성을 사용하는 것은 약한 거부 목록을 사용하여 Cross-Site Scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Static Code Analyzer는 인코딩이 적용되는 경우에도 Cross-Site Scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 페이지에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 사용자 구성 요소, URL 스키마 처리기 또는 알림을 통하지만, Persistent(Stored라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 확인 작업을 거치지 않고 UIWebView 구성 요소에 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
다음 예제는 인코딩 API를 사용하여 인코딩되는 익스플로이트 가능한 XSS 인스턴스를 보여줍니다.
예제 1: 다음 Swift 코드 세그먼트는 응용 프로그램에 전달되어 호출한 사용자 지정 URL 스키마의 텍스트 부분을 읽습니다(
예제 3: 다음 코드에서는 UITextField의 콘텐트를 읽고 이를 WKWebView 내에서 사용자에게 표시합니다.
다음 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 하지만 자신의 장치에서 악의적인 코드가 실행되도록 할 수 있는 입력을 제공하는 이유가 있을까요? 정말 위험한 일은 공격자가 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 이러한 동작을 수행하도록 만드는 것입니다. 이러한 공격에 성공하면 피해자는 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 장치로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제에서처럼, XSS 취약점은 HTTP 콘텐트에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
-
-
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 페이지에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 사용자 구성 요소, URL 스키마 처리기 또는 알림을 통하지만, Persistent(Stored라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 확인 작업을 거치지 않고 UIWebView 구성 요소에 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
다음 예제는 인코딩 API를 사용하여 인코딩되는 익스플로이트 가능한 XSS 인스턴스를 보여줍니다.
예제 1: 다음 Swift 코드 세그먼트는 응용 프로그램에 전달되어 호출한 사용자 지정 URL 스키마의 텍스트 부분을 읽습니다(
myapp://input_to_the_application
). 그런 다음 URL의 신뢰할 수 없는 데이터가 UIWebView 구성 요소의 HTML 출력을 렌더링하는 데 사용됩니다.
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 데이터베이스에서 읽어들이고 HTML로 인코딩하기 때문에 덜 위험한 것처럼 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 공격자가 제공하는 익스플로이트는 인코딩한 문자를 무시하거나 HTML 인코딩의 영향을 받지 않는 컨텍스트에 입력할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제 3: 다음 코드에서는 UITextField의 콘텐트를 읽고 이를 WKWebView 내에서 사용자에게 표시합니다.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
다음 예제의 코드는
inputTextField
내의 텍스트에 표준 영숫자 텍스트만 있으면 문제없이 작동합니다. inputTextField
내의 텍스트에 메타 문자나 소스 코드가 포함되어 있으면 웹 브라우저에서 HTTP 응답을 표시할 때 입력을 코드로 실행할 수 있습니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 하지만 자신의 장치에서 악의적인 코드가 실행되도록 할 수 있는 입력을 제공하는 이유가 있을까요? 정말 위험한 일은 공격자가 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 이러한 동작을 수행하도록 만드는 것입니다. 이러한 공격에 성공하면 피해자는 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 장치로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제에서처럼, XSS 취약점은 HTTP 콘텐트에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터는 사용자 지정 URL 스키마에서 직접 읽어 들여 UIWebView 응답의 콘텐트에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 iOS 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 사용자 지정 스키마 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 취약한 응용 프로그램을 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 앱이 공격자의 컨텐츠를 사용자에게 보내면, 컨텐츠가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.-
Example 3
에서는 대상 응용 프로그램 외부의 소스에서 대상 응용 프로그램의 사용자 지정 URL 스키마를 사용하여 URL 요청을 생성하고, 이어서 URL 요청의 확인되지 않은 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 다시 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] W/Labs Continued Adventures with iOS UIWebViews
[4] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, 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 Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.swift.cross_site_scripting_poor_validation
Abstract
사용자 입력을 검증하는 데 HTML, XML 및 기타 인코딩 유형을 사용하면 브라우저가 악성 코드를 실행하게 될 수 있습니다.
Explanation
특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 ASP 코드 세그먼트는 HTTP 요청에서 직원 ID 인
다음 예제의 코드는
처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 ASP 코드 세그먼트는 주어진 ID를 가진 직원을 데이터베이스에 쿼리하여 HTML 인코딩한 해당 직원의 이름을 인쇄합니다.
예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
-
- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.
2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.
웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.
예제 1: 다음 ASP 코드 세그먼트는 HTTP 요청에서 직원 ID 인
eid
를 읽고 HTML 인코딩하여 사용자에게 표시합니다.
...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
..
다음 예제의 코드는
eid
에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid
가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.
예제 2: 다음 ASP 코드 세그먼트는 주어진 ID를 가진 직원을 데이터베이스에 쿼리하여 HTML 인코딩한 해당 직원의 이름을 인쇄합니다.
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & Server.HTMLEncode(objADORecordSet("name"))
objADORecordSet.MoveNext
Wend
...
Example 1
에서처럼 이 코드는 name
의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name
의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name
의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.
-
Example 1
에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.-
Example 2
에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.vb.cross_site_scripting_poor_validation