계: Input Validation and Representation

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

NoSQL Injection: MongoDB

Abstract

신뢰할 수 없는 소스에서 나온 입력을 사용하여 동적 MongoDB 쿼리를 생성하면 공격자가 해당 문의 의미를 수정할 수 있습니다.

Explanation

MongoDB의 NoSQL Injection 오류가 발생하는 경우는 다음과 같습니다.

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

2. 데이터를 사용하여 MongoDB 쿼리를 동적으로 생성합니다.

예제 1: 다음 코드는 특정 ID의 전자 메일을 검색하는 MongoDB 쿼리를 동적으로 생성하고 실행합니다.


...
    String userName = User.Identity.Name;
    String emailId = request["emailId"];
    var coll = mongoClient.GetDatabase("MyDB").GetCollection<BsonDocument>("emails");
    var docs = coll.Find(new BsonDocument("$where", "this.name == '" + name + "'")).ToList();
...

쿼리는 다음 코드를 실행하려고 합니다.


    this.owner == "<userName>" && this.emailId == "<emailId>"

하지만 상수 쿼리 문자열과 사용자 입력을 연결하여 쿼리를 동적으로 생성하기 때문에, 쿼리는 emailId에 작은따옴표가 들어 있지 않은 경우에만 정확하게 동작합니다. 사용자 이름이 wiley인 공격자가 emailId에 문자열 123' || '4' != '5를 입력하면 쿼리는 다음과 같이 생성됩니다.


    this.owner == 'wiley' && this.emailId == '123' || '4' != '5'

|| '4' != '5' 조건을 추가하면 where 절이 항상 true로 평가되므로 쿼리는 전자 메일 소유자와 관계없이 emails 컬렉션에 저장된 모든 항목을 반환합니다.

References

[1] Testing for NoSQL injection OWASP

[2] Standards Mapping - Common Weakness Enumeration CWE ID 89, CWE ID 943

[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089

[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089

[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089

[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089

[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089

[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [3] CWE ID 089

[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.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 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 Mobile Application Security Verification Standard 2.0 MASVS-CODE-4

[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws

[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws

[20] Standards Mapping - OWASP Top 10 2010 A1 Injection

[21] Standards Mapping - OWASP Top 10 2013 A1 Injection

[22] Standards Mapping - OWASP Top 10 2017 A1 Injection

[23] Standards Mapping - OWASP Top 10 2021 A03 Injection

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6

[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2

[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1

[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1

[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1

[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1

[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 089

[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089

[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089

[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II

[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I

[61] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)

[62] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection

desc.dataflow.dotnet.nosql_injection_mongodb

Abstract

신뢰할 수 없는 소스에서 나온 입력을 사용하여 동적 MongoDB 쿼리를 생성하면 공격자가 해당 문의 의미를 수정할 수 있습니다.

Explanation


...
    String userName = ctx.getAuthenticatedUserName();
    String emailId = request.getParameter("emailId")
    MongoCollection<Document> col = mongoClient.getDatabase("MyDB").getCollection("emails");
    BasicDBObject Query = new BasicDBObject();
    Query.put("$where", "this.owner == \"" + userName + "\" && this.emailId == \"" + emailId + "\"");
    FindIterable<Document> find= col.find(Query);
...

쿼리는 다음 코드를 실행하려고 합니다.


    this.owner == "<userName>" && this.emailId == "<emailId>"

하지만 상수인 기본 쿼리 문자열과 사용자 입력 문자열을 연결하여 쿼리를 동적으로 생성하기 때문에, 쿼리는 emailId에 큰따옴표가 들어 있지 않은 경우에만 정확하게 동작합니다. 사용자 이름이 wiley인 공격자가 emailId에 문자열 123" || "4" != "5를 입력하면 쿼리는 다음과 같이 생성됩니다.


    this.owner == "wiley" && this.emailId == "123" || "4" != "5"

|| "4" != "5" 조건을 추가하면 where 절이 항상 true로 평가되므로 쿼리는 전자 메일 소유자와 관계없이 emails 컬렉션에 저장된 모든 항목을 반환합니다.