5.1 GlassFishに関するセキュリティ対策

セキュリティ侵害に対する対策は、一般的にはサービスだけでは対処できません。運用でも対処を行うことによって、安全性が強化されます。

■サーバー運用資産への不正アクセス

悪意のあるユーザーが、正当なアクセス権限をもつユーザーになりすまし、運用資産にアクセスする脅威があります。サーバーマシンは、不正なアクセスをされないように、セキュリティ的に守られた施設内で運用してください。

また、Webブラウザからアプリケーションにアクセスする際、ネットワーク上の悪意のあるユーザーが、正当なアクセス権限をもつユーザーになりすまし、サーブレットアプリケーションやHTMLファイルにアクセスする脅威があります。

サーバーの運用資産に対する不正なアクセスを防止するために、GlassFishには各種のセキュリティ機能があります。詳細は、本章の以降の節を参照してください。

■通信データの盗聴・改ざん

ネットワーク上の悪意のあるユーザーが、正当にアクセスする権限をもつユーザーとサーバーとの間の通信データをのぞき見する脅威があります。さらにサーバーとの間の通信データを改ざんされ、それが正当なデータとしてやりとりされる脅威があります。

通信データの盗聴・改ざんを防ぐためには、暗号化によるセキュリティ保護が必要です。暗号化通信として、GlassFishではSSL/TLS通信を使用することができます。

SSL通信で使用する暗号は、鍵長が十分に長く、安全なアルゴリズムのみを有効にしてください。

詳細は、「5.3 Jakarta EEアプリケーションのセキュリティ機能」を参照してください。

なお、性能を重視する場合やイントラネット内の通信に対する脅威を防止する場合はSSLアクセラレータの使用を検討してください。

■サービス停止・サービス拒否

ネットワーク上の悪意のあるユーザーが、標的とするサーバーに対して、大量のアクセスを発生させてサーバーの負荷を上げます。これによりレスポンスが悪くなりサービスの質が劣化する、または正規の利用者がサービスを利用できなくなってしまう脅威があります。

サービスへの攻撃に対しては、ユーザー認証、IPアクセス制限、SSL通信、サイズ制限の機能の利用をお勧めします。

なお、Webサーバー連携している場合は、Webサーバーで各種設定をすることができます。詳細は、「Interstage HTTP Server 2.4 運用ガイド」の「運用・保守」－「セキュリティ対策」を参照してください。

ユーザー認証: 登録したユーザーからのアクセスだけを許可するように設定することができます。詳細は、「5.3 Jakarta EEアプリケーションのセキュリティ機能」を参照してください。

IPアクセス制限: 特定のIPアドレスからのアクセスに対してのみ、リクエスト処理を実行させる設定をすることができます。設定の詳細は、「8.8.2 HTTPサービスの定義項目」の「要求を受け付けるIPアドレス」(allowRemoteAddress)を参照してください。

サイズ制限

バッファオーバフローに備えて、以下のような各種最大サイズを設定することができます。設定の詳細は、「8.8.3 ネットワーク設定の定義項目」を参照してください。

リクエストラインやヘッダ：受信バッファーサイズ(header-buffer-length-bytes)
POSTリクエストのBODY：POSTリクエストの最大サイズ(max-form-post-size-bytes)、リクエストBODYの最大サイズ(max-post-size-bytes)
リクエストのパラメータ数：HTTPリクエストパラメータ数の最大値(max-request-parameters)
ヘッダ数：リクエストヘッダ数の上限値(max-request-headers)、レスポンスヘッダ数の上限値(max-response-headers)

なお、アップロードするファイルの最大サイズは、アプリケーションで設定可能です。

■サーバー情報の漏洩

ネットワーク上の悪意のあるユーザーが、HTTPレスポンスヘッダのX-Powered-Byヘッダーフィールドに存在するサーバー情報を入手し、製品情報から不正アクセスを試みることが可能となる脅威があります。

GlassFishでは、X-Powered-Byヘッダーフィールドを付加しない設定で運用することを推奨します。設定の詳細は、「8.8.3 ネットワーク設定の定義項目」の「X-Powered-Byヘッダーフィールド」(xpowered-by)を参照してください。

■Webコンテナへアクセスする運用形態の設定

Webコンテナへのリクエストが運用形態に応じたものではない場合、セキュリティのリスクが発生することがあります。

例えば、Webサーバーでリクエストに対するチェックやフィルタリングを行っているときにWebコンテナに直接アクセスされた場合や、逆にWebサーバーを利用しない形態であるときにWebサーバー経由であるかのようにリクエストの情報を偽られる場合が考えられます。

本機能の設定を適切に行うことで、Webサーバーを経由する・しないの運用形態を限定することが可能です。

詳細は、「8.8.3 ネットワーク設定の定義項目」の「Webコンテナへアクセスする運用形態」(request-check)を参照してください。

■クロスサイト・スクリプティングによるセッションCookieの漏洩

クロスサイト・スクリプティングによりCookieが第三者に漏えいする脅威があります。

HttpOnly属性をCookieに付加すると、クライアントサイドスクリプトからCookieを取得できなくなります。このため、クロスサイト・スクリプティングの影響を軽減することができます。

GlassFishでは、CookieにHttpOnly属性を付加する運用を推奨します。なお、セッションCookieはデフォルトでHttpOnly属性を付加するようになっています。また、Servlet 3.0からセッションCookieにHttpOnly属性を付加できるようになっています。

■セッション情報の漏洩

セッション情報は、CookieまたはURLパラメタに埋め込まれます。WebサーバーとWebブラウザの間がインターネットの場合には、通信内容が傍受/改変される恐れがあります。そのため、重要なセッション情報をやり取りする場合には、SSL通信を使用することをお勧めします。

なお、サーブレットAPI のHttpServletResponse#encodeURL(java.lang.String)、encodeRedirectURL(java.lang.String)を使用すると、URLにセッションIDが含まれる場合があります。URLにセッションIDが含まれると、Cookieを利用することができないクライアントがセッションを継続することができます。ただし、URLにセッションIDが含まれる場合には、以下の脅威が存在します。

Webブラウザが表示中のWebページのURLを、Refererヘッダに含めて他のWebサイトに送ることにより、セッションIDが漏洩する

そのため、セッションの追跡には、ブラウザ等のクライアントがCookieを利用できない場合などを除き、セッションCookieを使用することをお勧めします。

なお、セッションCookieを利用する場合でも、初回リクエストで上記APIを使用すると、セッションIDにURLが埋め込まれてしまいます。これらのAPIが呼び出された際に、URLにセッションIDを含めないようにするためには、Servlet 3.0で導入された以下の方法を利用してください。

javax.servlet.ServletContext#setSessionTrackingModes(Set<SessionTrackingMode> sessionTrackingModes)で指定する。

例

セッションの追跡にセッションCookieのみを使用する場合のServletContextListener

public class MyServletContextListener implements ServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent event) {
        ServletContext sc = event.getServletContext();
        Set<SessionTrackingMode> set = new HashSet<SessionTrackingMode>();
        set.add(SessionTrackingMode.COOKIE);
        sc.setSessionTrackingModes(set);
    }

    @Override
    public void contextDestroyed(ServletContextEvent event) {
   }
}

web.xmlの<tracking-mode>にCOOKIEを指定する

例

セッションの追跡にセッションCookieのみを使用する場合のweb.xml

<?xml version="1.0" encoding="UTF-8" ?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
           http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
           version="3.0">
<session-config>
   <tracking-mode>COOKIE</tracking-mode>
</session-config>
</web-app>

注意

アプリケーションでHttpServletResponse#encodeURL(java.lang.String)、encodeRedirectURL(java.lang.String)を使用していない場合でも、JSFやその他のフレームワークが内部で使用する場合があります(JSFの場合は、これらのAPIが使用されることが規約に記載されています)。そのため、web.xmlでtracking-modeを指定することをお勧めします。
サーブレットAPIおよびweb.xmlの双方で指定した場合、サーブレットAPIで設定した値が優先されます。

■HTTP TRACEメソッド悪用による脅威

ネットワーク上の悪意のある人(またはマシン)が、HTTPリクエストデータ内に存在する個人情報を盗み見たり、任意のコードを実行したりする脅威があります。
このような脅威に備え、HTTP TRACEメソッドを無効にすることをお勧めします。

なお、TRACEメソッドは、ネットワーク上の診断を行うためなどに使用され、クライアント側から送出したデータをそのままレスポンスデータとして受信するHTTP/1.1のメソッドです。通常、使用されないため、無効にしても運用上の影響はありません。