CSRF 対策

[37] サーバーは、 CSRF 対策のためにこのヘッダーを使うことができます。

[38] Origin: ヘッダーの値がサーバーの想定する起源でなければ、 不当な起源からの要求であり、 CSRF 攻撃のおそれがありますから、 要求を拒否することとできます。

CORS

[36] サーバーは、 CORS のためにこのヘッダーを使うことができます。

[214] CORS では別起源への要求に対する鯖 (資源) での処理モデルが規定されており、 その中で Origin: の処理方法も規定されています。 Origin: に関する部分だけを抜き出すと、次の通りです。

• [215] Origin: 欄がなければ、 CORS 処理モデルの適用範囲外です。 >>213
• [216] Origin: 欄の値は、
  • [218] cross-origin request/actual request では U+0020 SPACE で分割し、得られたそれぞれの値が大文字・小文字不区別で想定している起源と一致するかを判定します。 >>213
  • [220] preflight request では値を直接大文字・小文字不区別で想定している起源と一致するかを判定します。 (preflight request はリダイレクトに対応していないので、常に値が1つと想定しています。) >>213, >>221
  • [219] なお、ここでいう想定している起源は有限のリストである必要はありません。
• [217] 応答の Access-Control-Allow-Origin: 欄には Origin: 欄の値をそのまま使うことができます。 >>213

DNS による攻撃

[210] 鯖側では Origin: が要求元として適切な起源かどうかチェックすることになりますが、 Host: をチェックしておかないと攻撃者が不正なドメイン名を当該鯖に結びつけることで意図せぬ要求を受理させることができるとされています。

IETF

[6] draft-abarth-origin-00 - The HTTP Origin Header (2009-01-22 10:33:27 +09:00 版) http://tools.ietf.org/html/draft-abarth-origin-00

[7] (X)HTML5 Tracking (2009-09-29 23:36:58 +09:00 版) http://html5.org/tools/web-apps-tracker?from=4010&to=4011

[8] IRC logs: freenode / #whatwg / 20090821 (2009-10-12 19:18:16 +09:00 版) http://krijnhoetmer.nl/irc-logs/whatwg/20090821#l-235

[9] Security/Origin - MozillaWiki (2009-10-09 22:03:56 +09:00 版) https://wiki.mozilla.org/Security/Origin

[20] The HTTP Sec-From Header draft-abarth-origin-01 の頃は Sec-From: という名前が提案されていました。

[10] IRC logs: freenode / #whatwg / 20090929 (2009-12-02 08:29:55 +09:00 版) http://krijnhoetmer.nl/irc-logs/whatwg/20090929

[11] IRC logs: freenode / #whatwg / 20091002 (2009-12-04 00:35:25 +09:00 版) http://krijnhoetmer.nl/irc-logs/whatwg/20091002#l-620

[12] IRC logs: freenode / #whatwg / 20091204 (2009-12-27 16:46:13 +09:00 版) http://krijnhoetmer.nl/irc-logs/whatwg/20091204#l-293

[13] Security/Origin - MozillaWiki (2010-10-06 06:03:55 +09:00 版) https://wiki.mozilla.org/Security/Origin

[14] IRC logs: freenode / #whatwg / 20101109 ( (2010-11-18 23:22:34 +09:00 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20101109#l-206

[15] drafts/origin.xml at master from abarth's ietf-websec - GitHub ( (2011-02-13 13:01:41 +09:00 版)) https://github.com/abarth/ietf-websec/blob/master/drafts/origin.xml

[16] IRC logs: freenode / #whatwg / 20110815 ( (2011-08-27 15:22:54 +09:00 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20110815#l-134

[17] IRC logs: freenode / #whatwg / 20111022 ( (2011-10-23 18:08:47 +09:00 版)) 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] 隣接する起源が同じ (identical) であってはなりません。 そうなってしまう場合は片方だけ送信しなければなりません。 >>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. ( (2012-01-31 09:48:00 +09:00 版)) http://html5.org/tools/web-apps-tracker?from=6940&to=6941

[19] Widget Access Request Policy ( (2012-02-04 04:00:27 +09:00 版)) http://dev.w3.org/2006/waf/widgets-access/#dfn-origin

[192] Origin Header Proposal ( (2011-12-28 22:11:55 +09:00 版)) http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html

[194] 446344 – Implement Origin header CSRF mitigation ( (2012-02-29 23:10:51 +09:00 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=446344

[197] Chromium Blog: Security in Depth: New Security Features ( (2012-02-29 23:04:56 +09:00 版)) http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html

[198] Scheme/Host/Port: RFC 6454 and RFC 6455 ( (2012-02-16 12:42:54 +09:00 版)) 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 ( (2012-02-29 23:34:42 +09:00 版)) http://stackoverflow.com/questions/6417219/force-safari-to-include-origin-header-in-jquery-get-request

[204] AJAX - Introducing Cross-domain Request (XDR) ( (2012-02-29 23:41:40 +09:00 版)) http://msdn.microsoft.com/en-us/library/ie/dd573303(v=vs.85).aspx

[295] CORS における Origin: ヘッダーの利用については、 CORS 仕様書に規定がありました。

[303] 著者が直接 Origin: を指定することは、 XHR で禁じられていました >>123。

WHATWG

[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。