1. はじめに
このセクションは規範的ではありません。
ユーザーがexample.comのウェブページを安全なチャネル（例えばHTTPS）経由で正常に読み込むとき、ユーザーエージェントとexample.comの間の通信データが第三者に盗聴または改ざんされていないことが保証されます。しかし、この保証はウェブページがスクリプトや画像などのサブリソースを安全でない接続で読み込んだ場合に弱まります。たとえば、安全でない方法で読み込まれたスクリプトは、攻撃者がユーザーの代わりにデータを読み取ったり変更したりすることを許す可能性があります。安全でない方法で読み込まれた画像は、攻撃者がユーザーに誤った情報（例：捏造された株価チャート）を伝えたり、クライアント側の状態を変更したり（例：クッキーの設定）、意図しない行動を誘発したり（例：ボタンのラベル変更）することができます。これらのリクエストは「混在コンテンツ」と呼ばれます。
本仕様は、ユーザーエージェントがこれらのリスクを軽減するために、特定のタイプの混在コンテンツをブロックし、一部のコンテキストでより厳格に動作する方法を詳述します。
ただし、以前のバージョンの本仕様はユーザーのデータの機密性および完全性を十分に保護していませんでした。画像・音声・動画などの安全でないコンテンツは、現行では安全なコンテキストでもデフォルトで読み込むことができます。安全なページは、ユーザーエージェントのサンドボックスを完全に回避する安全でないダウンロードさえ開始することができます。
さらに、混在コンテンツが読み込まれた場合、ユーザーには明確なセキュリティ指標が表示されません。ウェブページが混在コンテンツを読み込むと、ブラウザは「中間的な」セキュリティ指標（例：南京錠アイコンの削除）を表示しますが、ユーザーがそのページを信頼すべきかどうか明確には示しません。このUXは、開発者が混在コンテンツを回避する十分な動機付けにもなっていません。なぜなら、現状でも多くのウェブページが混在コンテンツを読み込んでいるからです。すべての混在コンテンツをブロックすれば、ユーザーにとっても「ウェブページが安全な通信で読み込まれているかどうか」という単純な理解モデルとなり、開発者も必要なコンテンツを安全に読み込むよう促されます。
そのため、本仕様はユーザーにより良いセキュリティとプライバシーの保証、そしてより良いセキュリティUXを提供しつつ、破壊を最小限に抑えるよう改訂されました。ブラウザが単純にすべての混在コンテンツを厳しくブロックするのではなく、混在コンテンツの自動アップグレードを推奨します：
-
ユーザーエージェントがまだブロックしていない混在コンテンツは、安全な通信へ自動アップグレードされるべきです。
-
リクエストが自動アップグレードできない場合は、ブロックされます。
自動アップグレードにより、安全なウェブページで安全でないリソースが読み込まれることを防ぎつつ、開発者の作業負担を最小限に抑えます。
本仕様は、現在デフォルトでブロックされていない種類の混在コンテンツサブリソースのみ自動アップグレードを推奨し、すでにブロックされているコンテンツ種別の自動アップグレードは推奨しません。これは、ウェブ上で発生する変化を最小限に抑えるためであり、自動アップグレードがデフォルトで混在コンテンツをすべてブロックするという目標に近づく場合のみ実施します。
本仕様では混在ダウンロードという概念も明確に導入します。混在ダウンロードとは、安全なコンテキストによって開始されたが、安全でない接続でダウンロードされるリソースのことです。ユーザーエージェントは混在ダウンロードをブロックすべきです。なぜなら、（実行ファイルの場合）ユーザーエージェントのサンドボックスを回避できたり、（例：銀行明細書のダウンロードの場合）機密情報を含むことがあるためです。特に混在ダウンロードは、ユーザーエージェントがユーザーに安全なページであると表示しながら、ダウンロードを開始・完了させるので、誤解を招きやすいです。
2. 主要な概念と用語
- 混在コンテンツ
-
request の URL が 潜在的に信頼できるURL
ではなく、かつ、それを読み込む責任のあるコンテキストが混在セキュリティコンテキストを禁止している場合（後者の厳密な定義については § 4.3 settingsは混在セキュリティコンテキストを禁止しているか？
を参照）、混在コンテンツ となります。
response が 認証されていないレスポンス であり、かつ、それを読み込む責任のあるコンテキストが混在セキュリティコンテキストを禁止している場合、その response も混在コンテンツとなります。
注: 「混在コンテンツ」は元々 Web Security Context: User Interface Guidelines [WSC-UI] の セクション5.3 で定義されました。本書はその初期定義を更新します。
注: [XML] でも「混在コンテンツ」という無関係な概念が定義されています。用語の混乱を招く可能性はありますが、この用語が10年以上にわたりユーザーエージェントのセキュリティ分野で広く使われているため、実質的な混乱のリスクは低いと考えられます。
- 認証されていないレスポンス
- response (response) の URL が 潜在的に信頼できるURL ではない場合、a posteriori で認証されていないと判断できます。
- 埋め込みドキュメント
-
DocumentA の 埋め込みドキュメント とは、A の 閲覧コンテキスト の コンテナドキュメント のことです。[HTML] - 混在ダウンロード
- 混在ダウンロードとは、安全なコンテキストによって開始されたが、安全でない接続でダウンロードされるリソースのことです。
a priori 認証済みURL は、潜在的に信頼できるURLと同等です。[SECURE-CONTEXTS]
3. コンテンツカテゴリ
理想的な世界では、すべてのユーザーエージェントは例外なくすべての混在コンテンツをブロックすることが求められます。しかし現実のインターネットでは、それは非現実的です。ユーザーエージェントは、膨大な数のウェブサイトの利用体験を損なわないよう、より微妙な制限を行う必要があります。
この観点から、混在コンテンツを § 3.1 アップグレード可能なコンテンツ と § 3.2 ブロック可能なコンテンツ の2つに分類します。
3.1. アップグレード可能なコンテンツ
アップグレード可能なコンテンツは、以前のバージョンの本仕様ではオプションでブロック可能と呼ばれていました。
混在コンテンツが混在コンテンツとして許可されるリスクよりも、ウェブの大部分が動作しなくなるリスクの方が大きい場合、そのコンテンツはアップグレード可能です。これは、そのリソースタイプの混在利用率が高く、かつそのリソース自体のリスクが比較的低い場合です。アップグレード可能だからといって安全という意味ではなく、他のリソースタイプほど致命的な危険性は低いというだけです。例えば、画像やアイコンはアプリケーションのUIの中心的な要素であることが多く、攻撃者が「メール削除」と「返信」アイコンを入れ替えると、ユーザーに実害が生じる可能性があります。
このカテゴリには以下が含まれます：
-
initiator が空文字列で、destination が "
image" のリクエスト。注: これはほとんどの画像（
img、SVG画像等）やCSS（background-image、border-imageなど）に該当します。ただし、img要素がsrcsetやpictureを利用する場合は含みません。 -
destination が "
video" のリクエスト。 -
destination が "
audio" のリクエスト。
さらに § 4.4
リクエストの取得は混在コンテンツとしてブロックすべきか？
で、CORS有効なリクエストは強制的に失敗させます。たとえば、<img crossorigin ...>で読み込まれる混在コンテンツ画像はブロックされます。これは、このカテゴリに含まれるのは「広く使われているために一律ブロックできないもののみ」という原則の好例です。ワーキンググループは今後さらにブロック可能なサブセットを切り出していく予定です。
3.2. ブロック可能なコンテンツ
上記で定義したアップグレード可能でないすべての混在コンテンツは、ブロック可能とみなされます。典型的な例としては、スクリプト、プラグインデータ、XMLHttpRequestによるデータ取得などがあります。
注: ナビゲーションリクエストはトップレベル閲覧コンテキストを対象とする場合がありますが、これらは混在コンテンツとはみなされません。詳細は § 4.4 リクエストの取得は混在コンテンツとしてブロックすべきか？ を参照してください。
注: プラグインのために行われるリクエストもブロック可能です。ただし、ユーザーエージェントがこれらのリクエストを常に制御できるとは限りません。NPAPIプラグインなどはネットワークへ直接アクセスでき、ユーザーエージェントを完全にバイパス可能です。ユーザーエージェントは可能な限りこれらのリクエストをブロックすることを推奨し、プラグインベンダーは本書で示されたリスクを軽減するために混在コンテンツチェックを実装することが望まれます。
4. アルゴリズム
4.1. 混在コンテンツrequestを潜在的に信頼できるURLへ、適切な場合はアップグレードする
注: Fetch仕様はこのアルゴリズムにフックし、アップグレード可能な混在コンテンツをHTTPSにアップグレードします。
Request requestが与えられた場合、このアルゴリズムはリクエストがアップグレード可能な混在コンテンツと判断された場合、そのURLを書き換えます。具体的なアルゴリズムは以下の通りです：
-
以下のいずれかの条件が満たされた場合、requestを変更せずにリターンする：
- requestのURLが潜在的に信頼できるURLである。
- requestのURLのホストがIPアドレスである。
- § 4.3
settingsは混在セキュリティコンテキストを禁止しているか？がrequestのclientに適用されて"
Does Not Restrict Mixed Security Contents"を返す。 - requestのdestinationが"
image"、"audio"、"video"以外である。 -
requestのdestinationが"
image"かつrequestのinitiatorが"imageset"である。注: 歴史的な理由により"
imageset"はアップグレードされません。以前は混在コンテンツをブロック可能・オプションでブロック可能に区分していましたが、"imageset"はブロック可能に含まれており、仕様にアップグレードが追加された際もアップグレード対象外となりました。
-
requestのURLのschemeが
httpの場合、 requestのURLのschemeをhttpsに設定し、リターンする。注: [url]に従い、ポートは変更しません。schemeが
httpの場合ポートはnullとなり、schemeがhttpsに変更された時点で443として解釈されます。
4.2. 以前のアルゴリズムへの修正
注: このセクションは仕様の以前のバージョンのアルゴリズムに対する修正を含みます。オプションでブロック可能とブロック可能の区別を無視し、すべてのオプションでブロック可能な混在コンテンツは自動アップグレードされるようになりました。
4.3. settingsは混在セキュリティコンテキストを禁止しているか？
ドキュメントとワーカーの両方は環境設定オブジェクトを持ち、以下のアルゴリズムによって混在コンテンツを制限するかどうかを判定できます。このアルゴリズムは適切に"Prohibits Mixed Security Contexts"または"Does Not Prohibit Mixed Security Contexts"を返します。
environment settings object (settings)が与えられた場合：
-
settingsのoriginが潜在的に信頼できるoriginなら "
Prohibits Mixed Security Contexts"を返す。 -
settingsのglobal objectが
windowの場合：-
documentにsettingsのglobal objectの関連付けられたDocumentを設定する。
-
各navigable navigableをdocumentの先祖navigablesで反復：
-
navigableのactive documentのoriginが潜在的に信頼できるoriginなら "
Prohibits Mixed Security Contexts"を返す。
-
-
-
"
Does Not Restrict Mixed Security Contexts"を返す。
4.4. requestの取得は混在コンテンツとしてブロックすべきか？
注: Fetch仕様はこのアルゴリズムにフックし、リクエストが完全にブロックされるべきか（例：ブロック可能コンテンツの場合、安全な接続で読み込まれないと仮定できる）を判定します。
あるリクエスト requestが与えられた場合、ユーザーエージェントは、 次のアルゴリズムを介してリクエスト requestを続行すべきかどうかを 決定する：
-
以下のいずれかの条件が満たされた場合はallowedを返す：
- § 4.3
settingsは混在セキュリティコンテキストを禁止しているか？がrequestのclientに適用されて"
Does Not Restrict Mixed Security Contexts"を返す。 - requestのURLが潜在的に信頼できるURLである。
- ユーザーエージェントが混在コンテンツの許可を指示されている（§ 7.2 ユーザーコントロール参照）。
-
requestのdestinationが"
document"で、requestのtarget browsing contextに親閲覧コンテキストが存在しない。注: トップレベルナビゲーションは混在コンテンツのチェック対象外ですが、ユーザーエージェントは安全でないフォーム送信に対して混在コンテンツチェックを適用することも可能です（§ 7.1 フォーム送信参照）。
- § 4.3
settingsは混在セキュリティコンテキストを禁止しているか？がrequestのclientに適用されて"
- blockedを返す。
4.5. requestへのresponseは混在コンテンツとしてブロックすべきか？
注: リクエストが進行した場合でも、レスポンスを生成した接続の状態（例：リクエストがブロック可能だが接続が認証されていないなど）によってレスポンスのブロックが必要になる場合があります。また、Service Workerがブロック可能リクエストに対して認証されていないレスポンスを誤って返さないようにも判断が必要です。このアルゴリズムはその判定に使用されます。
request requestとresponse responseが与えられた場合、ユーザーエージェントは以下のアルゴリズムで返すべきレスポンスを判定します：
-
以下のいずれかの条件が満たされた場合はallowedを返す：
- § 4.3
settingsは混在セキュリティコンテキストを禁止しているか？がrequestのclientに適用されて
Does Not Restrict Mixed Contentを返す。 - responseのurlが潜在的に信頼できるURLである。
- ユーザーエージェントが混在コンテンツの許可を指示されている（§ 7.2 ユーザーコントロール参照）。
-
requestのdestinationが"
document"で、requestのtarget browsing contextに親閲覧コンテキストが存在しない。注: トップレベルナビゲーションは混在コンテンツのチェック対象外ですが、ユーザーエージェントは安全でないフォーム送信に対して混在コンテンツチェックを適用することも可能です（§ 7.1 フォーム送信参照）。
- § 4.3
settingsは混在セキュリティコンテキストを禁止しているか？がrequestのclientに適用されて
- blockedを返す。
5. 統合
5.1. Fetchへの修正
Fetch § 4.1 メインフェッチは、ステップ3と4の間でrequestに対して§ 4.1 混在コンテンツのリクエストを適切な場合は潜在的に信頼できるURLへアップグレードするを呼び出すように修正すべきです。すなわち、アップグレード可能な混在コンテンツは混在コンテンツのブロック処理を適用する前にHTTPSへ自動アップグレードされるべきです。
5.2. HTMLへの修正
ナビゲートレスポンスの処理 は以下のように修正すべきです。ステップ3は、sourceのアクティブドキュメントのURLが潜在的に信頼できるURLで、かつresponseのURLリスト内のいずれかのURLが潜在的に信頼できるURLでない場合、ダウンロードを中止してリターンすべきです。
同様の修正をハイパーリンクのダウンロードにも適用すべきです。このアルゴリズムでは、ステップ6.2は、subjectのノードドキュメントのURLが潜在的に信頼できるURLで、かつresponseのURLリスト内のいずれかのURLが潜在的に信頼できるURLでない場合はリターン（ダウンロード中止）すべきです（responseはrequestのフェッチ結果）。
注: ダウンロードは他の混在コンテンツタイプと異なり自動アップグレードされません。なぜなら、ユーザーエージェントはリソースがダウンロードされるかどうかをリクエスト前に必ずしも把握できないためです。
注: リソースはユーザーエージェントが不正な接続に基づいてダウンロードを中止するかどうかを判断する前にダウンロードされます。そのため、ユーザーエージェントが最終的にダウンロードをブロックしても、機密情報がネットワーク上を通過する可能性があります。これは一般的に避けられませんが、ユーザーエージェントがリソースをブロックすることで、ウェブサイト運営者が安全な接続でダウンロードを提供するよう促すことができます。
6. 廃止事項
6.1. Strict Mixed Content Checking
以前のバージョンの本仕様ではblock-all-mixed-content
CSPディレクティブが定義されていましたが、現在は廃止されています。なぜなら、自動アップグレードできないすべての混在コンテンツが現在はブロックされるためです。
注: upgrade-insecure-requests ([upgrade-insecure-requests])ディレクティブは廃止されていません。これは開発者がブロック可能なコンテンツをアップグレードできるようにするためです。本仕様はデフォルトでアップグレード可能なコンテンツのみアップグレードします。
7. セキュリティおよびプライバシーに関する考慮事項
全体として、アップグレード可能な混在コンテンツの自動アップグレードは、より多くのユーザー通信をネットワークの盗聴や改ざんから保護できるため、セキュリティ・プライバシーの向上が期待されます。
開発者が意図しなかったリソースを読み込むことで、ウェブページにセキュリティやプライバシー上の問題が発生するリスクがあります。例えば、あるウェブサイトがhttp://www.example.com/image.jpgから画像を読み込んでおり、何らかの理由でhttps://www.example.com/image.jpgがトラッキングサイトにリダイレクトされている場合、ブラウザは開発者やユーザーの明示的な同意なしにプライバシー問題を引き起こすことになります。しかし、こうしたケースは非常に稀であると考えられます。このリスクはアップグレード可能なコンテンツのみを自動アップグレードし、ブロック可能なコンテンツは対象外とすることで軽減されます。ブロック可能なコンテンツは、例えば古い脆弱なJavaScriptライブラリを読み込むなど、より大きなリスクを持つ可能性があります。
7.1. フォーム送信
§ 4.3 settings は混在セキュリティコンテキストを禁止するか？が
Restricts Mixed Contentを返すのが、Documentの
関連する設定オブジェクトに適用された場合であるなら、ユーザーエージェントは、
ユーザーに対し、
1 つ以上の
form
要素であって、action 属性の
値が 潜在的に信頼できる URLではないものが存在することを警告することを選択してもよい。
ユーザーエージェントは、
form
要素を送信する際に、その action 属性の値が 潜在的に信頼できる URLではない場合にユーザーへ警告し、
ユーザーが送信を中止できるようにすることを選択してもよい。ユーザーエージェントが、
form
要素の
送信先が 潜在的に信頼できる URLではないことについて警告する場合、そのエージェントは、
さらに、
送信時に、
form
要素の action のリダイレクト先が、
潜在的に信頼できる URLではなく、その結果、
form
の情報が露出する場合にも、ユーザーに警告し、ユーザーが送信を中止できるようにするべきである。
さらに、ユーザーエージェントは、そのような Document
からの form 送信を、ブロック可能なリクエストとして扱ってもよく、これは送信が
トップレベル閲覧コンテキストで行われる場合でも同様である。
7.2. ユーザーコントロール
ユーザーエージェントは、特定のページでブロック可能混在コンテンツのブロック決定をユーザーが上書きできる機能を提供してもよいです。注: 実際には、ユーザーエージェントがこのような抜け道を一切提供しないのは困難でしょう。ただし、混在スクリプトの許可は特に非常に危険な選択であり、各ユーザーエージェントはREALLY SHOULD NOT [RFC6919]、リスクを慎重に説明した上で選択肢を提示すべきです。
ユーザーエージェントは、特定のページでアップグレード可能混在コンテンツの自動アップグレード決定をユーザーが上書きできる機能を提供してもよいです。
ユーザーエージェントがそのようなコントロール機能を提供する場合、支援技術を利用するユーザーのためにアクセシビリティAPI経由でも同様の機能を提供しなければなりません。
8. 謝辞
WebAppSec WGから寄せられた素晴らしいフィードバックに加え、Chromeセキュリティチームは本仕様の準備において非常に貴重な協力をしてくれました。特に、Chris Palmer、Chris Evans、Ryan Sleevi、Michal Zalewski、Ken Buchanan、Tom Sepezは、初期段階で多くのフィードバックを提供してくれました。Anne van KesterenはFetchの説明や本仕様へのインターフェース定義、Level 2アップデートへの重要なフィードバックを提供してくれました。Brian Smithは仕様を焦点化し、簡潔で理性的なものに保つために助力してくれました。