계: Input Validation and Representation
입력 검증 및 표현 문제는 메타 문자, 대체 인코딩 및 숫자 표현 때문에 발생합니다. 보안 문제는 입력을 신뢰하기 때문에 발생합니다. 문제로는 "Buffer Overflows", "Cross-Site Scripting" 공격, "SQL Injection", 그 외 여러 가지가 있습니다.
SQL Injection: iBatis Data Map
Abstract
신뢰할 수 없는 소스에서 나온 입력을 받아 동적으로 SQL 문을 생성하면 공격자가 해당 문의 의미를 수정하거나 임의의 SQL 명령을 실행할 수 있습니다.
Explanation
SQL Injection 오류는 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스의 데이터가 프로그램에 입력됩니다.
2. 데이터를 사용하여 SQL 쿼리를 동적으로 생성합니다.
iBatis Data Map을 사용하면 SQL 문에서 동적 매개변수를 지정할 수 있으며 일반적으로 iBatis Data Map은 다음과 같이
변수 이름 주위의
예제 1: 다음 코드는 지정한 이름과 일치하는 항목을 검색하기 위한 SQL 쿼리를 동적으로 생성하고 실행합니다. 쿼리는 표시되는 항목을 항목 소유자가 현재 인증된 사용자의 이름과 일치하는 항목으로 제한합니다.
하지만 상수인 기본 쿼리 문자열과 사용자 입력 문자열을 연결하여 쿼리를 동적으로 생성하기 때문에, 쿼리는
공격자는 이렇게 쿼리를 단순화하여 쿼리가 인증된 사용자가 소유한 항목만 반환해야 한다는 요구 사항을 무시할 수 있습니다. 이제 쿼리는 지정된 소유자와 관계없이
예제 2: 이 예제는
Microsoft(R) SQL Server 2000을 포함한 많은 데이터베이스 서버에서 여러 SQL 문을 세미콜론으로 구분하여 한꺼번에 실행하는 것을 허용합니다. 이 공격 문자열은 세미콜론으로 구분한 문에 대한 일괄 실행을 허용하지 않는 Oracle 및 기타 데이터베이스 서버에서는 오류를 일으키지만 일괄 실행을 허용하는 데이터베이스에서는 공격자가 이런 종류의 공격으로 데이터베이스에 대해 임의의 명령을 실행할 수 있습니다.
마지막의 하이픈 쌍(--)을 보겠습니다. 이는 대부분의 데이터베이스 서버에서 해당 문에 대한 나머지 부분을 주석으로 처리하여 실행하지 말라는 의미로 해석됩니다[4]. 이 경우, 이 주석 문자는 수정된 쿼리에서 마지막의 작은따옴표 한쪽을 제거하는 역할을 합니다. 주석을 이런 식으로 사용할 수 없는 데이터베이스에서도
SQL Injection 공격을 방지하는 한 가지 기존의 접근 방식은 공격을 입력값 검증 문제로 처리하고 안전한 값의 허용 목록의 문자만 받거나 악의적일 가능성이 있는 값 목록(거부 목록)을 식별하여 이스케이프 처리하는 것입니다. 허용 목록을 확인하는 것은 엄격한 입력값 검증 규칙을 이행하는 매우 효율적인 수단이 되기도 하지만, 매개 변수가 있는 SQL 문은 유지 관리가 쉽고 보다 강력한 보안을 제공할 수 있습니다. 대부분의 경우 거부 목록을 구현하는 것은 SQL Injection 공격 방지의 효과를 떨어뜨리는 허점이 아주 많습니다. 예를 들어, 공격자는 다음과 같이 할 수 있습니다.
- 따옴표로 묶지 않은 필드를 노립니다.
- 이스케이프 처리된 메타 문자를 사용할 필요가 없는 방법을 찾습니다.
- 저장 프로시저(Stored procedure)를 사용하여 삽입된 메타 문자를 숨깁니다.
SQL 쿼리에 입력할 때 수동으로 문자를 이스케이프 처리하는 방법도 있지만 이것으로 SQL Injection 공격으로부터 응용 프로그램을 보호할 수는 없습니다.
SQL Injection 공격을 다루는 데 주로 제시되는 다른 솔루션은 저장 프로시저(Stored procedure)를 사용하는 것입니다. 저장 프로시저(Stored procedure)는 일부 유형의 SQL injection 공격은 막을 수 있지만 다른 많은 유형은 막지 못합니다. 저장 프로시저(Stored procedure)는 일반적으로 매개 변수에 전달되는 SQL 문의 유형을 제한하여 SQL Injection 공격을 막습니다. 하지만 이 제약을 피할 수 있는 많은 방법이 있어 수많은 비정상적인 문을 저장 프로시저(Stored procedure)에 전달할 수 있습니다. 다시 말해, 저장 프로시저(Stored procedure)는 일부 익스플로이트는 막을 수 있지만 응용 프로그램을 SQL Injection 공격에 대해 안전하게 보호할 수는 없습니다.
1. 신뢰할 수 없는 소스의 데이터가 프로그램에 입력됩니다.
2. 데이터를 사용하여 SQL 쿼리를 동적으로 생성합니다.
iBatis Data Map을 사용하면 SQL 문에서 동적 매개변수를 지정할 수 있으며 일반적으로 iBatis Data Map은 다음과 같이
#
문자를 사용하여 정의됩니다.
<select id="getItems" parameterClass="MyClass" resultClass="items">
SELECT * FROM items WHERE owner = #userName#
</select>
변수 이름 주위의
#
문자는 iBatis가 userName
변수를 사용하여 매개 변수화된 쿼리를 만드는 것을 나타냅니다. 그뿐만 아니라 iBatis는 $
문자를 사용하여 변수를 SQL 문에 직접 연결하는 것도 허용함으로써 SQL Injection의 기회를 제공합니다.예제 1: 다음 코드는 지정한 이름과 일치하는 항목을 검색하기 위한 SQL 쿼리를 동적으로 생성하고 실행합니다. 쿼리는 표시되는 항목을 항목 소유자가 현재 인증된 사용자의 이름과 일치하는 항목으로 제한합니다.
<select id="getItems" parameterClass="MyClass" resultClass="items">
SELECT * FROM items WHERE owner = #userName# AND itemname = '$itemName$'
</select>
하지만 상수인 기본 쿼리 문자열과 사용자 입력 문자열을 연결하여 쿼리를 동적으로 생성하기 때문에, 쿼리는
itemName
에 작은따옴표가 들어 있지 않은 경우에만 정확하게 동작합니다. 사용자 이름이 wiley
인 공격자가 itemName
에 문자열 name' OR 'a'='a
를 입력하면 쿼리는 다음과 같이 생성됩니다.
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';
OR 'a'='a'
조건을 추가하면 where 절이 항상 true로 평가되기 때문에 쿼리는 훨씬 단순한 다음 쿼리와 논리적으로 동일하게 됩니다.
SELECT * FROM items;
공격자는 이렇게 쿼리를 단순화하여 쿼리가 인증된 사용자가 소유한 항목만 반환해야 한다는 요구 사항을 무시할 수 있습니다. 이제 쿼리는 지정된 소유자와 관계없이
items
테이블에 저장된 모든 항목을 반환합니다.예제 2: 이 예제는
Example 1
에서 생성하여 수행한 쿼리에 또 다른 악성 값이 전달될 때의 결과를 검토합니다. 사용자 이름이 wiley
인 공격자가 itemName
에 문자열 "name'; DELETE FROM items; --
"를 입력하면 쿼리는 다음과 같은 두 개의 쿼리가 됩니다.
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';
DELETE FROM items;
--'
Microsoft(R) SQL Server 2000을 포함한 많은 데이터베이스 서버에서 여러 SQL 문을 세미콜론으로 구분하여 한꺼번에 실행하는 것을 허용합니다. 이 공격 문자열은 세미콜론으로 구분한 문에 대한 일괄 실행을 허용하지 않는 Oracle 및 기타 데이터베이스 서버에서는 오류를 일으키지만 일괄 실행을 허용하는 데이터베이스에서는 공격자가 이런 종류의 공격으로 데이터베이스에 대해 임의의 명령을 실행할 수 있습니다.
마지막의 하이픈 쌍(--)을 보겠습니다. 이는 대부분의 데이터베이스 서버에서 해당 문에 대한 나머지 부분을 주석으로 처리하여 실행하지 말라는 의미로 해석됩니다[4]. 이 경우, 이 주석 문자는 수정된 쿼리에서 마지막의 작은따옴표 한쪽을 제거하는 역할을 합니다. 주석을 이런 식으로 사용할 수 없는 데이터베이스에서도
Example 1
에서 본 것과 유사한 속임수를 사용하면 대부분의 공격이 효과를 거둘 수 있습니다. 공격자가 문자열 "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a
"를 입력하여 다음 세 가지 유효한 문을 만드는 경우입니다.
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';
DELETE FROM items;
SELECT * FROM items WHERE 'a'='a';
SQL Injection 공격을 방지하는 한 가지 기존의 접근 방식은 공격을 입력값 검증 문제로 처리하고 안전한 값의 허용 목록의 문자만 받거나 악의적일 가능성이 있는 값 목록(거부 목록)을 식별하여 이스케이프 처리하는 것입니다. 허용 목록을 확인하는 것은 엄격한 입력값 검증 규칙을 이행하는 매우 효율적인 수단이 되기도 하지만, 매개 변수가 있는 SQL 문은 유지 관리가 쉽고 보다 강력한 보안을 제공할 수 있습니다. 대부분의 경우 거부 목록을 구현하는 것은 SQL Injection 공격 방지의 효과를 떨어뜨리는 허점이 아주 많습니다. 예를 들어, 공격자는 다음과 같이 할 수 있습니다.
- 따옴표로 묶지 않은 필드를 노립니다.
- 이스케이프 처리된 메타 문자를 사용할 필요가 없는 방법을 찾습니다.
- 저장 프로시저(Stored procedure)를 사용하여 삽입된 메타 문자를 숨깁니다.
SQL 쿼리에 입력할 때 수동으로 문자를 이스케이프 처리하는 방법도 있지만 이것으로 SQL Injection 공격으로부터 응용 프로그램을 보호할 수는 없습니다.
SQL Injection 공격을 다루는 데 주로 제시되는 다른 솔루션은 저장 프로시저(Stored procedure)를 사용하는 것입니다. 저장 프로시저(Stored procedure)는 일부 유형의 SQL injection 공격은 막을 수 있지만 다른 많은 유형은 막지 못합니다. 저장 프로시저(Stored procedure)는 일반적으로 매개 변수에 전달되는 SQL 문의 유형을 제한하여 SQL Injection 공격을 막습니다. 하지만 이 제약을 피할 수 있는 많은 방법이 있어 수많은 비정상적인 문을 저장 프로시저(Stored procedure)에 전달할 수 있습니다. 다시 말해, 저장 프로시저(Stored procedure)는 일부 익스플로이트는 막을 수 있지만 응용 프로그램을 SQL Injection 공격에 대해 안전하게 보호할 수는 없습니다.
References
[1] iBatis Working with Data Maps
[2] iBatis Data Mapper Developer Guide
[3] S. J. Friedl SQL Injection Attacks by Example
[4] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[5] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[6] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[7] IDS00-J. Prevent SQL Injection CERT
[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5.0
[9] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[10] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[11] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[12] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[13] Standards Mapping - CIS Kubernetes Benchmark partial
[14] Standards Mapping - Common Weakness Enumeration CWE ID 89
[15] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[17] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[18] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[19] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[20] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[21] Standards Mapping - FIPS200 SI
[22] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[23] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[24] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[25] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[26] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[27] Standards Mapping - OWASP Top 10 2010 A1 Injection
[28] Standards Mapping - OWASP Top 10 2013 A1 Injection
[29] Standards Mapping - OWASP Top 10 2017 A1 Injection
[30] Standards Mapping - OWASP Top 10 2021 A03 Injection
[31] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[32] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[42] 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
[43] 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
[44] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[45] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[46] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[47] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[68] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[69] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.config.java.sql_injection_ibatis_data_map