界: Security Features

軟體安全性並非安全性軟體。我們關注驗證、Access Control、保密性、加密以及權限管理之類的主題。

Access Control: LDAP

Abstract

若沒有適當的 Access Control，執行包含使用者控制值的 LDAP 指令，可讓攻擊者查看未經授權的目錄。

Explanation

在以下情況會發生資料庫 Access Control 錯誤：

1. 資料從一個不可信賴的來源進入程式。

2. 資料用在 LDAP 查詢中指定資料值。
範例 1：目前已驗證的使用者的員工識別碼，會隨著每個用戶端介面的要求自動傳遞。以下的程式碼在使用員工名稱建立 LDAP 查詢之前，使用了允許清單適當地驗證此員工名稱。此驗證避免了 LDAP injection 弱點，但仍可能留下程式碼弱點。


static string AllowlistVerify(string name) {
    Regex pattern = new Regex(@"^[a-zA-Z\-\.']+$");
    if (pattern.IsMatch(name)) {
        return name;
    }
    return null;
}

...
string verifiedName = AllowlistVerify(managerName.Text.trim());
if(verifiedName != null) {
    DirectorySearcher src = new DirectorySearcher("(manager=" + verifiedName + ")");
    src.SearchRoot = de;
    src.SearchScope = SearchScope.Subtree;

    foreach(SearchResult res in src.FindAll()) {
        ...
    }
}

問題是開發人員未考慮到，如果攻擊者提供可替代 empName 的值，會發生什麼情況。儘管介面自動傳遞目前使用者的員工識別碼，但是攻擊者仍可能在惡意要求傳遞其他代替目前識別碼的值。因為此範例中的程式碼是在匿名連結下執行查詢，所以不管目前驗證的使用者身份如何，它都會將任何有效的員工識別碼傳回目錄項目中。

References

[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3

[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1

[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1

[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality

[5] Standards Mapping - CIS Kubernetes Benchmark complete

[6] Standards Mapping - Common Weakness Enumeration CWE ID 639

[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863

[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-001084, CCI-002165

[9] Standards Mapping - FIPS200 AC

[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation

[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)

[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement

[13] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control

[14] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference

[15] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References

[16] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References

[17] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control

[18] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control

[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.2 General Access Control Design (L1 L2 L3), 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3)

[20] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication

[21] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization

[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4

[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8

[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8

[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8

[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8

[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 5.4 - Authentication and Access Control

[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control

[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls

[34] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 863

[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3480.1 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3480.1 CAT I

[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3480.1 CAT I

[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3480.1 CAT I

[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3480.1 CAT I

[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3480.1 CAT I

[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3480.1 CAT I

[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001540 CAT I, APSC-DV-002360 CAT II

[56] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)

[57] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization

desc.dataflow.dotnet.access_control_ldap

Abstract

若沒有適當的 Access Control，執行包含使用者控制值的 LDAP 指令，可讓攻擊者查看未經授權的目錄。

Explanation

在以下情況會發生資料庫 Access Control 錯誤：

1. 資料從一個不可信賴的來源進入程式。

2. 資料用在 LDAP 查詢中指定資料值。
範例 1：以下程式碼在使用員工名稱建立 LDAP 查詢之前，使用了允許清單驗證從通訊端讀取的員工名稱。此驗證避免了 LDAP injection 弱點，但仍可能留下程式碼弱點。


char* allowlist_verify(char* name) {
    const char *error;
    int errOffset;
    char* regex = "^[a-zA-Z\\-\\.']+$";
    pcre* re = pcre_compile(regex, 0, &err, &errOffset, NULL);
    int rc = pcre_exec(re, NULL, name, strlen(name), 0, 0, NULL, 0);
    if (rc == 1)
        return name;
    return NULL;
}
...
fgets(managerName, sizeof(managerName), socket);
char* verified_name = allowlist_verify(managerName);
if(verified_name != NULL) {
    snprintf(filter, sizeof(filter), "(manager=%s)", verified_name);
    if ( ( rc = ldap_search_ext_s( ld, FIND_DN, LDAP_SCOPE_BASE,
            filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
            LDAP_NO_LIMIT, &result ) ) == LDAP_SUCCESS ) {
    ...
    }
}

問題是開發人員未考慮到，如果攻擊者提供可替代 username 的值，會發生什麼情況。因為此範例中的程式碼是在匿名連結下執行查詢，所以不管目前驗證的使用者身份如何，它都會將任何有效的員工識別碼傳回目錄項目中。