単一のサーブレットにマップされている複数の URL パターンは、サーブレットが実行する機能が多すぎることを示している場合があります。

例 1: 次の例では、5 つの URL パターンが 1 つのサーブレットにマップされています。

<servlet>
    <servlet-class>com.class.MyServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/myservlet</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/helloworld*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/servlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/mservlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

セッションを開いたままの時間が長いほど、攻撃者がユーザー アカウントを侵害するチャンスは増えます。セッションをアクティブなままにしておくと、攻撃者がユーザーのパスワードを総当たり攻撃で盗んだり、ユーザーのワイヤレス暗号鍵を解読したり、開いているブラウザーからセッションを乗っ取る可能性があります。セッション タイムアウトが長くなると、メモリが解放されなくなり、作成されるセッションが多くなりすぎて最終的に Denial of Service 攻撃が発生する可能性があります。

例 1: セッション タイムアウトがゼロまたはゼロ未満の場合、セッションは期限切れになりません。次の例は、セッション タイムアウトが -1 に設定されていることを示しています。これにより、セッションは無期限でアクティブのままになります。

<session-config>
    <session-timeout>-1</session-timeout>
</session-config>

<session-timeout> タグは、Web アプリケーションのすべてのセッションを対象とした、デフォルトのセッション タイムアウト間隔を定義します。<session-timeout> タグがない場合、デフォルトのタイムアウトの設定はコンテナーに任されます。

攻撃者が Web サイトの脆弱性を探す場合、サイトが提供する情報の量が、攻撃の試みが最終的に成功するか失敗するかを左右します。アプリケーションが攻撃者にスタックト レースを表示すると、攻撃者の仕事を大幅に容易にする情報が漏れてしまいます。たとえば、スタックト レースは、無効な形式の SQL クエリ文字列、使用されているデータベースのタイプ、およびアプリケーション コンテナーのバージョンを攻撃者に見せてしまう可能性があります。こうした情報を利用することで、攻撃者は、これらのコンポーネントの既知の脆弱性を標的にすることができます。

アプリケーションが攻撃者にエラー メッセージを漏らさないようにするために、アプリケーション設定ではデフォルトのエラー ページを指定する必要があります。標準の HTTP エラー コードの処理は、優れたセキュリティ プラクティスであることに加えて、便利でユーザー フレンドリーです。また、適切な設定により、アプリケーションによってスローされる可能性のある例外をキャッチする、ラストチャンス エラー ハンドラーも定義されます。

WebLogic デプロイメント ディスクリプターでは、少なくとも 24 バイトのセッション識別子の長さを指定する必要があります。セッション識別子を短くすると、アプリケーションがブルートフォース セッション推測攻撃を受けやすくなります。攻撃者が認証されたユーザーのセッション識別子を推測できる場合、そのユーザーのセッションを乗っ取ることができます。この説明の残りの部分では、24 バイトのセッション ID のバックオブエンベロープ正当化について詳しく説明します。

セッション ID は、62 文字の英数字の擬似乱数が選択されて構成されます。つまり、文字列が真にランダムな方法で構成されているとしたら、各バイトから最大 6 ビットのエントロピが生じることになります。

有効なセッション識別子を推測するために必要な秒数は、次の式で予測できます:

(2^B+1) / (2*A*S)

ここで:

- B は、セッション識別子のエントロピーのビット数です。

- A は、攻撃者が 1 秒間に試行する可能性のある推測の数です。

- S は、有効であり、いつでも推測できる、有効なセッション ID の数です。

セッション識別子のエントロピーのビット数は、常にセッション識別子の合計ビット数よりも少なくなります。たとえば、セッション ID が昇順で提供された場合、ID の長さに関係なく、セッション ID にはゼロ ビットに近いエントロピーがあります。セッション識別子が多くの乱数を使用して生成されていると仮定すると、セッション識別子のエントロピーのビット数は、セッション識別子の合計ビット数の半分であると推定されます。現実的な識別子の長さについて、これは可能ですが、おそらく楽観的です。

攻撃者が数百または数千のドローン コンピューターでボットネットを使用する場合、1 秒間に数万の推測を試みる可能性があると想定するのが妥当です。対象となる Web サイトが大規模で、人気がある場合、大量の推測がしばらくの間見過ごされる可能性があります。

推測が可能な、有効なセッション識別子の数の下限は、任意の時点でサイトでアクティブなユーザーの数です。ただし、ユーザーがログアウトせずにセッションを放棄した場合は、この数が増えます(これは、非アクティブなセッションのタイムアウトを短くする理由の 1 つです)。

64 ビットのセッション識別子を使用し、32 ビットのエントロピーを想定します。大規模な Web サイトの場合、攻撃者が 1 秒あたり 1,000 回の推測を試みる可能性があり、任意の時点で 10,000 個の有効なセッション識別子があると想定します。これらの想定では、攻撃者が有効なセッション識別子の推測に成功するまでの時間は 4 分未満と推測されます。

次に、64 ビットのエントロピーを提供する 128 ビットのセッション識別子を想定します。非常に大規模な Web サイトで、攻撃者が 1 秒あたり 10,000 回の推測を試みる可能性があり、100,000 個の有効なセッション識別子があると想定します。これらの想定では、攻撃者が有効なセッション識別子の推測に成功するまでの時間は 292 年を超えると推測されます。

ビットからバイトへと逆方向に作業すると、セッション識別子は 128/6 である必要があり、これにより約 21 バイトが生成されます。さらに、経験的テストでは、セッション識別子の最初の 3 バイトがランダムに生成されていないように見えることが示されています。つまり、目的の 64 ビットのエントロピーを実現するには、24 バイトの長さのセッション識別子を使用するように WebLogic を設定する必要があります。

サーブレット名が欠落または重複していると、web.xml はエラーになります。すべてのサーブレットには一意の名前 (servlet-name) と対応するマッピング (servlet-mapping) が必要です。

例 1:web.xml の次のエントリは、サーブレット定義のいくつかのエラーを示しています。

<!-- No <servlet-name> specified: -->
    <servlet>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Empty <servlet-name> node: -->
    <servlet>
        <servlet-name/>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Duplicate <servlet-name> nodes: -->
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-name>Servlet</servlet-name>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

これらのエラーにより、サーブレットに対する意図しないアクセス拒否が発生する可能性があります。

<login-config> 要素は、ユーザーがアプリケーションをどのように認証するかを設定するために使用されます。認証方法がないということは、誰もログインできないため、アプリケーションでは承認制約をどのように適用するかがわからないことを意味します。認証方法は、<auth-method> タグ (<login-config> の子) を使用して指定します。

認証方法は 4 種類あります。BASIC、FORM、DIGEST、および CLIENT_CERT。

BASIC は、HTTP 基本認証を示します。
FORM は、フォームベース認証を示します。
DIGEST は BASIC 認証に似ていますが、DIGEST ではパスワードが暗号化されます。
CLIENT_CERT は、クライアントが公開鍵証明書を持ち、SSL/TLS を使用することを求めます。

例 1: 次の設定は、ログイン設定を指定していません。

<web-app>

    <!-- servlet declarations -->
    <servlet>...</servlet>

    <!-- servlet mappings-->
    <servlet-mapping>...</servlet-mapping>

    <!-- security-constraints-->
    <security-constraint>...</security-constraint>

    <!-- login-config goes here -->

    <!-- security-roles -->
    <security-role>...</security-role>

</web-app>

web.xml のセキュリティ制約は通常、ロール ベースのアクセス制御に使用されますが、オプションの user-data-constraint 要素は、安全でない方法でコンテンツが送信されないようにするトランスポート保証を指定します。

<user-data-constraint> タグ内で、<transport-guarantee> タグは通信の処理方法を定義します。トランスポート保証には 3 つのレベルがあります。

1) NONE は、アプリケーションがトランスポート保証を必要としないことを意味します。
2) INTEGRAL は、クライアントとサーバー間で送信されるデータが、転送中に変更されないように送信されることをアプリケーションが要求することを意味します。
3) CONFIDENTIAL は、他のエンティティが送信の内容を監視できないような方法でデータを送信することをアプリケーションが要求することを意味します。



ほとんどの場合、INTEGRAL または CONFIDENTIAL を使用することは、SSL/TLS が必要であることを意味します。<user-data-constraint> と<transport-guarantee> タグが省略されると、トランスポート保証は NONE にデフォルト設定されます。

例 1: 次のセキュリティ制約は、トランスポート保証を指定していません。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Storefront</web-resource-name>
        <description>Allow Customers and Employees access to online store front</description>
        <url-pattern>/store/shop/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Anyone</description>
        <role-name>anyone</role-name>
    </auth-constraint>
</security-constraint>

攻撃者が Web サイトの脆弱性を探す場合、サイトが提供する情報の量が、攻撃の試みが最終的に成功するか失敗するかを左右します。アプリケーションが攻撃者にスタックト レースを表示すると、攻撃者の仕事を大幅に容易にする情報が漏れてしまいます。たとえば、スタックト レースは、無効な形式の SQL クエリ文字列、使用されているデータベースのタイプ、およびアプリケーション コンテナーのバージョンを攻撃者に見せてしまう可能性があります。こうした情報を利用することで、攻撃者は、これらのコンポーネントの既知の脆弱性を標的にすることができます。

アプリケーションが攻撃者にエラー メッセージを漏らさないようにするために、アプリケーション設定ではデフォルトのエラー ページを指定する必要があります。標準の HTTP エラー コードの処理は、優れたセキュリティ プラクティスであることに加えて、便利でユーザー フレンドリーです。また、適切な設定により、アプリケーションによってスローされる可能性のある例外をキャッチする、ラストチャンス エラー ハンドラーも定義されます。

フィルター マッピングを適用するには、各フィルター マッピングが有効なフィルター定義に対応している必要があります。

例 1: 次の例は、存在しないフィルター AuthenticationFilter を参照するフィルター マッピングを示しています。定義がないため、フィルター AuthenticationFilter は指定した URL パターン /secure/* に適用されず、その結果、ランタイム例外が発生する可能性があります。

<filter>
    <description>Compresses images to 64x64</description>
    <filter-name>ImageFilter</filter-name>
    <filter-class>com.ImageFilter</filter-class>
</filter>

<!-- AuthenticationFilter is not defined -->
<filter-mapping>
    <filter-name>AuthenticationFilter</filter-name>
    <url-pattern>/secure/*</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>ImageFilter</filter-name>
    <servlet-name>ImageServlet</servlet-name>
</filter-mapping>

auth-constraint で定義されている role-name に security-role がないときは、設定が古い場合があります。

例 1: 次の例は、role-name を指定していますが、security-role で定義していません。

<security-constraint>
    <web-resource-collection>
         <web-resource-name>AdminPage</web-resource-name>
         <description>Admin only pages</description>
         <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>

    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>

    <user-data-constraint>
        <transport-guarantee>INTEGRAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

有効なサーブレット マッピングがないと、マッピングされていないサーブレットへのアクセスはすべて阻止されます。

例 1:web.xml の次のエントリは ExampleServlet を定義しますが、対応するサーブレット マッピングを定義できません。

<web-app
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

    <servlet>
      <servlet-name>ExampleServlet</servlet-name>
      <servlet-class>com.class.ExampleServlet</servlet-class>
      <load-on-startup>1</load-on-startup>
    </servlet>

</web-app>

リモート インターフェイスを公開するエンティティ Bean は、アプリケーションの攻撃対象領域の一部になります。パフォーマンス上の理由から、アプリケーションがリモート エンティティ Bean を使用することは稀です。そのため、リモート エンティティ Bean の宣言がエラーである可能性が高くなります。

例 1: 次のエンティティ Bean 宣言には、リモート インターフェイスが含まれています。

<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>EmployeeRecord</ejb-name>
<home>com.wombat.empl.EmployeeRecordHome</home>
<remote>com.wombat.empl.EmployeeRecord</remote>
...
</entity>
...
</enterprise-beans>
</ejb-jar>

EJB デプロイメント ディスクリプターに、特別な ANYONE ロールへのアクセスを許可する 1 つ以上のメソッド権限が含まれている場合は、アプリケーションのアクセス制御が十分に検討されていないか、合理的なアクセス制御制限ができない方法でアプリケーションが設定されています。

例 1: 次のデプロイメント ディスクリプターは、ANYONE 権限 (Employee EJB の getSalary() メソッドを呼び出す) を付与します。

<ejb-jar>
	...
	<assembly-descriptor>
		<method-permission>
			<role-name>ANYONE</role-name>
			<method>
				<ejb-name>Employee</ejb-name>
				<method-name>getSalary</method-name>
		</method-permission>
	</assembly-descriptor>
	...
</ejb-jar>

Kubernetes API サーバーは、リクエストが他の設定された認証方法によって拒否されない場合、デフォルトで匿名リクエストを受け入れます。API サーバーはクラスターの中央管理エンティティであるため、攻撃者は匿名リクエストを使用して、保護が不十分でセキュリティが重要なサービス API にアクセスできます。

例 1: 次の設定では、Kubernetes API サーバーを起動し、--anonymous-auth=true フラグを設定することで匿名リクエストを許可します。

...
spec:
  containers:
    - command:
      - kube-apiserver
...
      - --anonymous-auth=true
...

Kubernetes API サーバーは、デフォルトで監査イベントを標準出力に書き込みます。監査イベントは永続ストレージに記録される必要があります。監査イベントには、セキュリティ インシデントの特定、ポリシー違反の監視、および否認防止の制御を支援するために使用される、貴重なデータが含まれています。

例 1: 次の設定では、--audit-log-path フラグなしで Kubernetes API サーバーを起動します。

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=RBAC
  image: example.domain/kube-apiserver-amd64:v1.6.0
...

クラスターの中央管理エンティティである Kubernetes API サーバーは、HTTP 基本認証を受け入れてユーザーを認証します。HTTP 基本認証は非推奨であり、ブルートフォース攻撃の影響を受けやすく、誤って設定された環境では攻撃者にユーザー資格情報を漏らす可能性があります。

例 1: 次の設定では、Kubernetes API サーバーを起動し、--basic-auth-file=<filename>> フラグを HTTP 基本認証を使用するように設定します。

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-apiserver
      - --basic-auth-file=<filename>
    image: example.domain/kube-apiserver-amd64:v1.6.0
    livenessProbe:
...

アクセス設定が緩いと、システムが公開され、組織の攻撃対象領域が広がる可能性があります。一般に公開されているサービスは、通常、悪意のあるエンティティによるほぼ継続的なスキャンとプロービングの対象になります。

これは、公開されたサービスのゼロデイ エクスプロイトが発見され、公表された場合 (Heartbleed など) に、特に問題になります。攻撃者は、パッチが適用されていない、公開されたシステムを積極的に追跡、検索して、それを悪用できます。

重要なリソースまたは機密リソースへの制御されていないアクセスは、重要なデータの開示や改ざんなど、さまざまな方法で組織に重大な影響を与える可能性があります。

重要なリソースまたは機密リソースへの制御されていないアクセスは、重要なデータの開示や改ざんなど、さまざまな方法で組織に重大な影響を与える可能性があります。

重要なリソースまたは機密リソースへの制御されていないアクセスは、重要なデータの開示や改ざんなど、さまざまな方法で組織に重大な影響を与える可能性があります。