界: Security Features
ソフトウェアのセキュリティは、セキュリティ ソフトウェアではありません。ここでは、認証、アクセス制御、機密性、暗号化、権限管理などのトピックについて説明します。
HTTP Verb Tampering
Abstract
HTTP 動詞を指定するセキュリティ制約は通常、意図したよりも多くのアクセスを許可します。
Explanation
次の場合、アプリケーションの認証および承認メカニズムは、HTTP 動詞の改ざんによってバイパスできます。
1) HTTP 動詞を一覧表示するセキュリティ コントロールを使用する。
2) セキュリティ コントロールが、リストされていない動詞のブロックに失敗する。
3) アプリケーションが、GET リクエストまたはその他の任意の HTTP 動詞に基づいて状態を更新する。
次の設定は、HTTP 動詞の改ざんに対して脆弱です。
デフォルトではすべての HTTP 動詞を .NET フレームワークで使用できます。そのため、この設定で全ユーザーに対する GET および POST を拒否していても、HEAD リクエストは阻止できません。攻撃者は GET または POST リクエストを HEAD リクエストと置き換えることによって、管理者機能を実行できる可能性があります。つまり、このコードは前述の第 1 および第 2 の条件を満たしています。あと、HEAD リクエストが管理者機能を実行するのに必要なのは、アプリケーションが POST 以外の動詞を使用するリクエストに基づいてコマンドを実行することだけです。
基本的に、この脆弱性は、拒否リスト (ユーザーに許可しないことを指定するポリシー) を作成しようとした結果です。拒否リストが意図した効果を達成することはめったにありません。
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] Arshan Dabirsiaghi - Aspect Security Bypassing Web Authentication and Authorization with HTTP Verb Tampering
desc.config.dotnet.http_verb_tampering
Abstract
HTTP 動詞を指定するセキュリティ制約は通常、意図したよりも多くのアクセスを許可します。
Explanation
次の場合、アプリケーションの認証および承認メカニズムは、HTTP 動詞の改ざんによってバイパスできます。
1) HTTP 動詞を一覧表示するセキュリティ コントロールを使用する。
2) セキュリティ コントロールが、リストされていない動詞のブロックに失敗する。
3) アプリケーションが、GET リクエストまたはその他の任意の HTTP 動詞に基づいて状態を更新する。
ほとんどの Java EE 実装では、設定で明示的にリストされていない HTTP メソッドが許可されています。たとえば、次のセキュリティ制約は、HTTP GET メソッドに適用されますが、他の HTTP 動詞には適用されません。
HEAD のような動詞がこの設定の
たとえば、次に示すのは、典型的なクライアントの GET リクエストです。
HTTP 動詞改ざん攻撃では、攻撃者は GET を FOO のようなものに置き換えます
基本的に、この脆弱性は、拒否リスト (ユーザーに許可しないことを指定するポリシー) を作成しようとした結果です。拒否リストが意図した効果を達成することはめったにありません。
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
基本的に、この脆弱性は、拒否リスト (ユーザーに許可しないことを指定するポリシー) を作成しようとした結果です。拒否リストが意図した効果を達成することはめったにありません。
References
[1] Arshan Dabirsiaghi - Aspect Security Bypassing Web Authentication and Authorization with HTTP Verb Tampering
desc.config.java.http_verb_tampering