Skip to main content

 

 

 

 
Language:

 

 
 
 
OutSystems

Google ChromeのCookie処理の変更予定

注記: OutSystemsによるこれらの変更は、Microsoftがリリースした.NET Framework 4.7.2および4.8に対する最新の変更が適用されているサーバーにのみ影響を及ぼします。

2020年2月、Google ChromeのデフォルトのCookieの動作が変更されます。サードパーティ連携やクロスサイトシナリオを使用するOutSystemsアプリがこの変更の影響を受けるおそれがあります。これらの変更の影響を受けるアプリケーションがある場合は事前に評価を行い、必要に応じてOutSystemsソフトウェアのパッチをインストールし(オンプレミスユーザーの場合)、問題を検出して解消する必要があります。クラウドユーザーについては、2020年1月20日~2月7日の間にこのパッチがインストールされる予定です。このアップデートが不要な場合は行わないことも選択できます。

OutSystemsが提供するパッチでは、デフォルトのものよりもセキュリティが低い別のCookieポリシーを選択することができ、これはOutSystemsプラットフォーム自体が生成するすべてのCookieに影響を及ぼします。このポリシーは、アプリケーションやサードパーティ連携で必要な場合にのみ選択してください。

FirefoxやEdgeなどのその他のブラウザでもデフォルトのCookieの動作が変更される予定ですが、スケジュールは現在のところ発表されていません。

同一サイトとクロスサイトの比較

アプリケーションが受ける可能性のある影響を把握するには、「サイト」とは何であるかや、「同一サイト」と「クロスサイト」の違いを理解することが重要です。

「サイト」とは、ドメインサフィックスとその直前のドメイン部分の組み合わせです。たとえば、以下のようなドメインがあるとします。

  • intranet.mycompany.com
  • extranet.mycompany.com
  • www.mycompany.com

これらのドメインは、いずれも同じサイトに属します。これらのドメインサフィックス(「com」)とその直前のドメイン(「mycompany」)は共通です。

なお、「ドメインサフィックス」部分に最上位ドメイン(「com」など)以外が含まれる場合もあります。
パブリックサフィックスリストによると、以下のドメインは異なるサイトに属しています。

  • johndoe.outsystemscloud.com
  • maryjane.outsystemscloud.com

「outsystemscloud.com」というパブリックドメインサフィックスがあるため、これらは異なるサイトに属します。これらはドメインサフィックスが同じ(「outsystemscloud.com」)ですが、その直前のドメイン部分(「johndoe」)が共通ではありません。

特定のサイトで(上記の「サイト」の定義に基づいて)異なるサイトのリソースに対して実行されるリクエストは、クロスサイトリクエストとみなされます。異なるサイトのコンテンツを表示するインラインフレームはこれに該当します。一方、現在のサイトに対して実行されるリクエストはいずれも同一サイトリクエストとみなされます。

同一サイトリクエストは、アナウンスされたChromeのCookieに関する変更予定の影響を受けません。

詳細と例については、Googleのドキュメントをご覧ください。

影響を受けるシナリオの例

Cookieの動作の変更の影響を受ける可能性のあるシナリオがいくつかあります。このドキュメントでは、以下のシナリオについてOutSystemsの観点から分析します。

  • サードパーティのコンテンツを表示するインラインフレームを含むOutSystemsアプリ
  • OutSystemsの画面/コンテンツを表示するインラインフレームを含むサードパーティのサイト
  • OutSystemsの画面/コンテンツを表示するインラインフレームを含むOutSystemsアプリ
  • クロスサイトリクエストを使用するOAuth/OpenID/SAML認証フロー
  • JavaScriptで設定されたカスタムCookie

その他の例やこの件の詳細については、Googleのドキュメントをご覧ください。

サードパーティのサイトのコンテンツを表示するインラインフレームを含むOutSystemsアプリ

OutSystemsアプリケーションでインラインフレームを使用してサードパーティのサイトのコンテンツを表示しているときに、それらのコンテンツプロバイダがセッションの状態を保持したりパーソナライズされたコンテンツを表示したりするためにCookieを必要としている場合、問題が発生するおそれがあります。

この問題を解決するには、サードパーティのコンテンツプロバイダ側で変更をいくつか実装する必要があります

プロバイダへの通信がすでにHTTPSプロトコル経由で行われている場合は、OutSystems側での変更は不要です。しかし、これらの通信がHTTPSではなくHTTPプロトコルで行われている場合は、OutSystemsアプリケーションを変更する必要があります。サードパーティプロバイダは、CookieにSecureアトリビュートを追加し、これらのCookieがHTTPSプロトコル経由でのみ送信されるように変更を行う必要があります。

OutSystemsの画面/コンテンツを表示するインラインフレームを含むサードパーティのサイト

インタラクションや認証を必要としない単純なクロスサイトのGETリクエストを除き、ほとんどのクロスサイトシナリオでは問題が発生します(上記の「同一サイトとクロスサイトの比較」をご覧ください)。 認証とセキュリティ検証のために常に必須のCookieがあるため、OutSystemsページが表示されるインラインフレームはCookieを送信できる必要があります。

サードパーティのサイトに埋め込まれたOutSystemsのコンテンツが適切に動作するようにするには、新しいOutSystemsのパッチをインストールして新しい「SameSite」の設定を「None」に設定し、プラットフォームによって生成されるCookieにSameSite=Noneアトリビュートが含まれるようにする必要があります。このアトリビュートの詳細と「None」値の意味については、「SameSiteアトリビュートの概要」をご覧ください。

また、これらのCookieをSecureとしてマークする必要があるため、環境レベルで「Force HTTPS for Screens」の設定を有効にし、OutSystemsコンテンツが埋め込まれたインラインフレームのURLでHTTPSプロトコルを使用する必要があります。

OutSystems UI WebとSilk UI Webの最新バージョンを使用していることを確認する必要もあります。詳細については、次のセクションをご覧ください。

OutSystemsの画面/コンテンツを表示するインラインフレームを含むOutSystemsアプリ

OutSystemsアプリケーションでインラインフレームを使用してOutSystemsのコンテンツを表示している場合は、以下のコンポーネントが最新バージョンであることを確認する必要があります。

  • OutSystems 10の場合: Silk UI Webの最新バージョン
  • OutSystems 11の場合: OutSystems UI WebSilk UI Web(アプリケーションでSilk UI Webをまだ使用している場合)の最新バージョン

クロスサイトリクエストを使用するOAuth/OpenID/SAML認証フロー

OAuth/OpenID/SAMLの認証フローの中には、GETリダイレクトではなくPOSTリクエストを使用して認証プロセスを完了するものがあります。POSTリクエストはクロスサイトリクエストであるため(「同一サイトとクロスサイトの比較」をご覧ください)、最後のリクエストにCookieが含まれず、認証プロセスが適切に完了しません。

このようなリクエストが、ChromeのデフォルトのCookieの動作が変更された主な理由の1つです。このため、新しいCookieポリシーを選択(「SameSite」の設定を「None」に設定)してこの認証シナリオを有効にすることは推奨できません。

代わりに、OutSystemsではPOSTリクエストでクロスサイトのCookieを必要としない他の認証フローに変更して適切に動作させることを推奨しています。ほとんどのIDプロバイダ(IdP)は開発者が選択できるフローを複数提供しています。

JavaScriptで設定されたカスタムCookie

より永続的な状態を維持するときなど、クライアント側のJavaScriptコードでCookieを設定する必要がある場合があります。クロスサイトシナリオでアプリケーションを使用し、プラットフォームのJavaScriptエクステンションを使用してCookieを設定している(「document.cookie =」を使用してCookieを設定する)場合、Cookieを読み取る際に問題が発生します。

この場合、互換性のないブラウザでの問題を避けるため、OutSystemsでは名前の異なる2つのCookieを定義することを推奨しています。1つは「;SameSite=None; Secure」とし、もう1つは「;Secure」とします。

例:

document.cookie = 'mycookie=value; SameSite=None; Secure';
document.cookie = 'mycookie-legacy=value; Secure';

また、以下の手順を実行して既存のCookieを読み取るコードを変更する必要もあります。

1.SameSiteアトリビュートセットを持つCookieを読み取ります。 1.Cookieが使用できない場合は、このアトリビュートを持たない他のCookieを読み取ります。

これにより、アプリケーションがすべてのブラウザに対応できるようになり、ユーザーエージェント文字列に基づく判別が不要になります。この推奨事項は、Googleのドキュメントで提案されている互換性のないクライアントの処理方法に沿ったものです。

これらの変更ではOutSystemsのパッチは不要ですが、必要に応じてOutSystemsアプリケーションが2つのCookieを設定したり読み取ったりできるように変更し、適切に動作することをテストで確認する必要があります。

影響の有無の確認

アプリケーションが予定された変更に対応できていることを確認するため、2つのChrome機能フラグを有効化し、Chrome 80でリリースされる予定のCookie処理の動作でアプリケーションをテストします。また、使用する可能性のあるカスタムCookieの動作もテストします。これらのChrome機能フラグは、Chrome 76以降で利用可能です。

以下の手順を実行します。

1.Chromeを開いて次のアドレスに移動します: chrome://flags 1.機能フラグの値を「Default」から「Enabled」に変更して以下の試験運用版の機能を有効にします。 * 「SameSite by default cookies」 * 「Cookies without SameSite must be secure」 1.Chromeを再起動し、アプリケーションを再度開きます。 1.アプリケーションが停止せず適切に動作することをテストで確認します。テストには以下が含まれるようにします。 * 認証シナリオ * 埋め込まれたサードパーティプロバイダのコンテンツが表示されるページ(存在する場合) * アプリケーションの主な機能の一般的なアクション

アプリケーション(具体的には、上記のいずれかのシナリオ)で問題が見つかった場合は、以下の手順を実行します。

1.引き続きChromeで、Chrome Developer Toolsを開きます。 1.ウィンドウの下部にあるコンソールでクロスサイトCookieに関連する警告を確認します。

機能フラグが有効になっている場合、SameSite=NoneアトリビュートやSecureアトリビュートがないために一部のCookieがブロックされたことを示す警告が、Chrome Developer Toolsのコンソールに表示される可能性が高いです。これはChrome 80の新しいCookie処理の動作をシミュレーションしているからであり、この新しい動作によってアプリケーションで問題が発生している可能性があります。

以下の図は、インラインフレームを含むアプリケーション画面を開いたときのコンソールの警告を示しています。この図は、Chrome 76で2つの機能フラグを有効にしてテストしたときのものです。

新しいCookieの動作が本当に問題の根本的な原因であるかどうかを確認するには、Chromeの機能フラグを無効にしてアプリを再テストするか、他のブラウザでアプリをテストします。

注記: Chromeのバグのため、ページで使用されていないサブドメインのCookieに関する警告が表示されます。これらの警告で示されたCookieは分析している問題とは無関係である場合があるため、ご注意ください。このバグはChrome 80で修正されます。このバージョンでは新しいCookie処理の動作もリリースされます。

OutSystemsのパッチの内容{ #patch }

OutSystems 11ではパッチを適用すると、プラットフォームによって生成されるCookieのSameSiteアトリビュートのデフォルト値を新しい「SameSite」の設定で構成できるようになります。

LifeTimeの新しい「SameSite」の設定で、以下のいずれかの値を選択できます。

  • Browser Default – ブラウザのデフォルトの処理を使用します。つまり、プラットフォームによって生成されるCookieにSameSiteアトリビュートを含めません。
  • None – プラットフォームによって生成されるCookieにSameSite=Noneアトリビュートを含めます。

また、同じ構成画面に新しい「Secure」の設定もあります。このオプションを有効にすると、プラットフォームによって生成されるすべてのCookieにSecureアトリビュートが追加されます。

注記: 「SameSite」の設定を「None」に設定する場合、以下も有効にする必要があります。

  • 新しい[Secure]の設定
  • Enable HTTP Strict Transport Security (HSTS)]と[Force HTTPS for Screens in Web Applications]のいずれかまたは両方の設定

これらの設定の詳細については、「HTTPSセキュリティを適用する」をご覧ください。

HttpRequestHandlerエクステンションのSetCookieアクションに新しいオプションの入力パラメータがあり、これを使用して特定のCookieの「SameSite」の値と「Secure」の値を指定できます。これらの入力パラメータの値が指定されていない場合、生成されるCookieはプラットフォーム全体の設定の値に従います。

OutSystems 10ではパッチを適用すると、SameSite Cookie構成のサポートが追加されますが、LifeTimeには新しい設定はありません。Factory Configurationを使用してSameSiteの動作を構成することができます。
OutSystems 10でこのSameSiteの構成の変更を適用するには、開発インフラを再パブリッシュする必要があります。1回の再パブリッシュで済むように、パッチをインストール後すぐにこの設定を構成することを推奨します。

また、HttpRequestHandlerエクステンションのSetCookieアクションはOutSystems 10では変更されません。このアクションはプラットフォームで定義されたCookieの動作の構成(Factory Configurationで設定可能)に従いますが、SameSiteアトリビュートとSecureアトリビュートをCookieごとにカスタマイズすることはできません。

プラットフォームの構成を変更しない限り、これらの動作は同じままです。そのため、デフォルトではプラットフォームによって生成されるCookieのSameSiteアトリビュートの値は指定されません。この場合、ブラウザで誤検出の警告が表示されることがありますが、すべてのブラウザで現在のデフォルトのCookie処理の動作(ブラウザがクロスサイトリクエストでCookieを許可)が維持されるため、アプリは引き続き正常に動作します。

将来のバージョンでは、主要なブラウザでこの新しいCookie処理の動作がロールアウトされた後、OutSystemsは結果を踏まえてこのデフォルト設定を見直し、「SameSite」設定の構成値として「Lax」を追加する可能性を検討します。

リリーススケジュール

クラウドユーザーの場合

クラウドユーザーについては、プラットフォームのアップデートスケジュールについてOutSystemsからご連絡を差し上げます。このアップデートは1月20日2月7日の間に行われます。アプリで問題が見つからなかった場合、このアップデートを行わないことを選択できます。

オンプレミスユーザーの場合

OutSystemsでは、Platform Server 11用の以下のパッチをリリースしました。

  • Platform Server 11 Release Oct.2019 CP6
  • LifeTime管理コンソールRelease Dec.2019

また、Platform Server 10の新しいリリース(バージョン10.0.1021)も提供しています。

Microsoftも、ChromeのCookie処理の動作の変更に関連する.NET Framework用のパッチをリリースしています。詳細については、公開されている各オペレーティングシステムバージョン向けのナレッジベース記事をご覧ください。
MicrosoftのパッチにはセッションのCookie処理に関する互換性を破る変更が含まれています。そのため、パッチをインストールする前に、Platform ServerのパッチをインストールしてOutSystemsアプリケーションを再パブリッシュしてください。

アプリケーションで問題が見つからず、プラットフォームによって生成されるCookieにSameSite=Noneアトリビュートを設定する新しいオプトイン機能が不要な場合は、.NET FrameworkのパッチやOutSystemsが提供するパッチをインストールする必要はありません。

注記: OutSystemsでは、このMicrosoftパッチに伴う.NET Frameworkプラットフォームバージョン要件の変更は行いません。

技術的な補足情報

SameSiteアトリビュートの概要

新しいCookieを設定するときに、SameSite Cookieアトリビュートを含めることができます。 このアトリビュートには3種類の値を使用できます。各値の意味は以下のとおりです。

  • Strict – サードパーティのCookieを許可しません。他のサイトへのリンクをクリックしてもCookieは送信されません。
  • Lax – サードパーティのCookieを許可しません。ただし、ユーザーが別のサイトへのリンクをクリックしたときはCookieが送信されます。
  • None* – 古い動作を維持します。ただし、サードパーティのサイトがHTTPSを使用し、CookieがSecureとしてマークされている必要があります。

このアトリビュートが定義されていない場合、現在はすべてのブラウザがクロスサイトリクエストのCookieを許可します。

* 「None」値は最近提案されたものであるため、一部の古いブラウザはこの値に対応していません。このアトリビュート値を含むCookieが受け入れられる場合と、ブロックされる場合があります。プラットフォームで生成されるCookieではこれは自動的に処理されますが、「JavaScriptで設定されたカスタムCookie」のセクションに示されているこの問題の回避策を参照することを推奨します。

Chromeの変更内容

Chromeでは、現在はSameSiteアトリビュートが指定されていないCookieのデフォルトの動作が変更されます。Chrome 80以降、SameSiteアトリビュートが指定されていないときのCookieのデフォルト設定がSameSite=Laxになります。

つまり、送信先サイトがブラウザでアクセスしているドメインと一致しない場合、これらのCookieは送信されません。また、これに伴ってクロスドメイン連携を必要とするサードパーティプロバイダは、1)CookieでSameSite=Noneアトリビュートを指定して目的を宣言し、2)CookieをSecureに指定して、3)HTTPS接続を使用することを義務付けられます。

詳細については、Googleの「SameSite cookies explained」のトピックをご覧ください。

OutSystemsの新しい「SameSite」の設定と「Secure」の設定の影響を受けるCookieは、以下のとおりです。

  • プラットフォームによって設定される内部Cookie(セッション処理用のCookieなど)
  • HttpRequestHandlerエクステンションのSetCookieアクションを使用して設定されるCookie

これらの方法で設定されるCookieについては、すべて新しい設定の値に従ってCookieが作成されます。

以下の場合に生成されるCookieは、プラットフォームで定義された構成に自動的には従いません

  • JavaScriptコードで設定されたCookie
  • エクステンションで設定されたCookie

このような場合、Cookieを定義するときにアトリビュートがすべて適切に設定されたことを確認する必要があります。JavaScriptで設定されたCookieの詳細については、「JavaScriptで設定されたカスタムCookie」をご覧ください。