[67] CSP指令 upgrade-insecure-requests
は、そのページに関する fetch で http: を
https: に書き換えること (格上げ)
を指示するものです。
[68] HTTP要求の Upgrade-Insecure-Requests:
ヘッダーは、クライアントが本 CSP指令に対応していることを示すものです。
[69] 本機能は W3C WebAppSec WG で Mike West らにより開発された仕様書 Upgrade Insecure Requests (非保安要求の格上げ、 UIR) で規定されています。
[71] CSP指令 upgrade-insecure-requests
は、本来 http: URL で指定され素のHTTP
で fetch するべきところを https:
に書き換え HTTPS で fetch するよう、 Webブラウザーに指示するものです。
[72] 10年代半ば、インターネットのプロトコルが平文から TLS
ベースへと移行することを迫られる中、既存の http:
前提の Webサイトの HTTPS への移行のために Webサイト中の http:
URL をすべて書き換えなければ Mixed Content 制約に抵触することが問題となりました。
例えば script 要素で http:
の絶対URLが指定されていると、
そのままでは HTTPS 化できません。そのため、あまりメンテナンスされなくなった
Webページや本文を編集したくない歴史的な文書などの Webサイトは
HTTPS に移行するのが困難でした。
[73] そこで導入された本機能を使うと、Webページの文書自体は編集せずとも
HTTPヘッダーを追加するだけで、 Mixed Content 制約の検査の前に
http: URL をWebブラウザーに読み替えさせることができます。
[74] ただし Mixed Content 制約を実装して本機能を実装しない旧来の
Webブラウザーに対して HTTPS でWebサイトを提供すると、
CSP指令は単に無視されますから、 URL の書き換えが行われず、
Webサイトは壊れてしまいます。そこで本機能に対応した Webブラウザーは
HTTP要求に Upgrade-Insecure-Requests: 1
ヘッダーを追加することになっています。サーバーはこのヘッダーがある時だけ
HTTPS で本機能を利用し、そうでない時は従来通り素のHTTP
で Webサイトを提供できます。
[76] CSP指令 upgrade-insecure-requests
は、その文書内の画像、スクリプト、ワーカー、
XHR アクセスなどで http: を https:
に読み替えさせます。 WebSocket アクセスでは ws:
を wss: に読み替えさせます。
[78] CSP指令 upgrade-insecure-requests
は、その文書からの navigate (ハイパーリンクやフレームなど)
のうち、同じ起源へのものや、フォーム提出について http: を
https: に読み替えさせます。
[59] 本仕様書では次のプロトコル要素が定義されています。
[24] URL scheme を https や wss
に書き換えた時、要求を格上げしたといいます >>22。
[39] 格上げは、 Mixed Content や CSP の検査よりも前に行われます。
[27] 環境設定群オブジェクトと閲覧文脈は、 非保安要求ポリシーを持ちます >>26。
[28] その値は、 「格上げする」、 「格上げしない」のいずれかです >>26。 既定値は「格上げしない」です >>26。
[41] この値は、 Content-Security-Policy: upgrade-insecure-requests
で設定されます。
[29] この値は、 navigate 以外の要求やフォームの提出において、
http: → https:
の書き換えを行うかどうかの判断に使われます。
[61] この値は閲覧文脈の作成や新しい文書オブジェクトの作成で設定されることがあります。 すなわち、フレーム外の文書の指定は、フレーム内の文書にも適用されます。
Content-Security-Policy: upgrade-insecure-requests[32] CSP の指令 upgrade-insecure-requests
は、被保護資源の非保安要求を格上げするべきことを示します >>31。
[34] Content-Security-Policy: ヘッダーで使うことができます
>>31。 <meta http-equiv=Content-Security-Policy>
での利用も禁止されていません。 Content-Security-Policy-Report-Only:
ヘッダーでも禁止はされていませんが意味はありません >>31。
[77] http: での利用も禁止されておらず、
処理も https: の場合と変わらないようです。
[35] enforce は、次のようにします >>31。
[40] upgrade-insecure-requests と
block-all-mixed-content を併用するべきではありません >>31。
両方が適用される場合、前者が優先されます。
Upgrade-Insecure-Requests: ヘッダー[43] Upgrade-Insecure-Requests:
ヘッダーは、
クライアントがサーバーに対して暗号化されて認証された応答を望んでいること、
CSP upgrade-insecure-requests 指令を処理できることを示すものです
>>42。
[80] 本ヘッダーは fingerprinting vector です。
[44] このヘッダーの値は、 1 です >>42。
upgrade-insecure-requests に対応していることを示します。
[49] 利用者エージェントは、 a priori insecure URL への要求で
Upgrade-Insecure-Requests: ヘッダーを送信しなければなりません
>>42。
[51] 利用者エージェントは、 potentially secure URL でそのホストが
preloadable HSTS host でなければ、要求で
Upgrade-Insecure-Requests: ヘッダーを送信しなければなりません
>>42。
[53] 利用者エージェントは、 potentially secure URL でそのホストが
preloadable HSTS host なら、要求で定期的に
Upgrade-Insecure-Requests: ヘッダーを送信するべきです
>>42。
[55] サーバーは、素の HTTP の要求で Upgrade-Insecure-Requests:
ヘッダーがあれば、要求された資源の potentially secure representation
にリダイレクトするべきです >>42。
Upgrade-Insecure-Requests:
ヘッダーがあれば、 upgrade-insecure-requests
が必要なページへの HTTP の要求を HTTPS への要求へと格上げできます >>42。[57] サーバーは、HTTPS の要求で Upgrade-Insecure-Requests:
ヘッダーがあれば、要求のホストが HSTS安全か条件付きHSTS安全の場合、
応答に Strict-Transport-Security: ヘッダーを含めるべきです
>>42。
Upgrade-Insecure-Requests:
ヘッダーがあれば、 HTTPS への要求を HTTP への要求へと格下げできます
>>42。[60] サーバーは、HTTPキャッシュを考慮して
Vary: ヘッダーに
Upgrade-Insecure-Requests を追加する必要があるかもしれません。
[46] Upgrade-Insecure-Requests: ヘッダーは、
当初 Prefer: ヘッダーの値として導入することが検討されていましたが、
HTTPキャッシュの効率に悪影響を及ぼす虞があるとして、
断念されました >>42。
[47] 次に HTTPS: ヘッダーとすることが提案され、
実際に Chrome に実装されましたが、 (驚くべきことに)
HTTPS か素の HTTP かの判断に影響を及ぼすサーバーが少なからず見つかったため、
ヘッダー名が改められました。
[1] UPGRADE: Describe a 'return=secure-representation' preference. · e524850 · w3c/webappsec ( 版) https://github.com/w3c/webappsec/commit/e524850dd6d8862712b18b43b9754ce951960cbf
[2] Re: UPGRADE: Feature detection? (Mike West 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0280.html
[3] Re: [upgrade] return=secure-representation (Mike West 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0086.html
[4] UPGRADE: Change to 'Prefer: https', which is (hopefully) not horrible ho... · a0aa404 · w3c/webappsec ( 版) https://github.com/w3c/webappsec/commit/a0aa404a84a0eca2040246fcd805980461d327ae
[5] UPGRADE: 'tls' is shorter than 'https'. · 29d07a9 · w3c/webappsec ( 版) https://github.com/w3c/webappsec/commit/29d07a99aebebd02f40a2daa9feb8425c36c5c21
[6] UPGRADE: Rename the header from `Prefer: tls` to `HTTPS: 1`. · d7d9fc0 · w3c/webappsec ( 版) https://github.com/w3c/webappsec/commit/d7d9fc0e16573455cf17d562eaff9667096e6489
[7] Integrate with UPGRADE. Fixes https://www.w3.org/Bugs/Public/show_bug.cg... · whatwg/fetch@fd90b5a ( 版) https://github.com/whatwg/fetch/commit/fd90b5afd0ff09284c2a3cd093c577d17ce06898
[8] Upgrade Insecure Requests ( 版) http://www.w3.org/TR/2015/WD-upgrade-insecure-requests-20150424/
[10] UPGRADE: 'HTTPS' header causing compatibility issues. (Mike West 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Jun/0075.html
[11] Re: UPGRADE: 'HTTPS' header causing compatibility issues. (Mike West 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0052.html
[12] UPGRADE: Rename 'HTTPS: 1' to 'Upgrade-Insecure-Requests: 1'. · w3c/webappsec@eeac392 ( 版) https://github.com/w3c/webappsec/commit/eeac3922418bfa6cb254071c74ddd962ee418c80
[13] Re: UPGRADE: 'HTTPS' header causing compatibility issues. (Mike West 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0108.html
[14] UPGRADE: Ugly first stab at a strawman. · 56a27a2 · w3c/webappsec ( 版) https://github.com/w3c/webappsec/commit/56a27a20bef8a3f8f9cf29fecf49b8163eb85afd
[15] Upgrade Insecure Requests ( ( 版)) http://www.w3.org/TR/2015/WD-upgrade-insecure-requests-20150226/
[16] Upgrade Insecure Requests ( ( 版)) https://w3c.github.io/webappsec/specs/upgrade/
[17] 1139297 – Implement CSP upgrade-insecure-requests directive ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=1139297
HSTS plus upgrade-insecure-requests is the way to go.
[19] Upgrade Insecure Requests ( 版) https://w3c.github.io/webappsec-upgrade-insecure-requests/
[21] w3c/webappsec-upgrade-insecure-requests ( 版) https://github.com/w3c/webappsec-upgrade-insecure-requests
[20] Upgrade Insecure Requests ( ( 版)) http://www.w3.org/TR/2015/CR-upgrade-insecure-requests-20151008/
[81] Allow upgrades from explicitly insecure expressions · w3c/webappsec-csp@0e81d81 ( 版) https://github.com/w3c/webappsec-csp/commit/0e81d81b64c42ca3c81c048161162b9697ff7b60
[82] [UPGRADE] passive mixed content breakage with the current variant of upgrade-insecure-requests (Peter Eckersley 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Dec/0055.html
[83] 1243586 – Implement Upgrade-Insecure-Requests HTTP Request Header Field ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=1243586
[84] Chrome だと fetch される https:
からHTTPリダイレクトで http: に飛ばされる時、
UIR が適用されないように見えます。(Fetch Standard によればその場合も
UIR が適用されるべきだと思われますが...)
[85] Proposal for a MIX Level 2 roadmap. (Mike West著, ) https://lists.w3.org/Archives/Public/public-webappsec/2017Oct/0013.html
[86] webappsec-mixed-content/proposed-level-2-roadmap.md at master · mikewest/webappsec-mixed-content () https://github.com/mikewest/webappsec-mixed-content/blob/master/proposed-level-2-roadmap.md
[87] Add MIX level 2 skeleton by estark37 · Pull Request #21 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/pull/21
Upgrade-Insecure-Requests: 1ヘッダー分の余計な転送が必要となりますが、いずれはそれも要らなくなるかもしれません。 (現状でもできるだけ削減するために HSTS の情報が使われています。) 一方で CSP指令は HTTPS に移行した Webサイトが今後も意図通り動作し続けるために、 Webブラウザーが恒久的に対応し続ける必要があります。