Apache Tomcat 11

JMX接続のセキュリティは、JREが提供する実装に依存するため、Tomcatの制御範囲外です。

通常、アクセス制御は非常に限られています（すべて読み取り専用か、すべて読み書き可能か）。Tomcatは、デバッグ、監視、管理を支援するために、JMXを介して大量の内部情報と制御を公開しています。利用可能なアクセス制御が限られていることを考えると、JMXアクセスはローカルのroot/管理者アクセスと同等に扱い、それに応じて制限すべきです。

ほとんど（すべて？）のJREベンダーが提供するJMXアクセス制御は、認証失敗の試行をログに記録せず、また、繰り返し認証に失敗した場合のアカウントロックアウト機能も提供しません。これにより、ブルートフォース攻撃を容易に仕掛けられ、検出が困難になります。

上記のすべてを考慮すると、JMXインターフェースを使用する場合は、適切に保護されていることを確認するために注意を払う必要があります。JMXインターフェースを保護するために検討すべきオプションは以下の通りです。

• すべてのJMXユーザーに強力なパスワードを設定する;
• JMXリスナーを内部ネットワークのみにバインドする;
• JMXポートへのネットワークアクセスを信頼できるクライアントに制限する; そして
• 外部監視システムが使用するためのアプリケーション固有のヘルスぺージを提供する。

Tomcatには、デフォルトで有効になっているいくつかのWebアプリケーションが同梱されています。過去にはこれらのアプリケーションで脆弱性が発見されています。不要なアプリケーションは削除し、別の脆弱性が発見された場合でもシステムが危険にさらされないようにすべきです。

ROOT Webアプリケーションはセキュリティリスクが非常に低いですが、使用されているTomcatのバージョンが含まれています。ROOT Webアプリケーションは、セキュリティ上の理由からではなく、ユーザーにより適切なデフォルトページを表示するために、通常は公開されているTomcatインスタンスから削除されるべきです。

ドキュメンテーションWebアプリケーションはセキュリティリスクが非常に低いですが、使用されているTomcatのバージョンを特定します。通常、公開されているTomcatインスタンスから削除されるべきです。

サンプルWebアプリケーションは、セキュリティ上重要なインストールからは常に削除されるべきです。サンプルWebアプリケーションには既知の脆弱性は含まれていませんが、攻撃者がTomcatインスタンスにデプロイされた別のアプリケーションの脆弱性と組み合わせて、通常は利用できない追加情報を取得するために使用できる機能（特に、受信したすべてのクッキーの内容を表示し、新しいクッキーを設定できるクッキーの例）が含まれていることが知られています。

マネージャーアプリケーションはWebアプリケーションのリモートデプロイを可能にし、脆弱なパスワードの広範な使用と、マネージャーアプリケーションが有効になっている公開されたTomcatインスタンスのために、攻撃者によって頻繁に標的とされます。マネージャーアプリケーションは、必要なアクセス権を持つユーザーが設定されていないため、デフォルトではアクセスできません。マネージャーアプリケーションが有効になっている場合は、管理アプリケーションの保護セクションのガイダンスに従うべきです。

ホストマネージャーアプリケーションは、仮想ホストの作成と管理を可能にします。これには、仮想ホストに対してマネージャーアプリケーションを有効にすることも含まれます。ホストマネージャーアプリケーションは、必要なアクセス権を持つユーザーが設定されていないため、デフォルトではアクセスできません。ホストマネージャーアプリケーションが有効になっている場合は、管理アプリケーションの保護セクションのガイダンスに従うべきです。

Tomcatインスタンスの管理機能を提供するWebアプリケーションをデプロイする際には、以下のガイドラインに従うべきです。

• 管理アプリケーションへのアクセスを許可されたすべてのユーザーが強力なパスワードを持っていることを確認してください。
• ユーザーパスワードに対するブルートフォース攻撃を防ぐLockOutRealmの使用を削除しないでください。
• 管理アプリケーションのcontext.xmlファイルでRemoteAddrValveを設定してください。これはデフォルトでlocalhostへのアクセスを制限します。リモートアクセスが必要な場合は、このバルブを使用して特定のIPアドレスに制限してください。

デフォルトのserver.xmlには、コメントアウトされたコンポーネント定義の例を含む、多数のコメントが含まれています。これらのコメントを削除すると、server.xmlを読み書きしやすくなります。

コンポーネントタイプがリストされていない場合、そのタイプにはセキュリティに直接影響する設定はありません。

port属性を-1に設定すると、シャットダウンポートが無効になります。

シャットダウンポートが無効でない場合、shutdownに強力なパスワードを設定すべきです。

APRライフサイクルリスナーは、Solaris上でgccを使用してコンパイルした場合、安定していません。Solaris上でAPR/ネイティブコネクタを使用する場合は、Sun Studioコンパイラでコンパイルしてください。

JNIライブラリロードリスナーはネイティブコードをロードするために使用できます。信頼できるライブラリのロードにのみ使用すべきです。

セキュリティライフサイクルリスナーは有効にし、適切に設定すべきです。

デフォルトでは、非TLSのHTTP/1.1コネクタがポート8080で設定されています。使用しないコネクタはserver.xmlから削除すべきです。

AJPはクリアテキストプロトコルです。AJPコネクタは通常、信頼されたネットワークでのみ使用すべきです。信頼されていないネットワークで使用する場合、secret属性を使用すると承認されたクライアントへのアクセスは制限されますが、ネットワークトラフィックを監視できる者にはsecret属性が見えてしまいます。

AJPコネクタは、不明なリクエスト属性を持つ転送されたリクエストをブロックします。既知の安全な属性や予期される属性は、allowedRequestAttributesPattern属性に適切な正規表現を設定することで許可できます。

address属性は、コネクタが接続をリッスンするIPアドレスを制御するために使用できます。デフォルトでは、コネクタは設定されているすべてのIPアドレスでリッスンします。

allowBackslash属性は、リクエストURIの非標準的なパースを許可します。この属性をデフォルト以外の値に設定すると、リバースプロキシの背後にある場合に、攻撃者がプロキシによって強制されるセキュリティ制約をバイパスできる可能性があります。

allowTrace属性は、デバッグに役立つTRACEリクエストを有効にするために使用できます。一部のブラウザがTRACEリクエストからの応答を処理する方法（これによりブラウザがXSS攻撃にさらされる）により、TRACEリクエストのサポートはデフォルトで無効になっています。

discardFacades属性をtrueに設定すると、各リクエストごとに新しいファサードオブジェクトが作成されます。これはデフォルト値であり、これによりアプリケーションのバグが一方のリクエストのデータを他方に公開する可能性が低減されます。

encodedSolidusHandling属性は、リクエストURIの非標準的なパースを許可します。この属性をデフォルト以外の値に設定すると、リバースプロキシの背後にある場合に、攻撃者がプロキシによって強制されるセキュリティ制約をバイパスできる可能性があります。

enforceEncodingInGetWriter属性は、falseに設定するとセキュリティ上の影響があります。多くのユーザーエージェントは、RFC 7230に違反して、仕様で規定されているデフォルトのISO-8859-1を使用すべきテキストメディアタイプの文字エンコーディングを推測しようとします。一部のブラウザは、ISO-8859-1では安全な文字を含む応答をUTF-7として解釈し、UTF-7として解釈された場合にXSS脆弱性を引き起こす可能性があります。

maxPostSize属性は、パラメータのためにパースされるPOSTリクエストの最大サイズを制御します。パラメータはリクエストの間キャッシュされるため、DoS攻撃への露出を減らすためにデフォルトで2 MiBに制限されています。

maxSavePostSize属性は、FORMおよびCLIENT-CERT認証、ならびにHTTP/1.1アップグレード中のリクエストボディの保存を制御します。FORM認証の場合、リクエストボディは認証の間HTTPセッションにキャッシュされるため、DoS攻撃への露出を減らすためにデフォルトでキャッシュされたリクエストボディは4 KiBに制限されています。FORM認証の許可された期間を制限することでDoS攻撃への露出をさらに減らすために、セッションがFORM認証によって作成された場合、短縮されたセッションタイムアウトが使用されます。この短縮されたタイムアウトは、FORM認証器のauthenticationSessionTimeout属性によって制御されます。

maxParameterCount属性は、クエリ文字列から取得されるリクエストパラメータ（アップロードされたファイルを含む）の最大総数を制御します。POSTリクエストの場合、コンテンツタイプがapplication/x-www-form-urlencodedまたはmultipart/form-dataであれば、リクエストボディも含まれます。過剰なパラメータを持つリクエストは拒否されます。

xpoweredBy属性は、X-Powered-By HTTPヘッダーが各リクエストと共に送信されるかどうかを制御します。送信される場合、ヘッダーの値には、サーブレットとJSPの仕様バージョン、完全なTomcatバージョン（例：Apache Tomcat/11.0）、JVMベンダー名、およびJVMのバージョンが含まれます。このヘッダーはデフォルトで無効になっています。このヘッダーは、正当なクライアントと攻撃者の両方に有用な情報を提供できます。

server属性は、Server HTTPヘッダーの値を制御します。Tomcat 4.1.xから8.0.xまでのこのヘッダーのデフォルト値はApache-Coyote/1.1です。8.5.x以降、このヘッダーはデフォルトでは設定されません。このヘッダーは、正当なクライアントと攻撃者の両方に限定的な情報を提供できます。

SSLEnabled、scheme、およびsecure属性はすべて個別に設定できます。これらは通常、Tomcatがリバースプロキシの背後に配置されており、プロキシがHTTPまたはHTTPS経由でTomcatに接続している場合に使用されます。これにより、TomcatはプロキシとTomcat間の接続ではなく、クライアントとプロキシ間の接続のSSL属性を見ることができます。例えば、クライアントはHTTPS経由でプロキシに接続するかもしれませんが、プロキシはHTTPを使用してTomcatに接続します。Tomcatがプロキシによって受信された安全な接続と非安全な接続を区別できる必要がある場合、プロキシは安全なリクエストと非安全なリクエストをTomcatに渡すために別々のコネクタを使用する必要があります。プロキシがAJPを使用する場合、クライアント接続のSSL属性はAJPプロトコルを介して渡されるため、別々のコネクタは必要ありません。

tomcatAuthenticationおよびtomcatAuthorization属性は、AJPコネクタと共に使用され、Tomcatがすべての認証と認可を処理すべきか、それとも認証をリバースプロキシに委任すべきか（認証されたユーザー名はAJPプロトコルの一部としてTomcatに渡される）を決定します。その際、Tomcatが認可を引き続き実行するオプションも提供されます。

AJPコネクタのrequiredSecret属性は、TomcatとTomcatの前のリバースプロキシとの間で共有シークレットを設定します。これは、AJPプロトコルを介した不正な接続を防ぐために使用されます。

host要素はデプロイメントを制御します。自動デプロイメントは管理を簡素化しますが、攻撃者が悪意のあるアプリケーションをデプロイすることも容易にします。自動デプロイメントはautoDeployとdeployOnStartup属性によって制御されます。両方がfalseの場合、server.xmlで定義されたContextsのみがデプロイされ、変更にはTomcatの再起動が必要です。

Webアプリケーションが信頼できないホスト環境では、Webアプリケーションに特権を付与しようとする可能性がある、Webアプリケーションにバンドルされたcontext.xmlを無視するために、deployXML属性をfalseに設定してください。セキュリティマネージャーが有効な場合、deployXML属性はデフォルトでfalseになることに注意してください。

これは、Context要素が定義できるすべての場所に適用されます: server.xmlファイル、デフォルトのcontext.xmlファイル、ホストごとのcontext.xml.defaultファイル、ホストごとの設定ディレクトリ内またはWebアプリケーション内のWebアプリケーションコンテキストファイル。

crossContext属性は、あるコンテキストが別のコンテキストのリソースにアクセスできるかどうかを制御します。デフォルトではfalseであり、信頼できるWebアプリケーションの場合にのみ変更すべきです。

privileged属性は、コンテキストがManagerサーブレットなどのコンテナ提供のサーブレットを使用できるかどうかを制御します。デフォルトではfalseであり、信頼できるWebアプリケーションの場合にのみ変更すべきです。

ネストされたResources要素のallowLinking属性は、コンテキストがリンクされたファイルを使用できるかどうかを制御します。有効にしてコンテキストがアンデプロイされると、コンテキストリソースの削除時にリンクが辿られます。大文字小文字を区別しないオペレーティングシステム（Windowsを含む）でこの設定をデフォルトのfalseから変更すると、多数のセキュリティ対策が無効になり、特にWEB-INFディレクトリへの直接アクセスが許可される可能性があります。

sessionCookiePathUsesTrailingSlashは、アプリケーションが共通のパスプレフィックスを共有する場合に、セッションクッキーがアプリケーション間で露出するのを防ぐために、一部のブラウザ（Internet Explorer、Safari、Edge）のバグを回避するために使用できます。ただし、このオプションを有効にすると、/*にマッピングされたサーブレットを持つアプリケーションに問題が発生する可能性があります。また、RFC6265セクション8.5では、異なるパスが他のアプリケーションからクッキーを隔離するのに十分であると見なすべきではないことが明確に述べられています。

antiResourceLockingが有効な場合、Tomcatは展開されたWebアプリケーションをjava.io.tmpdirシステムプロパティ（デフォルトでは$CATALINA_BASE/temp）で定義されたディレクトリにコピーします。この場所は、適切なファイルパーミッションで保護されるべきです。通常、Tomcatユーザーには読み書き権限を、他のユーザーにはアクセス権を与えないようにします。

mapperContextRootRedirectEnabledおよび/またはmapperDirectoryRedirectEnabledが有効な場合、リクエスト処理はより効率的になりますが、セキュリティ上の副作用があります。第一に、ユーザーがそのディレクトリにアクセスできない場合でも、Webアプリケーションやディレクトリの存在が確認される可能性があります。第二に、セキュリティ機能を提供するものを含む、すべてのバルブおよび/またはフィルターは、リクエストを処理する機会がなくなります。

AccessLogValveを設定することを強く推奨します。デフォルトのTomcat設定にはAccessLogValveが含まれています。これらは通常ホストごとに設定されますが、必要に応じてエンジンごとまたはコンテキストごとに設定することもできます。

すべての管理アプリケーションはRemoteAddrValve（このバルブはフィルターとしても利用可能）によって保護されるべきです。allow属性を使用して、既知の信頼されたホストのセットへのアクセスを制限すべきです。

デフォルトのErrorReportValveは、クライアントに送信される応答にTomcatのバージョン番号を含めます。これを避けるには、各Webアプリケーション内でカスタムエラー処理を設定できます。あるいは、明示的にErrorReportValveを設定し、そのshowServerInfo属性をfalseに設定することもできます。別の方法として、CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.propertiesというファイルを以下の内容で作成することでバージョン番号を変更できます。

server.info=Apache Tomcat/11.0.x

必要に応じて値を変更してください。ただし、これにより一部の管理ツールで報告されるバージョン番号も変更され、実際にインストールされているバージョンを特定するのが難しくなる可能性があることに注意してください。CATALINA_HOME/bin/version.bat|shスクリプトは引き続き正しいバージョン番号を報告します。

デフォルトのErrorReportValveは、エラー発生時にスタックトレースやJSPソースコードをクライアントに表示できます。これを避けるには、各Webアプリケーション内でカスタムエラー処理を設定できます。あるいは、明示的にErrorReportValveを設定し、そのshowReport属性をfalseに設定することもできます。

RewriteValveは正規表現を使用しており、不適切に形成された正規表現パターンは「壊滅的なバックトラッキング」や「ReDoS」の脆弱性を持つ可能性があります。詳細については、リライトドキュメントを参照してください。

MemoryRealmは、tomcat-users.xmlへの変更を有効にするためにTomcatの再起動が必要であるため、本番環境での使用を意図していません。

UserDatabaseRealmは大規模なインストール向けではありません。小規模で比較的静的な環境向けです。

JAASRealmは広く使用されておらず、そのため他のレルムほどコードが成熟していません。このレルムを使用する前に、追加のテストが推奨されます。

デフォルトでは、レルムはアカウントロックアウトの形式を実装していません。これは、ブルートフォース攻撃が成功する可能性があることを意味します。ブルートフォース攻撃を防ぐために、選択したレルムはLockOutRealmでラップされるべきです。

マネージャーコンポーネントはセッションIDを生成するために使用されます。

ランダムセッションIDを生成するために使用されるクラスは、randomClass属性で変更できます。

セッションIDの長さは、sessionIdLength属性で変更できます。

persistAuthenticationは、セッションに関連付けられた認証済みPrincipal（存在する場合）が、再起動中またはストアへのセッション永続化時に含まれるかどうかを制御します。

JDBCStoreを使用する場合、セッションストアは、JDBCStoreのみが永続化されたセッションデータにアクセスできるように（専用の認証情報、適切なパーミッションで）保護されるべきです。特に、JDBCStoreは、Webアプリケーションで利用可能な認証情報を介してアクセスできないようにすべきです。

セッションをストレージに永続化したり、クラスター内でセッションをレプリケートするマネージャー実装は、通常Javaシリアライゼーションを使用します。セッションデータは信頼できると見なされますが（アプリケーションが信頼されているため）、システム管理者はJavaシリアライゼーションに制限を設けることを検討してもよいでしょう。これはsessionAttributeValueClassNameFilter属性を使用して行うことができます。この属性の安全な初期値はjava\\.lang\\.(?:Boolean|Integer|Long|Number|String)|org\\.apache\\.catalina\\.realm\\.GenericPrincipal\\$SerializablePrincipal|\\[Ljava.lang.String;であり、これはアプリケーションのニーズに合わせて調整できます。sessionAttributeValueClassNameFilterに値を設定する場合は、warnOnSessionAttributeFilterFailureをtrueに設定することを推奨します。

クラスタ実装は、クラスタ関連のすべてのネットワークトラフィックに安全で信頼されたネットワークが使用されることを前提として書かれています。安全でない、信頼されていないネットワーク上でクラスタを実行することは安全ではありません。

機密性および/または完全性保護が必要な場合は、EncryptInterceptorを使用してノード間のトラフィックを暗号化できます。このインターセプターは、信頼されていないネットワークで実行するすべてのリスク、特にDoS攻撃から保護するものではありません。