界: Security Features

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

HTTP Verb Tampering

C#/VB.NET/ASP.NET
Java/JSP

Abstract

指定 HTTP 動詞的安全限制通常可允許比預期更大量的存取。

Explanation

在下列情況下，可使用 HTTP 動詞竄改來略過應用程式的 Authentication 和授權機制：
1) 該應用程式使用列出 HTTP 動詞的安全性控制。
2) 安全性控制無法封鎖未列出的動詞。
3) 應用程式根據 GET 要求或其他任意 HTTP 動詞來更新其狀態。

以下組態將易受 HTTP 動詞篡改的攻擊：


    <authorization>
        <allow verbs="GET,POST" users="admin"/>
        <deny verbs="GET,POST"users="*" />
    </authorization>

依預設，.NET Framework 允許所有 HTTP 動詞，因此即使此配置拒絕讓所有使用者存取 GET 和 POST，仍無法防止 HEAD 要求。攻擊者也許可透過以 HEAD 要求替代 GET 或 POST 要求，來執行管理功能。換句話說，此程式碼將滿足上述的條件 1 和 2。接著若要讓 HEAD 請求執行管理功能，則應用程式須依據使用 POST 以外的動詞的要求，來執行指令。

就其核心而言，此弱點是嘗試建立拒絕清單 (指示使用者不可進行之事項的原則) 的結果。拒絕清單很少達成預期的效果。

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 288, CWE ID 302

[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287

[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287

[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287

[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287

[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287

[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [25] CWE ID 306

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

[9] Standards Mapping - FIPS200 CM

[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 API 2023 API5 Broken Function Level Authorization

[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)

[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls

[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration

[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management

[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration

[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration

[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration

[21] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10

[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10

[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10

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

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[47] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)

[48] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication

desc.config.dotnet.http_verb_tampering

Abstract

指定 HTTP 動詞的安全限制通常可允許比預期更大量的存取。

Explanation

在下列情況下，可使用 HTTP 動詞竄改來略過應用程式的 Authentication 和授權機制：
1) 該應用程式使用列出 HTTP 動詞的安全性控制。
2) 安全性控制無法封鎖未列出的動詞。
3) 應用程式根據 GET 要求或其他任意 HTTP 動詞來更新其狀態。

多數的 Java EE 執行允許組態中未明確列出的 HTTP 方法。例如，下列安全限制會套用至 HTTP GET 方法，但不會套用至其他 HTTP 動詞：


    <security-constraint>
        <display-name>Admin Constraint</display-name>
        <web-resource-collection>
            <web-resource-name>Admin Area</web-resource-name>
            <url-pattern>/pages/index.jsp</url-pattern>
            <url-pattern>/admin/*.do</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description>only admin</description>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>

由於此組態的 <http-method> 標籤中未明確定義如 HEAD 的動詞，因此可透過以 HEAD 要求替代 GET 或 POST 要求，來執行管理功能。為了能讓 HEAD 要求執行管理功能，條件 3 必須適用 - 應用程式必須依據 POST 以外的動詞執行指令。某些網路/應用程式伺服器會接受任意的非標準 HTTP 動詞，並以具有指定 GET 要求的型態回應。若情況為此，攻擊者將可使用要求中的任意動詞，來檢視管理頁面。

例如，典型的用戶端 GET 要求範例如下：


GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com

在 HTTP 動詞竄改攻擊中，攻擊者會以與 FOO 同類的要求替代 GET。


FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com

就其核心而言，此弱點是嘗試建立拒絕清單 (指示使用者不可進行之事項的原則) 的結果。拒絕清單很少達成預期的效果。