[8] Web における混合内容とは、 HTTPS の文書から参照される HTTP のスクリプトのように、 安全なプロトコルによってもたらされた文書に含まれる安全でないプロトコル由来のデータのことをいいます。
[46] かつては混合内容も普通に用いられていましたが、 TLS を用いない素のHTTPが安全ではないとの認識が広まるにつれ、 混合内容が禁止されるようになっていきました。
[47] 現在では画像や媒体を除き、混合内容は禁止されています。 混合内容の fetch は、ネットワークエラーとなります。
[88] あるページが HTTPS (HTTP over TLS) で保護されて配送されてきたとしても、 其の表示に際して別の資源を埋め込む時に素のHTTP を使っていたら、 その Webページ全体は信頼できるとは言い切れなくなります。 特にそれがスクリプトの場合、 攻撃者によって Webページの表示全体が置き換えられる場合すらあり得ます。
[89] 混合内容制約は、 TLS で保護されているように見える Webページが、 真に保護されていることを確保するための最低限の保証と言えます。
[91] 要求は、 URL が 先験的認証済URL でなく、 Does settings prohibit mixed security contexts? が真であるとき、 混合内容です。 >>90
[92] 応答は、 unauthenticated response であって、 Does settings prohibit mixed security contexts? が真であるとき、 混合内容です。 >>90
[94] 混合内容が、 混合内容を制限する文脈に読み込まれる時、 当該文脈は RFC 6797 混合保安文脈です。 >>90
[174]
Fetch
に適用されます。
JavaScript
の
fetch
に限らず、
Webページからのネットワークアクセスほとんどすべてに適用されます。
WebSocket も適用対象に含まれます >>26, >>25。
[96]
要求が混合内容で任意選択的ブロック可能であるとは、
終点が video
か audio
であるか、
initiator が空文字列で終点が image
であるかをいいます。
>>95
[97] img
などの画像, video
, audio
,
video
や audio
の source
などが該当します。これらは従前より混合内容が比較的よく使われてきました。
それをただちにブロックすることはWeb互換性のため極めて難しいので、
当分の間の暫定的措置として混在が認められています >>95。
とはいえ混在が安全でないことは間違いなく、
理想的にはブロックするべきものであるため、
将来的にブロックできるようになることが期待されています >>95。
利用者の設定で任意選択的ブロック可能なものも含めてブロックすることができます
(>>168)。
(なお、
任意選択的ブロック可能に該当しても、他の条件によりブロックされる場合があります。)
[98] 要求が混合内容で任意選択的ブロック可能でない場合、 ブロック可能です。 >>95
[99] プラグインからのネットワークアクセスも混合内容制約の適用対象ですが、 NPAPI プラグインが直接ネットワークにアクセスする可能性があるように、 実際には擦り抜けられてしまうことがあります。 Webブラウザーはこれを防ぐべきで、 プラグインの開発者も制約に從うべきとされています。 >>95 Flash を最後に外部プラグインが廃止されることで、 この問題は解消されます。
[85]
navigation、つまり HTTPS ページから素のHTTP のページへのリンクの遷移は認められています。
しかし navigation であっても HTTPS ページ内部の
iframe
に表示させるようなものは、認められません。
[141] HTTPS から素のHTTP へのフォームの提出も基本的には認められています。 しかし Webブラウザー依存でこれを制限しても構わないことになっています (>>124)。 そのような場合古くから多くの Webブラウザーがモーダルダイアログを表示して利用者に確認していました。
[175] 利用者エージェントは、 仕様書のアルゴリズムより更に厳しい制限を課すことが認められ (というか推奨され) ています。 >>163 いくつか例示されていますが、それ以外の措置も認められるようです。
[176] そのような曖昧性を残した規定は相互運用性のため好ましくないとも思われますが、 要はすべて HTTPS で安全に輸送すれば良いということでしょう。
[177]
Strict-Transport-Security
ヘッダー (HSTS)
があるとき、
すべてをブロック可能とみなしたり、
厳密混合内容検査フラグを設定するものとみなしたりして構いません。
>>163
[178] 利用者の安全のため危険性を下げるべく、 任意選択的ブロック可能な要求を修正して構いません。 例えばクッキーその他認証トークンw除去したり、 自動的に URL scheme を格上げしてみたり、 などの措置を取り得ます。 >>163
[179] 入れ子閲覧文脈内の任意選択的ブロック可能なものをブロック可能とみなして構いません。 そうすることで混合内容が含まれてしまうおそれを排除して埋め込みできます。 >>163
[167]
Mixed Content は Webブラウザーが実装する制約で、
HTTPS 頁に素のHTTPが埋め込まれるものをエラーとするものです。
ところが従来素のHTTPで提供されてきた
Web頁を
HTTPS
に移行したい時、
ページ内にあるすべての URL
を http:
から
https:
に書き換えないといけないとすると、大規模な
Webサーバーでは困難な場合があります。
そこで
UIR
を使うと、
Mixed Content でエラーとなる以前に暗黙裡に
http:
から
https:
への読み替えがなされます。
[103] 環境設定群オブジェクト設定群について Does settings prohibit mixed security contexts? は、 真 (Prohibits Mixed Security Contexts) か偽 (Does Not Prohibit Mixed Security Contexts) を返し、 次のようにします。 >>102
[114] おおまかにいえば、親フレームに https:
のものがあれば真を返します。
[166] 要求 (>>116) や応答 (>>142) に対するアルゴリズムの他、 アドレスバー表示でも使われます。
[116] 要求要求について Should fetching request be blocked as mixed content? は、 真 (blocked) か 偽 (allowed) を返し、 次のようにします。 >>102
document
で、
要求の対象閲覧文脈の親閲覧文脈が
null
の場合、block-all-mixed-content
指令が含まれる場合、block-all-mixed-content
について
create-violation-for-global
した結果に設定します。image
で、
要求の initiator が imageset
でない場合、video
か audio
の場合、[142] 要求要求、 応答応答について Should response to request be blocked as mixed content? は、 真 (blocked) か 偽 (allowed) を返し、 次のようにします。 >>102
document
で、
要求の対象閲覧文脈の親閲覧文脈が
null
の場合、modern
の場合、image
で、
要求の initiator が imageset
でない場合、video
か audio
の場合、[162] この処理は要求に対する処理と似ています。 要求に対する処理はネットワークに送信する前に実行し、 それを通過したもののみがこちらの応答に対する処理も実行されます。 応答に対する処理は、 リダイレクトの結果やサービスワーカーが動作した場合も考慮して、 一部重複して検査が実行されています。
[101]
表示中の
Web頁が混合内容を含むかどうかは、
通例アドレスバーに表示されます。
[165]
他に開発者コンソールに詳しくエラーが表示されることがあります。
文書の厳密混合内容検査フラグが真で一般の利用者に混合内容の表示がない場合
[173] Webブラウザー利用者の設定による一部挙動の変更も認められています。
[168] 利用者エージェントは、 すべての混合内容をブロック可能とする (任意選択的ブロック可能なものもブロックする) 選択肢を利用者に提供して構いません。 その場合利用者はこれを利用することが強く推奨されます。 >>163
[170] 利用者エージェントは、 特定の Webページについて、 ブロック可能なものをブロックする決定を覆す手段を利用者に提供して構いません。 >>163
[172] 利用者エージェントは、こうした機能について、 AT 利用者のためアクセシビリティーAPI を通じても提供しなければなりません。 >>163
[63] 単数形の「Mixed Content」 を混合コンテンツ、 混在コンテンツと訳す人もいますが、 明確な誤訳です。
混在コンテンツ(Mixed Content)
[55] なぜ英語で単数形なのに日本語で複数形に訳すのか、理解に苦しむ。
[68] はてなブックマーク・ネイティブ広告 - はてなのコンテンツマーケティング支援総合サービス () http://www.hatena.ne.jp/contentmarketing/nativeads では 「はてなコンテンツマーケティング」が 「Hatena Content Marketing」 とされています。株式会社はてなでは content の「t」を「ツ」 と音訳していると思われます。
[69] 他社ではこうした事例は多くないので (なくはない)、 業界独自の慣習でもなくこの会社の人がそうしているだけ?
[73] 英語原文では「content」と単数なのがことごとく「コンテンツ」 と複数形で誤訳されています。
[75] Google は コンテンツ セキュリティ ポリシー | Web | Google Developers () https://developers.google.com/web/fundamentals/security/csp で CSP の C も「コンテンツ」 と訳しています。 「ツ」は 「t」の音訳なのかもしれません。
[71] Google、Chromeで混合コンテンツを完全にブロックする計画 | スラド IT () https://it.srad.jp/story/19/10/05/2112223/
>>72 を引用。
[76]
「コンテント」と「コンテンツ」を正しく訳し分けしないと、
技術者は
block-all-mixed-content
の正しい綴りを覚えるのに苦労することになります。
[10] SGML や XML の内容モデルにおける混合内容とは関係ありません。 混合内容の語は長年 Webブラウザーで使われるため混乱は少ないと説明されています >>90。
[84] 保安文脈は HTTPS とそれ以外を分離した上で更に HTTPS 側だけに機能を提供する、更に強い制約となっています。
[86] 当初 HTTPS と素のHTTP の混合はまったく制約なく認められていました。 Web 上では普通に行われていました。
[87] しかし IE4 など HTTPS からの素のHTTP の利用の一部を制限することがある Webブラウザーもありました。
A Web page is called mixed content if the top-level resource was retrieved through a strongly TLS protected HTTP transaction, but some dependent resources were retrieved through a weakly protected or unprotected HTTP transaction.
[6] Web Security Context: User Interface Guidelines ( ( 版)) http://www.w3.org/TR/wsc-ui/#def-mixed-content
[7] RFC 6797 - HTTP Strict Transport Security (HSTS) ( ( 版)) http://tools.ietf.org/html/rfc6797#section-2.3.1.3
[1] Mixed Content ( ( 版)) http://projects.mikewest.org/webappsec/specs/mixedcontent/
[2] webappsec/specs/mixedcontent at master · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/tree/master/specs/mixedcontent
[3] Mixed Content ( ( 版)) https://w3c.github.io/webappsec/specs/mixedcontent/
[4] Add Mixed Content hook placeholders. Broaden placeholder CSP hook. · f04393a · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/f04393aa9815dd6dce350d5d058f2bac9c4d606c
[5] Bug 22262 – Mixed content / CSP ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=22262
[11] RFC 6797 - HTTP Strict Transport Security (HSTS) ( ( 版)) http://tools.ietf.org/html/rfc6797#section-12.4
[12] Clarify MIX and CSP hooks a bit · 682f68d · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/682f68d5f0cce7f9637a8f6d9450b514ed276f9b
[13] Put MIX/CSP hooks in switch. Put second MIX check before tainting. · 567fe8a · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/567fe8ad5f1804efdefa7aa273f2a366b223c70e
[14] Mixed Content ( ( 版)) http://www.w3.org/TR/2014/WD-mixed-content-20140722/
[15] Mixed Content ( ( 版)) http://www.w3.org/TR/2014/WD-mixed-content-20140916/
[16] Mixed Content ( ( 版)) http://www.w3.org/TR/2014/WD-mixed-content-20141113/
[17] MIX: Walk the ancestor tree for powerful features. · 8d8d201 · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/8d8d201a571896267b229e9be0bd5cab222d67a2
[18] Fix the order of CSP, HSTS, Mixed Content, and Referrer https://www.w3.o... · b8c2c49 · whatwg/fetch ( 版) https://github.com/whatwg/fetch/commit/b8c2c4964c233cd3616042c04e2c14e0ff25485d
[19] Mixed Content ( ( 版)) http://www.w3.org/TR/2015/CR-mixed-content-20150317/
[20] Part2 - browsersec - Browser Security Handbook, part 2 - Browser Security Handbook - Google Project Hosting ( 版) https://code.google.com/p/browsersec/wiki/Part2#Protocol-level_encryption_facilities
[21] Re: Fetch, MSE, and MIX (Matthew Wolenetz 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Apr/0093.html
[22] Re: [MIX] Modifications to script APIs (Anne van Kesteren 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0228.html
[23] Bug 28577 – [XMLHttpRequest] Throwing SecurityError on open() call for some kind of simple errors ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=28577
If secure is false but the origin specified by the entry settings object has a scheme component that is itself a secure protocol, e.g. HTTPS, then throw a SecurityError exception and abort these steps.
[27] MIX: Clarify mixed content "resources" vs "requests". · w3c/webappsec@8732a84 ( 版) https://github.com/w3c/webappsec/commit/8732a8402ba535dc7ab05423fec251f8ceb5c8bd
[28] MIX: Explicitly update WSC-UI's 'mixed content' definition (h/t @equa… · w3c/webappsec@d9d8246 ( 版) https://github.com/w3c/webappsec/commit/d9d8246bf985bcfe78d02dfb6d0c1be6ccb3b56a
[29] MIX: Cite a source for the IE4 note. · w3c/webappsec@9b1690c ( 版) https://github.com/w3c/webappsec/commit/9b1690c0432e0320fa861c89ced452bbaf45a5ed
[30] PRB: Security Warning Message Occurs When You Browse to a Page That Contains an IFRAME Through SSL ( 版) https://support2.microsoft.com/default.aspx?scid=kb;EN-US;Q261188
[31] Eric Lawrence on Twitter: "@mikewest IE6-IE8 used a modal dialog box. http://t.co/fvK7RiZ9Pi implies that IE4/IE5 had the same. Sadly, I don't have any Win9x VMs." ( 版) https://twitter.com/ericlaw/status/469813922908758016
[32] MIX: Clarify "mixed content" vs XML's term. · w3c/webappsec@528162c ( 版) https://github.com/w3c/webappsec/commit/528162c3014ddd19cc6e04570fe19e57292ca0d1
"Mixed security context" loads happen when a web application
resource, fetched by the UA over a secure transport, subsequently
causes the fetching of one or more other resources without using
secure transport. This is also generally referred to as "mixed
content" loads (see Section 5.3 ("Mixed Content") in
[W3C.REC-wsc-ui-20100812]) but should not be confused with the same
"mixed content" term that is also used in the context of markup
languages such as XML and HTML.
NOTE: In order to provide behavioral uniformity across UA
implementations, the notion of mixed security context will
require further standardization work, e.g., to define the
term(s) more clearly and to define specific behaviors with
respect to it.
When Firefox implemented mixed content blocking, Mozilla treated
Mozilla-owned sites specially: We assumed that our coworkers would make the
necessary changes before we shipped, after we helped them understand what
was necessary, and so we didn't consider breaking any Mozilla site a risk
for shipping. That strategy worked very well for us (IIRC).
[35] Intent to Ship: Strict mixed content checking. - Google Groups ( 版) https://groups.google.com/a/chromium.org/d/msg/blink-dev/MafYMJ3zQw0/DkZdADnS3hMJ
[36] MIX: First stab at SW integration. · w3c/webappsec@e577d4d ( 版) https://github.com/w3c/webappsec/commit/e577d4d5746bd33248a7dd4dbe0db515c16f20fb
[37] MIX: Dropping the irrelevant CORS mode check from passthrough requests. · w3c/webappsec@72c2dba ( 版) https://github.com/w3c/webappsec/commit/72c2dba9b871a577c2be24101d57f71b63240974
[38] MIX: Align 'should block response?' with Fetch. · w3c/webappsec@bbe52ec ( 版) https://github.com/w3c/webappsec/commit/bbe52eca3e5c3b1c726b03c0363bf87bf4c66972
[39] MIX: Clarify blocking algorithm for passthrough requests. · w3c/webappsec@1d683bb ( 版) https://github.com/w3c/webappsec/commit/1d683bb8e9e4c60b4e51f40299c5e634eb024170
[40] MIX: Target browsing context. · w3c/webappsec@05c7c4c ( 版) https://github.com/w3c/webappsec/commit/05c7c4caf52596baab0acb85083be3a1dd710ae2
[41] Mixed Content ( 版) https://w3c.github.io/webappsec-mixed-content/
[42] w3c/webappsec-mixed-content ( 版) https://github.com/w3c/webappsec-mixed-content
[43] Mixed Content ( ( 版)) http://www.w3.org/TR/2015/CR-mixed-content-20151008/
[44] Clean up language. · w3c/webappsec-mixed-content@bb27f07 ( 版) https://github.com/w3c/webappsec-mixed-content/commit/bb27f07b05e5e385ca4a767f186870d3831cd338
[45] Update WebSocket to use Fetch's WebSocket alterations · whatwg/html@3dadbca ( 版) https://github.com/whatwg/html/commit/3dadbcad063a10b586ef52dd4b427aa339048ee7
[48] [MIX] Carveout for `127.0.0.1`? (Mike West 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0044.html
現象 : HTTPS コンテンツと HTTP コンテンツが混在するページを表示すると、Internet Explorer 6 以前で表示されていたモーダル ダイアログ ボックスではなく、情報バーが表示される。
回避策 : HTTPS ページに、HTTP プロトコルによりアドレス指定されるリソースへの参照が埋め込まれていないことを確認します。
[50] Use 'Is URL trustworthy?' rather than whitelisting 'https' and 'wss'. (mikewest著, ) https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165
[51] CfC: Republish "Mixed Content" as CR; deadline July 27th. (Mike West著, ) https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0033.html
[52] Mixed Content () https://www.w3.org/TR/2016/CR-mixed-content-20160802/
[53] Call for Exclusions: Mixed Content (Xueyuan Jia著, ) https://lists.w3.org/Archives/Public/public-webappsec/2016Aug/0000.html
[56] Remove outdated note regarding passthrough requests. (mikewest著, ) https://github.com/w3c/webappsec-mixed-content/commit/025b6c392fdf2bb367526cd8e6130a424b4c67de
[57] Remove service worker mixed content exceptions · Issue #12 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/issues/12
[58] Cleaning up 'optionally-blockable'. (mikewest著, ) https://github.com/w3c/webappsec-mixed-content/commit/2ff806843a8e634d7d47484db185b995d2d6a95c
[59] Normative definition of optionally-blockable contradicts following note · Issue #8 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/issues/8
[60] Proposal for a MIX Level 2 roadmap. (Mike West著, ) https://lists.w3.org/Archives/Public/public-webappsec/2017Oct/0013.html
[61] 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
[62] Mixed Content Level 2 (John Wilander著, ) https://lists.w3.org/Archives/Public/public-webappsec/2018Feb/0001.html
[64] CfC to transition MIX to PR. (Mike West著, ) https://lists.w3.org/Archives/Public/public-webappsec/2018Aug/0027.html
[65] Move "Mixed Content" to PR. · Issue #15 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/issues/15
[66] Merge pull request #16 from w3c/admin-stuff (wseltzer著, ) https://github.com/w3c/webappsec-mixed-content/commit/dce78c1ffb302c27170de59aa5bf359182537a3f
[67] Admin stuff by plehegar · Pull Request #16 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/pull/16
[70] Chromium Blog: No More Mixed Messages About HTTPS () https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
[77] Add MIX level 2 skeleton (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/4b68136d948df44e6d112cac2906d574b7035294
[78] Add MIX level 2 skeleton by estark37 · Pull Request #21 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/pull/21
[79] Add html output (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/d08a1927257b14169b91227c02774d5b1c27c96c
[80] Fill out Level 2 spec (#22) (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/3d3335503f68736890ea89b9bbdc3ac71533fd01
[81] Fill in level 2 security + privacy considerations (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/5e27950001ea7231563fb40e20c6f28305017d5e
[82] Add level 2 security+privacy questionnaire (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/123c78c9efcac2681ebf114353c50ed22b712c9d
[83] Update and expand Introduction (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/8ce96e12c70d6efa745b3612292bfc79f997476c
[180] Add FPWD document for MIX2 (carlosjoan91, , ) https://github.com/w3c/webappsec-mixed-content/commit/3051e22deb3c5ba4cd5f2c564e75ab21530325cf
[181] Add carlosil as editor (carlosjoan91, , ) https://github.com/w3c/webappsec-mixed-content/commit/0235c9196e8a83c25bd6adbd2ec36cd25e0abd82
[182] Add FPWD document for MIX2 by carlosjoan91 · Pull Request #24 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/pull/24
[183] Mixed Content Level 2, , https://w3c.github.io/webappsec-mixed-content/level2.html
[184] replace original level2.html file (carlosjoan91, , ) https://github.com/w3c/webappsec-mixed-content/commit/e85f5805718759b48d2e9603124c1a8ffa44e390