ログアウトされた SSO Cookie の追跡、mpHealth REST エンドポイント制御など、26.0.0.7 の新機能
このリリースでは、ログアウト後の Cookie の再利用を防ぐために、ログアウトされた SSO Cookie の追跡がデフォルトで有効になり、ファイル・ベースのヘルス・チェックが有効な場合に mpHealth REST エンドポイントを無効にするオプションが追加されました。
Open Liberty 26.0.0.7 では次の変更があります:
ランタイムに新機能を追加し、ガイドも更新しました。
26.0.0.7 で修正されたバグのリストをご覧ください。
以前の Open Liberty GA リリースのブログ記事もご確認ください。
26.0.0.7 を使用したアプリケーションの開発と実行
Maven を使用している場合は、pom.xml ファイルに以下を含めてください:
<plugin>
<groupId>io.openliberty.tools</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>3.12.0</version>
</plugin>
Gradle の場合は、build.gradle ファイルに以下を含めてください:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'io.openliberty.tools:liberty-gradle-plugin:4.0.0'
}
}
apply plugin: 'liberty'
コンテナー・イメージを使用している場合は以下です。
FROM icr.io/appcafe/open-liberty
もしくは、ダウンロード・ページをご覧ください。
IntelliJ IDEA、Visual Studio Code、または Eclipse IDE を使用している場合は、オープンソースの Liberty 開発者ツールを利用して、IDE 内から効果的な開発、テスト、デバッグ、およびアプリケーション管理を行うこともできます。
LibertyコンテナイメージをUBI 10 Minimalに更新
Open Liberty 26.0.0.7以降、UBI MinimalをベースとするすべてのLibertyコンテナイメージ(-ubi-minimalタグが付いたイメージ)は、これまでのUBI 9 Minimalではなく、Red Hat Universal Base Image(UBI)10 Minimalをベースとして構築されるようになりました。
コンテナイメージのタグ名自体は変更されないため、イメージの参照先を更新する必要はありません。
今回の更新により、Libertyコンテナイメージのセキュリティが向上します。これは、OSパッケージに対するセキュリティ修正がUBI 10 Minimalではより早く提供されることが多く、その結果、作成されるコンテナイメージで報告されるCVEの数を減らせるためです。
26.0.0.7より前の既存のLibertyリリースでは、引き続きUBI 9 Minimalが使用されます。たとえば、26.0.0.6はUBI 9 Minimalのままであり、サポート対象のライフサイクル期間中は、OSおよびJavaのセキュリティアップデートを引き続き受け取ります。
ユーザーは、ビルド環境および実行環境が、基盤となるUBI 10 / RHEL 10と互換性があることを確認してください。
ログアウトされた SSO Cookie の追跡がデフォルトで有効化
アプリケーションの組み込みセキュリティーを継続的に改善するため、Open Liberty 26.0.0.7 では、ログアウトされたシングル・サインオン (SSO) Cookie の追跡がデフォルトで有効になりました。この機能により、ログアウトされた SSO Cookie は、ログアウト後に再利用できなくなります。
潜在的な影響は何ですか?
ログアウトされた SSO Cookie が再利用された場合、ユーザーは明示的に再認証を求められ、アプリケーションのセキュリティーが強化されます。
ログアウトされた SSO Cookie の追跡は、以下のサーバー構成で無効にすることもできます:
<webAppSecurity trackLoggedOutSSOCookies="false"/>
詳細については、ログアウトされた SSO Cookie の追跡に関する資料をご確認ください。
ファイル・ベースのヘルス・チェックが有効な場合の mpHealth-4.0 REST エンドポイントの無効化
mpHealth-4.0 の機能は、Open Liberty に MicroProfile Health 4.0 のサポートを追加します。この機能には、/health REST エンドポイントの代替として、ファイル・ベースのヘルス・チェック・メカニズムが含まれています。ファイル・ベースのヘルス・チェック・メカニズムが有効な場合、サーバー構成の属性を使用して /health/started、/health/live、および /health/ready REST エンドポイントを無効にできます。
以前は、ファイル・ベースのヘルス・チェックが有効な場合でも、REST ベースの MicroProfile Health エンドポイントは登録され、アクセス可能でした。この動作は、ファイル・ベースのヘルス・チェックに依存する Kubernetes デプロイメントでは冗長であることが多く、ユーザーは通常、httpGet や gRPC ではなく exec 戦略を使用してプローブを構成します。これらのシナリオでは、REST ヘルス・エンドポイントは使用されません。
この冗長性に対処するため、このリリースでは、server.xml ファイルの mpHealth サーバー構成要素に新しいオプションの enableEndpoints="false" 属性が導入されました。同等の環境変数 MP_HEALTH_ENABLE_ENDPOINTS=false もサポートされています。
このオプションが false に設定され、ファイル・ベースのヘルス・チェックが有効な場合、サーバーは MicroProfile Health REST エンドポイント (/health、/health/live、/health/ready、/health/started) を登録または公開しません。これらのエンドポイントへのリクエストは、'404 Not Found' レスポンスを返します。
ファイル・ベースのヘルス・チェックは、checkInterval 構成属性または MP_HEALTH_CHECK_INTERVAL 環境変数で有効にできます。
環境変数と server.xml 構成の両方が指定されている場合、実行時には server.xml 設定が優先されます。
<server>
<featureManager>
<feature>mpHealth-4.0</feature>
</featureManager>
<!-- Enable file-based health checks but disable HTTP endpoints -->
<mpHealth startupCheckInterval="1s" checkInterval="5s" enableEndpoints="false" />
...
</server>
enableEndpoints 構成属性または MP_HEALTH_ENABLE_ENDPOINTS 環境変数が設定されていない場合、デフォルト値は true であり、ヘルス・チェック REST エンドポイントが有効化され、公開されます。
注: この機能は、ファイル・ベースのヘルス・チェック・メカニズムが有効な場合にのみサポートされます。ファイル・ベースのヘルス・チェックが有効でなく、enableEndpoints 構成属性または環境変数が指定されている場合、警告メッセージがログに記録されます。REST ヘルス・エンドポイントはデフォルトで有効のままです。
詳細については、資料をご覧ください。
このリリースでのセキュリティー脆弱性 (CVE) の修正
| CVE | CVSS スコア | 脆弱性評価 | 影響を受けるバージョン | 注記 |
|---|---|---|---|---|
8.1 |
HTTP リクエスト・スマグリング |
17.0.0.3-26.0.0.6 |
servlet-3.0、servlet-3.1、servlet-4.0、servlet-5.0、servlet-6.0、servlet-6.1、websocket-1.0、websocket-1.1、websocket-2.0、websocket-2.1、および websocket-2.2 の機能に影響 |
|
5.9 |
サービス拒否 |
17.0.0.3-26.0.0.6 |
servlet-3.0、servlet-3.1、servlet-4.0、servlet-5.0、servlet-6.0、servlet-6.1、websocket-1.0、websocket-1.1、websocket-2.0、websocket-2.1、および websocket-2.2 の機能に影響 |
|
7.1 |
サービス拒否 |
17.0.0.3-26.0.0.6 |
servlet-3.0、servlet-3.1、servlet-4.0、servlet-5.0、servlet-6.0、servlet-6.1、websocket-1.0、websocket-1.1、websocket-2.0、websocket-2.1、および websocket-2.2 の機能に影響 |
|
7.5 |
サービス拒否 |
17.0.0.3-26.0.0.6 |
jaxws-2.2、xmlWS-3.0、および xmlWS-4.0 の機能に影響 |
|
7.5 |
サービス拒否 |
17.0.0.3-26.0.0.6 |
jaxws-2.2、xmlWS-3.0、および xmlWS-4.0 の機能に影響 |
|
7.2 |
サーバーサイド・リクエスト・フォージェリ |
17.0.0.3-26.0.0.6 |
jaxws-2.2、xmlWS-3.0、および xmlWS-4.0 の機能に影響 |
|
7.2 |
HTTP リクエスト・スマグリング |
17.0.0.3-26.0.0.6 |
restConnector-2.0 の機能に影響 |
|
7.4 |
HTTP リクエスト・スマグリング |
17.0.0.3-26.0.0.6 |
過去のセキュリティー脆弱性の修正のリストについては、セキュリティー脆弱性 (CVE) リストを参照してください。
このリリースで修正された注目すべきバグ
バグの修正に時間を費やしました。以下のセクションでは、このリリースで解決された問題の一部について説明します。詳細については、26.0.0.7 で修正されたバグの完全なリストをご覧ください。