[109] Origin:
ヘッダーは、
当該要求を行う fetch の実行元の起源を表すものです。
[299] 欄値は、 起源または null
です >>290。
[300] 起源は、URL scheme、://
、ホスト、
:
、ポートで構成され (:
以降は省略可能) >>290、
起源のASCII直列化を表します。
[301] null
は、三項組で表されない起源を表します。
小文字でなければなりません。
[113] 利用者エージェントは任意の要求に Origin:
欄を含めて構いません。
>>21
[114] 一つの要求に複数の Origin:
欄を含めてはなりません。
>>21
null
[142] HTML の定義に従えば起源のASCII直列化が空文字列になることもありますが、
その場合 Origin:
の値をどうするべきかは不明確です。
[196] >>195 によれば Firefox では空文字列が null
の変わりに使われることになっています。
古い仕様ではそうだったのかもしれません。
[50]
Webブラウザーの
fetch
アルゴリズムは、
送信するHTTP要求の多くに、
HTTPヘッダー
Origin:
を付与します。
[51]
要求Origin
ヘッダーの追加は、
要求について、
次のようにします。
>>49
[298] Webブラウザーなど同一起源ポリシーで管理されたクライアントからの要求には Origin:
ヘッダーが含まれますが、
それ以外の要求には普通は Origin:
ヘッダーは含まれません。
[37] サーバーは、 CSRF 対策のためにこのヘッダーを使うことができます。
[38] Origin:
ヘッダーの値がサーバーの想定する起源でなければ、
不当な起源からの要求であり、 CSRF 攻撃のおそれがありますから、
要求を拒否することとできます。
[36] サーバーは、 CORS のためにこのヘッダーを使うことができます。
[214] CORS では別起源への要求に対する鯖 (資源) での処理モデルが規定されており、
その中で Origin:
の処理方法も規定されています。 Origin:
に関する部分だけを抜き出すと、次の通りです。
Origin:
欄がなければ、 CORS 処理モデルの適用範囲外です。 >>213Origin:
欄の値は、U+0020
SPACE
で分割し、得られたそれぞれの値が大文字・小文字不区別で想定している起源と一致するかを判定します。 >>213Access-Control-Allow-Origin:
欄には Origin:
欄の値をそのまま使うことができます。 >>213[210] 鯖側では Origin:
が要求元として適切な起源かどうかチェックすることになりますが、
Host:
をチェックしておかないと攻撃者が不正なドメイン名を当該鯖に結びつけることで意図せぬ要求を受理させることができるとされています。
[211] 例えば corp.example
と corp.invalid
があるとします。 corp.example
が corp.example
に cross-origin request を行い、 Origin: corp.example
と送ります。この時 corp.invalid
またはネットワークが不正にこの要求を
corp.example
に送りつけさせることができます。すると corp.example
は自身からの要求を (意図せず)
受け取ることになります。 corp.example
側で Host:
をチェックすれば、利用者エージェントが本当は corp.invalid
に宛てて送ろうとしていたことを認識でき、
不適切な要求として処理できます。 (cross-origin request には HTTPS のような安全な接続を使うとより安全になります。)
>>212 4.
[22] 例によって W3C や IETF で政治的なごたごたに巻き込まれて必要以上に長くかかっています。 RFC になるよりずっと先に Webブラウザーで実装が進みました。
[1] Cross-Site Request Forgery ( 版) http://crypto.stanford.edu/websec/csrf/
[2] Origin Header for CSRF Mitigation ( 版) http://crypto.stanford.edu/websec/specs/origin-header/
[3] HTML5 のナビゲーションの算法に組み込まれたみたいです。。。
[4] (X)HTML5 Tracking ( 版) http://html5.org/tools/web-apps-tracker?from=2668&to=2669
[5] ACTION-96: Origin removal (Henri Sivonen 著, 版) http://lists.w3.org/Archives/Public/public-html/2009Jan/0210.html
[6] draft-abarth-origin-00 - The HTTP Origin Header ( 版) http://tools.ietf.org/html/draft-abarth-origin-00
[7] (X)HTML5 Tracking ( 版) http://html5.org/tools/web-apps-tracker?from=4010&to=4011
[8] IRC logs: freenode / #whatwg / 20090821 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20090821#l-235
[9] Security/Origin - MozillaWiki ( 版) https://wiki.mozilla.org/Security/Origin
[20] The HTTP Sec-From Header draft-abarth-origin-01 の頃は
Sec-From:
という名前が提案されていました。
[10] IRC logs: freenode / #whatwg / 20090929 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20090929
[11] IRC logs: freenode / #whatwg / 20091002 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20091002#l-620
[12] IRC logs: freenode / #whatwg / 20091204 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20091204#l-293
[13] Security/Origin - MozillaWiki ( 版) https://wiki.mozilla.org/Security/Origin
[14] IRC logs: freenode / #whatwg / 20101109 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20101109#l-206
[15] drafts/origin.xml at master from abarth's ietf-websec - GitHub ( ( 版)) https://github.com/abarth/ietf-websec/blob/master/drafts/origin.xml
[16] IRC logs: freenode / #whatwg / 20110815 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20110815#l-134
[17] IRC logs: freenode / #whatwg / 20111022 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20111022
[107] Origin:
欄の構文は次のように定義されていました >>21。
origin = "Origin:" OWS origin-list-or-null OWS origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list origin-list = serialized-origin *( SP serialized-origin ) serialized-origin = scheme "://" host [ ":" port ] ; <scheme>, <host>, <port> from RFC 3986
[108] RFC 6454 は、 SP
区切りのリストで複数の値を指定できるとしていました
>>21。
[110] 要求がなされるまでに複数の起源が関わっている場合、 それをすべて列挙して構わない >>21 とされていました。
[112] しかし列挙の順序や鯖による解釈の方法については特に規定されていませんでした。
[118] 隣接する起源が同じであってはなりません。 そうなってしまう場合は片方だけ送信しなければなりません。 >>21
[191] fetch (>>126) の定義においてはリダイレクトの際に複数の値を Origin:
を入れることは認められていません。ただし明示的に禁じられているわけではなく、
自然に読むと複数にはならないというだけなので、実際には禁止する意図は無いかもしれません。
[222] CORS (>>213) でも鯖側の処理モデルにおいて、 リダイレクトの時に複数の値が指定され得ることに言及はされているのですが、 利用者エージェント側の処理モデル上はそうなる場合が記述されていません。
[126] fetch 操作においては、起源が呼び出し元により明示された場合、
それを Origin:
に使います。そうでない場合は「プライバシー重視」
な文脈として扱います。 >>125
[190] HTML や XHR の仕様上定義されたあらゆる HTTP 要求は fetch
操作経由で発行されるので、従ってこれを実装しているWebブラウザーからのあらゆる HTTP
要求は何らかの Origin:
欄を送出し得ることになります。
しかしよく読むといつ Origin:
欄を送出するべきかは RFC も
HTML も XHR も規定していません。明示的な起源の指定無しに fetch
が呼び出された時は null を送信しなければならない (>>126 + >>116) ということになっていますが、
これも無条件に送信することを強制する意図があるのかは怪しいです。
[193] 実際の Webブラウザーはフォームの提出や XHR などで Origin:
を送出しますが、通常の文書の navigation などでは送出しないものもあります。
[18] Web Applications 1.0 r6941 Drop old origin definitions that no longer matter. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=6940&to=6941
[19] Widget Access Request Policy ( ( 版)) http://dev.w3.org/2006/waf/widgets-access/#dfn-origin
[192] Origin Header Proposal ( ( 版)) http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
[194] 446344 – Implement Origin header CSRF mitigation ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=446344
[197] Chromium Blog: Security in Depth: New Security Features ( ( 版)) http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html
[198] Scheme/Host/Port: RFC 6454 and RFC 6455 ( ( 版)) http://www.schemehostport.com/2011/12/rfc-6454-and-rfc-6465.html
[199] javascript - Force Safari to include Origin header in jQuery GET request - Stack Overflow ( ( 版)) http://stackoverflow.com/questions/6417219/force-safari-to-include-origin-header-in-jquery-get-request
[204] AJAX - Introducing Cross-domain Request (XDR) ( ( 版)) http://msdn.microsoft.com/en-us/library/ie/dd573303(v=vs.85).aspx
[295] CORS における Origin:
ヘッダーの利用については、
CORS 仕様書に規定がありました。
[291] IETF の RFC 6454 の Origin:
の定義は実際の
Webブラウザーの実装と異なっていましたが、 IETF では手続き上改訂が難しい状況でした。
[292] Anne は、 WHATWG Fetch Standard において RFC 6454 を参照しつつもより正確な定義を含めました >>290。
[293] 2014年6月には URL Standard に URL の起源が追加され、 HTML Standard、URL Standard、Fetch Standard の3つの文書によって事実上 RFC 6454 は廃止されました >>310, >>311。
[205] Origin:
はまだ十分 interoperable に実装されていません。
別の起源への XHR+CORS POST では Chrome も Firefox
も Origin:
を送りますし、 XDR では IE
も送りますが、フォームの POST で送るのは WebKit だけです。
また、同じ起源の時に送るのも Chrome だけです。
[124] Origin:
を XMLHttpRequest
などで著者が指定することはできません >>123, >>302。
[305] Origin:
が指定された HTTP要求を、
CORS要求といいます >>306。
[309] RFC 6454 - The Web Origin Concept ( ( 版)) http://tools.ietf.org/html/rfc6454
[312] ( ( 版)) http://www.iana.org/assignments/message-headers/prov/access-control-allow-credentials
[23] Chrome 40 になって、 <meta name=referrer>
で never
や origin-when-crossorigin
を指定すると
Origin: null
が送られるようになったみたいです。
[24] Web Applications 1.0 r4011 Synchronise with the latest Origin spec rules and semantics. ( 版) https://html5.org/r/4011
[25] Web Applications 1.0 r2525 CSRF mitigation -- add Origin header to all non-GET requests. ( 版) https://html5.org/r/2525
[27] Fix #91: rename force-Origin-header flag to omit-Origin; unset it whe… · whatwg/fetch@dfb8bff ( 版) https://github.com/whatwg/fetch/commit/dfb8bff8fd180009a549527220c304f098c932ed
[29] force-Origin-header flag set for no-cors requests · Issue #91 · whatwg/fetch ( 版) https://github.com/whatwg/fetch/issues/91
[30] Align with Fetch: force-Origin-header flag is now omit-Origin-header … · whatwg/xhr@bb19040 ( 版) https://github.com/whatwg/xhr/commit/bb19040865164a76a313b27dca1fcb21849b852a
[31] remove force-origin flag · w3c/beacon@5f1a2e7 ( 版) https://github.com/w3c/beacon/commit/5f1a2e7e9250ef7cce4b1222d8b87661110d8578
[32] Re: [referrer] Should referrer policy change value of the Origin header? (Mike West 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2016Feb/0006.html
[33] Should we send an Origin header for no-cors fetches? · Issue #225 · whatwg/fetch ( ()) https://github.com/whatwg/fetch/issues/225
[34] Consider setting omit-Origin-header-flag for same origin requests · Issue #31 · whatwg/xhr ( ()) https://github.com/whatwg/xhr/issues/31
[35] 1272302 – navigator.sendBeacon doesn't set Origin header for same-origin request ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=1272302
[39] Remove request's omit-Origin-header flag (annevk著, ) https://github.com/whatwg/fetch/commit/eb89fcd54bb39e81b11c569f6ad7ba615883f7b9
[40] Fetch: remove omit-Origin-header flag (annevk著, ) https://github.com/whatwg/html/commit/1d3dd5da311ce51eeaac027cb053cf482476099a
[41] Properly set the Origin header for WebSocket requests (nox著, ) https://github.com/whatwg/fetch/commit/406c5a60595c63d323693050b45d40823933e185
[26] IETF HTML5 Meeting March 2009 - W3C Wiki () https://www.w3.org/wiki/IETF_HTML5_Meeting_March_2009
[43] Fix Origin header and "no-cors" redirects behavior (annevk著, ) https://github.com/whatwg/fetch/commit/af45ce34d6943c2a31cfa1d306d6db3b24682634
[44] "no-cors" POST and 307/308 redirects · Issue #593 · whatwg/fetch () https://github.com/whatwg/fetch/issues/593
[45] Avoid using the CORS flag to reset request's origin in redirects by annevk · Pull Request #594 · whatwg/fetch () https://github.com/whatwg/fetch/pull/594
The Cloudflare CDN identifies cache items based on the Host Header + Origin Header + Path and Query, which supports different objects using the same host header, but different origin headers
[47] Editorial: use %s ABNF notation (annevk著, ) https://github.com/whatwg/fetch/commit/e69e9c2b73b1aac124de47e8f32ee8979dfdb77a
[48] Make the Origin header honor Referrer Policy (outside of CORS) (JuniorHsu著, ) https://github.com/whatwg/fetch/commit/cc80ec58d24668413b7a3c7160d9b4d83ace7b20
[52] Make the Origin header honor Referrer Policy (outside of CORS) (JuniorHsu著, ) https://github.com/whatwg/fetch/commit/cc80ec58d24668413b7a3c7160d9b4d83ace7b20
[63] Let Origin header honor referrer policy for non CORS request by JuniorHsu · Pull Request #908 · whatwg/fetch () https://github.com/whatwg/fetch/pull/908
[64] Editorial: remove the CORS flag (annevk, , ) https://github.com/whatwg/fetch/commit/65138f3f20a80020e405c5a0fb3675abfd884013
[65] Remove the CORS flag by annevk · Pull Request #960 · whatwg/fetch () https://github.com/whatwg/fetch/pull/960