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

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

■サーバー資源への不正アクセス

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

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

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

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

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

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

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

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

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

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

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

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

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

IPアクセス制限: 特定のIPアドレスからのアクセスに対してのみ、リクエスト処理を実行させる設定をすることができます。設定の詳細は、「7.1.4 HTTPサービスの定義項目」－「仮想サーバー」のallowRemoteAddressプロパティを参照してください。

サイズ制限

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

リクエストラインやヘッダー：受信バッファーサイズ(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ヘッダーフィールドに存在するサーバー情報を入手し、製品情報から不正アクセスを試みることが可能となる脅威があります。

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

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

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

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

Launcherでは、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で導入された以下の方法を利用してください。

jakarta.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="https://jakarta.ee/xml/ns/jakartaee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
           web-app_5_0.xsd"
           version="5.0">
<session-config>
   <tracking-mode>COOKIE</tracking-mode>
</session-config>
</web-app>

注意

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

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

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

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