계: Input Validation and Representation
입력 검증 및 표현 문제는 메타 문자, 대체 인코딩 및 숫자 표현 때문에 발생합니다. 보안 문제는 입력을 신뢰하기 때문에 발생합니다. 문제로는 "Buffer Overflows", "Cross-Site Scripting" 공격, "SQL Injection", 그 외 여러 가지가 있습니다.
SQL Injection: Persistence
Abstract
신뢰할 수 없는 소스에서 나온 입력을 받아 동적으로 SQL 문을 생성하면 공격자가 해당 문의 의미를 수정하거나 임의의 SQL 명령을 실행할 수 있습니다.
Explanation
SQL injection 오류는 다음 경우에 발생합니다.
1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.
이런 경우, Fortify Static Code Analyzer는 데이터 소스를 신뢰할 수 있는 것으로 판단하지 않습니다.
2. 데이터를 사용하여 SQL 쿼리를 동적으로 생성합니다.
예제 1: 다음 코드는 지정된 이름과 일치하는 항목을 검색하는 SQL 쿼리를 동적으로 생성하고 실행합니다. 쿼리는 표시되는 항목을 항목 소유자가 현재 인증된 사용자의 이름과 일치하는 항목으로 제한합니다.
쿼리는 다음 코드를 실행하려고 합니다.
하지만 상수인 기본 쿼리 문자열과 사용자 입력 문자열을 연결하여 쿼리를 동적으로 생성하기 때문에, 쿼리는
공격자는 이렇게 쿼리를 단순화하여 쿼리가 인증된 사용자가 소유한 항목만 반환해야 한다는 요구 사항을 무시할 수 있습니다. 이제 쿼리는 지정된 소유자와 관계없이
예제 2: 이 예제는
Microsoft(R) SQL Server 2000을 포함한 많은 데이터베이스 서버에서 여러 SQL 문을 세미콜론으로 구분하여 한꺼번에 실행하는 것을 허용합니다. 이 공격 문자열은 세미콜론으로 구분한 문에 대한 일괄 실행을 허용하지 않는 Oracle 및 기타 데이터베이스 서버에서는 오류를 일으키지만 일괄 실행을 허용하는 데이터베이스에서는 공격자가 이런 종류의 공격으로 데이터베이스에 대해 임의의 명령을 실행할 수 있습니다.
마지막의 하이픈 쌍(--)을 보겠습니다. 이는 대부분의 데이터베이스 서버에서 해당 문에 대한 나머지 부분을 주석으로 처리하여 실행하지 말라는 의미로 해석됩니다[4]. 이 경우, 이 주석 문자는 수정된 쿼리에서 마지막의 작은따옴표 한쪽을 제거하는 역할을 합니다. 주석을 이런 식으로 사용할 수 없는 데이터베이스에서도
모바일 환경에서는 SQL Injection과 같은 전형적인 웹 응용 프로그램 취약성이 발생하지 않는다고 생각하는 사용자도 있습니다. 자기 자신을 공격하는 사용자는 없을 것이라 여기기 때문입니다. 그러나 모바일 플랫폼의 핵심 요소는 다양한 소스에서 다운로드되어 같은 장치에서 함께 실행되는 응용 프로그램이라는 점을 유념해야 합니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 프로세스 간 통신을 포함하도록 모바일 응용 프로그램의 공격 표면을 확장해야 합니다.
예제 3: 다음 코드는
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. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.
이런 경우, Fortify Static Code Analyzer는 데이터 소스를 신뢰할 수 있는 것으로 판단하지 않습니다.
2. 데이터를 사용하여 SQL 쿼리를 동적으로 생성합니다.
예제 1: 다음 코드는 지정된 이름과 일치하는 항목을 검색하는 SQL 쿼리를 동적으로 생성하고 실행합니다. 쿼리는 표시되는 항목을 항목 소유자가 현재 인증된 사용자의 이름과 일치하는 항목으로 제한합니다.
...
String userName = ctx.getAuthenticatedUserName();
String itemName = request.getParameter("itemName");
String query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ itemName + "'";
ResultSet rs = stmt.execute(query);
...
쿼리는 다음 코드를 실행하려고 합니다.
SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;
하지만 상수인 기본 쿼리 문자열과 사용자 입력 문자열을 연결하여 쿼리를 동적으로 생성하기 때문에, 쿼리는
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과 같은 전형적인 웹 응용 프로그램 취약성이 발생하지 않는다고 생각하는 사용자도 있습니다. 자기 자신을 공격하는 사용자는 없을 것이라 여기기 때문입니다. 그러나 모바일 플랫폼의 핵심 요소는 다양한 소스에서 다운로드되어 같은 장치에서 함께 실행되는 응용 프로그램이라는 점을 유념해야 합니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 프로세스 간 통신을 포함하도록 모바일 응용 프로그램의 공격 표면을 확장해야 합니다.
예제 3: 다음 코드는
Example 1
을 Android 플랫폼에 맞게 조정합니다.
...
PasswordAuthentication pa = authenticator.getPasswordAuthentication();
String userName = pa.getUserName();
String itemName = this.getIntent().getExtras().getString("itemName");
String query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ itemName + "'";
SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
Cursor c = db.rawQuery(query, null);
...
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] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] IDS00-J. Prevent SQL Injection CERT
[6] INJECT-2: Avoid dynamic SQL Oracle
[7] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5.0
[8] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[9] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[10] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[11] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[12] Standards Mapping - CIS Kubernetes Benchmark partial
[13] Standards Mapping - Common Weakness Enumeration CWE ID 89
[14] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[15] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[17] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[18] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[19] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[20] Standards Mapping - FIPS200 SI
[21] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[22] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[23] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[24] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[25] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[26] Standards Mapping - OWASP Top 10 2010 A1 Injection
[27] Standards Mapping - OWASP Top 10 2013 A1 Injection
[28] Standards Mapping - OWASP Top 10 2017 A1 Injection
[29] Standards Mapping - OWASP Top 10 2021 A03 Injection
[30] 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)
[31] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[32] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[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.semantic.java.sql_injection_persistence