界: Security Features

ソフトウェアのセキュリティは、セキュリティソフトウェアではありません。ここでは、認証、アクセス制御、機密性、暗号化、権限管理などのトピックについて説明します。

HTTP Verb Tampering

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

Abstract

HTTP 動詞を指定するセキュリティ制約は通常、意図したよりも多くのアクセスを許可します。

Explanation

次の場合、アプリケーションの認証および承認メカニズムは、HTTP 動詞の改ざんによってバイパスできます。
1) HTTP 動詞を一覧表示するセキュリティコントロールを使用する。
2) セキュリティコントロールが、リストされていない動詞のブロックに失敗する。
3) アプリケーションが、GET リクエストまたはその他の任意の HTTP 動詞に基づいて状態を更新する。

次の設定は、HTTP 動詞の改ざんに対して脆弱です。


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

デフォルトではすべての HTTP 動詞を .NET フレームワークで使用できます。そのため、この設定で全ユーザーに対する GET および POST を拒否していても、HEAD リクエストは阻止できません。攻撃者は GET または POST リクエストを HEAD リクエストと置き換えることによって、管理者機能を実行できる可能性があります。つまり、このコードは前述の第 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 動詞の改ざんによってバイパスできます。
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>

HEAD のような動詞がこの設定の <http-method> タグで明示的に定義されていないため、GET または POST リクエストを HEAD リクエストに置き換えることで、管理機能を実行できてしまう場合があります。HEAD リクエストが管理機能を実行するには、条件 3 (アプリケーションは POST 以外の動詞に基づいてコマンドを実行する必要がある) が成立する必要があります。一部の Web サーバーまたはアプリケーションサーバーは、任意の非標準 HTTP 動詞を受け入れ、GET リクエストを受け取ったかのように応答します。こうなると、攻撃者が、リクエスト内の任意の動詞を使用して管理ページを表示できてしまいます。

たとえば、次に示すのは、典型的なクライアントの GET リクエストです。


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

HTTP 動詞改ざん攻撃では、攻撃者は GET を FOO のようなものに置き換えます


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

基本的に、この脆弱性は、拒否リスト (ユーザーに許可しないことを指定するポリシー) を作成しようとした結果です。拒否リストが意図した効果を達成することはめったにありません。