계: Input Validation and Representation

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

Connection String Parameter Pollution

Abstract

확인되지 않은 입력을 데이터베이스 연결에 연결하면 공격자가 요청 매개 변수의 값을 오버라이드할 수 있습니다. 공격자는 기존 매개 변수 값을 오버라이드하거나, 새 매개 변수를 삽입하거나, 직접 연결로부터 변수를 익스플로이트할 수 있습니다.

Explanation

CSPP(Connection String Parameter Pollution) 공격은 연결 문자열 매개 변수를 다른 기존 매개 변수에 주입하는 공격으로 구성됩니다. 이 취약점은 매개 변수 감염도 발생할 수 있는 HTTP 환경 내의 다른 취약점과 비슷하며 아마 더 잘 알려져 있을 것입니다. 하지만 이는 데이터베이스 연결 문자열 같은 다른 위치에도 적용될 수 있습니다. 응용 프로그램이 사용자 입력을 제대로 정화하지 않으면 악의적인 사용자가 응용 프로그램의 로직을 침해한 후 자격 증명을 훔쳐 공격을 수행하거나 전체 데이터베이스를 검색할 수 있습니다. 추가 매개 변수를 응용 프로그램에 전송하고 이러한 매개 변수의 이름이 기존 매개 변수와 동일할 경우 데이터베이스 연결은 다음과 같은 반응 중 하나를 보일 수 있습니다.

첫 번째 매개 변수의 데이터만 받아들일 수 있습니다.
마지막 매개 변수의 데이터를 받아들일 수 있습니다.
모든 매개 변수의 데이터를 받아들이고 서로 연결할 수 있습니다.

이는 사용된 드라이버, 데이터베이스 유형 또는 API가 사용되는 방식에 따라서도 달라질 수 있습니다.

예제 1: 다음 코드는 HTTP 요청의 입력을 사용하여 데이터베이스에 연결합니다.


      ...
      string password = Request.Form["db_pass"]; //gets POST parameter 'db_pass'
      SqlConnection DBconn = new SqlConnection("Data Source = myDataSource; Initial Catalog = db; User ID = myUsername; Password = " + password + ";");
      ...

이 예제에서 프로그래머는 공격자가 다음과 같은 db_pass 매개 변수를 제공할 수 있다는 것을 고려하지 않았습니다.
"xxx; Integrated Security = true". 이 경우의 연결 문자열은 다음과 같습니다.

"Data Source = myDataSource; Initial Catalog = db; User ID = myUsername; Password = xxx; Integrated Security = true; "

그러면 응용 프로그램이 실행 중인 운영 체제 계정을 사용하여 데이터베이스에 연결하므로 정상 인증을 무시하게 됩니다. 즉, 공격자가 유효한 암호 없이도 데이터베이스에 연결하여 데이터베이스에 대해 직접 쿼리를 수행할 수 있게 됩니다.

References

[1] Chema Alonso, Manuel Fernandez, Alejandro Martin and Antonio Guzmán Connection String Parameter Pollution Attacks

[2] Eric P. Maurice A New Threat To Web Applications: Connection String Parameter Pollution (CSPP)

[3] Standards Mapping - Common Weakness Enumeration CWE ID 235

[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754

[5] Standards Mapping - FIPS200 SI

[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)

[10] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection

[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation

[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[28] 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

[29] 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

[30] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 020

[31] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807

[32] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807

[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I

[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I

[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I

[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I

[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I

[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[55] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)

desc.dataflow.dotnet.connection_string_parameter_pollution

Abstract

Explanation

CSPP(Connection String Parameter Pollution) 공격은 연결 문자열 매개 변수를 다른 기존 매개 변수에 삽입하는 공격으로 구성됩니다. 이 취약점은 매개 변수 감염도 발생할 수 있는 HTTP 환경 내의 다른 취약점과 비슷하며 아마 더 잘 알려져 있을 것입니다. 하지만 이는 데이터베이스 연결 문자열 같은 다른 위치에도 적용될 수 있습니다. 응용 프로그램이 사용자 입력을 제대로 정화하지 않으면 악의적인 사용자가 응용 프로그램의 로직을 침해한 후 자격 증명을 훔쳐 공격을 수행하거나 전체 데이터베이스를 검색할 수 있습니다. 이름이 기존 매개 변수와 동일한 추가 매개 변수를 응용 프로그램에 전송하면 데이터베이스는 다음과 같은 반응 중 하나를 보일 수 있습니다.

첫 번째 매개 변수의 데이터만 사용할 수 있습니다.
마지막 매개 변수의 데이터만 사용할 수 있습니다.
모든 매개 변수의 데이터를 사용하고 하나로 연결할 수 있습니다.

이는 사용된 드라이버, 데이터베이스 유형 또는 API가 사용되는 방식에 따라 달라질 수 있습니다.

예제 1: 다음 코드는 HTTP 요청의 입력을 사용하여 데이터베이스에 연결합니다.


    ...
    password := request.FormValue("db_pass")
    db, err := sql.Open("mysql", "user:" + password + "@/dbname")
    ...

이 예제에서 프로그래머는 공격자가 다음과 같은 db_pass 매개 변수를 제공할 수 있다는 것을 고려하지 않았습니다.
“xxx@/attackerdb?foo=”의 경우 연결 문자열은 다음과 같습니다.

"user:xxx@/attackerdb?foo=/dbname"

그러면 응용 프로그램이 공격자 컨트롤러 데이터베이스에 연결되어 응용 프로그램으로 반환되는 데이터가 제어될 수 있습니다.

References

[1] Chema Alonso, Manuel Fernandez, Alejandro Martin and Antonio Guzmán Connection String Parameter Pollution Attacks

[2] Standards Mapping - Common Weakness Enumeration CWE ID 235

[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754

[4] Standards Mapping - FIPS200 SI

[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)

[9] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection

[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation

[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[27] 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

[28] 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

[29] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 020

[30] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807

[31] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807

[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I

[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I

[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I

[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I

[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I

[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[54] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)

desc.dataflow.golang.connection_string_parameter_pollution

Abstract

확인되지 않은 입력을 데이터베이스 연결에 연결하면 공격자가 요청 매개 변수의 값을 오버라이드할 수 있습니다. 공격자는 기존 매개 변수 값을 오버라이드하거나, 새 매개 변수를 삽입하거나, 직접 연결의 변수를 악용할 수 있습니다.

Explanation

CSPP(Connection String Parameter Pollution) 공격은 연결 문자열 매개 변수를 다른 기존 매개 변수에 주입하는 공격으로 구성됩니다. 이 취약점은 매개 변수 감염도 발생할 수 있는 HTTP 환경 내의 다른 취약점과 비슷하며 아마 더 잘 알려져 있을 것입니다. 하지만 이는 데이터베이스 연결 문자열 같은 다른 위치에도 적용될 수 있습니다. 응용 프로그램이 사용자 입력을 제대로 정화하지 않으면 악의적인 사용자가 응용 프로그램의 로직을 침해한 후 자격 증명을 훔쳐 공격을 수행하거나 전체 데이터베이스를 검색할 수 있습니다. 추가 매개 변수를 응용 프로그램에 제출하고 이러한 매개 변수의 이름이 기존 매개 변수와 동일할 경우 데이터베이스 연결은 다음과 같은 반응 중 하나를 보일 수 있습니다.

첫 번째 매개 변수의 데이터만 사용할 수 있습니다.
마지막 매개 변수의 데이터만 사용할 수 있습니다.
모든 매개 변수의 데이터를 사용하고 하나로 연결할 수 있습니다.

이는 사용된 드라이버, 데이터베이스 유형 또는 API가 사용되는 방식에 따라 달라질 수 있습니다.

예제 1: 다음 코드는 HTTP 요청의 입력을 사용하여 데이터베이스에 연결합니다.


username = req.field('username')
password = req.field('password')
...
client = MongoClient('mongodb://%s:%s@aMongoDBInstance.com/?ssl=true' % (username, password))
...

이 예제에서 프로그래머는 공격자가 다음과 같은 password 매개 변수를 제공할 수 있다는 것을 고려하지 않았습니다.
"myPassword@aMongoDBInstance.com/?ssl=false&". 그러면 연결 문자열은 다음이 됩니다(사용자 이름을 "scott"으로 가정).

"mongodb://scott:myPassword@aMongoDBInstance.com/?ssl=false&@aMongoDBInstance.com/?ssl=true"

그러면 "@aMongoDBInstance.com/?ssl=true"가 잘못된 추가 인수로 처리되고 실질적으로 "ssl=true"가 무시되며 암호화가 없는 데이터베이스에 연결됩니다.