J2EE 標準は、より上位のプロトコルを利用できない場合、レガシシステムでの通信目的にのみ Use of Sockets を許可します。自身の通信プロトコルを認証するには、以下を含めて難しいセキュリティ上の課題に取り組む必要があります。

- 帯域内信号と帯域外信号

- プロトコルのバージョン間の互換性

- チャネルのセキュリティ

- エラーの取り扱い

- ネットワークの制約 (ファイアウォール)

- セッション管理

セキュリティ専門家による十分な監視が行わなければ、カスタム通信プロトコルはセキュリティ問題に悩まされる可能性が高くなります。

同様の多くの問題が標準プロトコルのカスタム実装に当てはまります。標準プロトコルの実装に関連したセキュリティ問題に取り組む多くのリソースがありますが、これらのリソースは攻撃者も利用できます。

Web アプリケーションのスレッド管理は J2EE 標準によって禁止されており、エラーが発生する可能性が常に高くなります。スレッドの管理は難しく、アプリケーションコンテナの動作に予測不能な方法で干渉する可能性が高いと言えます。コンテナに干渉しなくとも、スレッド管理は通常、デッドロック、Race Condition、その他の同期エラーなど、検出や診断が難しいバグにつながります。

ほとんどの Web アプリケーションは、セッション ID を使用してユーザーを一意に識別します。これは通常 cookie に保存され、サーバーと Web ブラウザー間で透過的に送信されます。


セッション ID を cookie に保存しないアプリケーションは、HTTP リクエスト パラメーターとして、または URL の一部としてセッション ID を送信することがあります。URL で指定されたセッション ID を受け入れると、攻撃者はセッション ID 固定化攻撃を実行しやすくなります。

URL にセッション ID を含めると、アプリケーションに対するセッション ハイジャック攻撃の成功率も高くなります。セッション ハイジャック攻撃は、攻撃者が被害者のアクティブなセッションまたはセッション ID を制御すると発生します。Web サーバー、アプリケーション サーバー、および Web プロキシが要求された URL を保存するのは一般的な動作です。セッション ID が URL に含まれている場合、それらはログにも記録されます。セッション ID が表示および保存される場所が増えると、攻撃者に侵害される可能性も高くなります。

Tomcat を使用して認証を実行している場合、Tomcat 配置ディスクリプタファイルで、認証に使用される「レルム (Realm)」が指定されます。次のようになります。

例 1:

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

この Realm タグでは、ログレベルを示す debug と呼ばれる属性をオプションで使用できます。数字が大きいほど、ログメッセージが詳細になります。デバッグレベルに非常に高い数字が設定されると、Tomcat ではログファイルにすべてのユーザー名とパスワードが平文で書き込まれます。Tomcat の JAASRealm に関連するデバッグメッセージの境界は 3 (3 以上は不適切、2 以下は適切) ですが、Tomcat で提供される他の種類のレルムでは、この境界が異なることがあります。

Struts や Spring などの Web フレームワークを使用して構築されたアプリケーションで Java Server Pages (JSP) に直接アクセスし、アクションまたはサーブレットを使用してリクエストを JSP に委任すると、未処理の例外やシステム情報の漏洩が発生する可能性があります。実装や設定が不十分なアプリケーション サーバーは、http://host/page.jsp%00 や http://host/page.js%2570 などの特別に細工されたリクエストを介して、ソース コードの詳細情報の漏洩に利用されてきました。さらに悪いことに、ユーザーによる任意のファイルのアップロードをアプリケーションが許可していると、攻撃者はこのメカニズムを使用して悪意のあるコードを JSP の形式でアップロードし、アップロードされたページに、悪意のあるコードをサーバー上で実行するように要求する可能性があります。

例 1: 次の例は、ロール名に "*" を含む JSP への直接アクセスを明示的に許可する、不十分な構成のセキュリティ制約を示しています。これは、対応する Web リソースへのアクセスをすべてのユーザーに許可することを示しています。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

セキュリティ ロールの重複には意味がありません。特定のセキュリティ ロールの最後の定義のみが適用されるためです。
例 1:web.xml ファイルのエントリは、2 つの admin ロールを定義します。

<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>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

サーブレット マッピングの重複には意味がありません。複数のサーブレット マッピングで同じ URL パターンが使用されていても、最後のエントリのみが適用されるためです。

例 1: 次の例では、2 つの異なるサーブレット マッピングで、URL パターン /servletA/* が使用されます。

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>

単一のサーブレットにマップされている複数の 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 エラー コードの処理は、優れたセキュリティ プラクティスであることに加えて、便利でユーザー フレンドリーです。また、適切な設定により、アプリケーションによってスローされる可能性のある例外をキャッチする、ラストチャンス エラー ハンドラーも定義されます。

アプリケーションが SSL を使用してクライアント ブラウザーとの機密通信を保証する場合、アプリケーション設定によって、SSL なしでアクセス制御されたページを表示できないようにする必要があります。

SSL がバイパスされる一般的な状況は 3 つあります。

- ユーザーが手動で URL を入力し、「HTTPS」ではなく「HTTP」と入力する。

- 攻撃者が意図的にユーザーを安全でない URL に送信する。

- プログラマがアプリケーション内のページへの相対リンクを誤って作成し、HTTP から HTTPS への切り替えに失敗する(これは、リンクが Web サイトのパブリック エリアとセキュリティで保護されたエリアの間を移動するときに、特に発生しがちです)。

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>