Apache Tomcat 10

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

通常、アクセス制御は非常に制限されています (すべてに対して読み取り専用か、すべてに対して読み取り/書き込みのどちらか)。 Tomcat は、デバッグ、モニタリング、および管理を支援するために、JMX を介して大量の内部情報と制御を公開しています。 利用可能なアクセス制御が限られていることを考えると、JMX アクセスはローカルの root/admin アクセスと同等に扱い、それに応じて制限する必要があります。

ほとんど (すべて?) の JRE ベンダーによって提供される JMX アクセス制御は、認証の失敗をログに記録せず、繰り返しの認証失敗後のアカウントロックアウト機能も提供しません。 これにより、ブルートフォース攻撃を簡単に実行でき、検出が困難になります。

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

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

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

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

ドキュメント Web アプリケーションは非常に低いセキュリティリスクを示しますが、使用されている Tomcat のバージョンを識別します。 通常は、公開アクセス可能な Tomcat インスタンスから削除する必要があります。

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

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

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

Tomcat インスタンスの管理機能を提供する Web アプリケーションをデプロイする場合は、次のガイドラインに従う必要があります。

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

デフォルトの server.xml には、コメントアウトされたいくつかのコンポーネント定義例を含む、多数のコメントが含まれています。 これらのコメントを削除すると、server.xml の読み取りと理解が大幅に容易になります。

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

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

シャットダウンポートが無効になっていない場合、shutdownに対して強力なパスワードを設定する必要があります。

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

JNIライブラリローディングリスナーは、ネイティブコードをロードするために使用できます。信頼できるライブラリのロードにのみ使用する必要があります。

セキュリティライフサイクルリスナーを有効にし、適切に設定する必要があります。

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

AJPコネクタは、信頼できるネットワークでのみ使用するか、適切なsecret属性で適切に保護する必要があります。

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

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

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

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

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

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

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

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

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

maxParameterCount属性は、クエリ文字列から取得したリクエストパラメータ（アップロードされたファイルを含む）の最大合計数と、POSTリクエストの場合は、コンテンツタイプがapplication/x-www-form-urlencodedまたはmultipart/form-dataの場合のリクエストボディを制御します。過剰なパラメータは無視されます。このようなリクエストを拒否する場合は、FailedRequestFilterを設定してください。

xpoweredBy属性は、X-Powered-By HTTPヘッダーを各リクエストで送信するかどうかを制御します。送信される場合、ヘッダーの値には、ServletおよびJSP仕様のバージョン、完全なTomcatバージョン（例：Apache Tomcat/10.1）、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属性は、Tomcatがすべての認証と認可を処理するか、認証をリバースプロキシに委任するか（認証されたユーザー名はAJPプロトコルの一部としてTomcatに渡されます）を決定するために、AJPコネクタで使用されます。Tomcatが認可をさらに実行するオプションがあります。

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

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

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

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

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

privileged属性は、コンテキストがマネージャーサーブレットなどのコンテナ提供のサーブレットを使用することを許可するかどうかを制御します。デフォルトでは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ユーザーは読み取り/書き込み、他のユーザーはアクセス不可にします。

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

管理アプリケーションは、RemoteAddrValve（このValveはフィルターとしても利用可能）で保護する必要があります。allow属性を使用して、既知の信頼できるホストのセットへのアクセスを制限する必要があります。

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

server.info=Apache Tomcat/10.1.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アプリケーションが利用できる資格情報でアクセス可能にすべきではありません。

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

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