[3] Cookie 設定時の Domain 属性は、その Cookie の対象となるドメイン名を指定します。 HTTP の Set-Cookie: 応答頭欄や JavaScript の document.cookie の設定時に用いられます。

仕様書

意味

[35] Domain 属性は、クッキーが送信されることになるホストを指定します。 >>34

[36] 例えば Domain=example.com であれば、 example.com, www.example.com, www.corp.example.com のようなホストに対する HTTP 要求でクッキーが送信されます。 >>34

[37] Domain 属性がなければ、起源鯖だけにクッキーを送信するべきであることを表しています。 >>34

構文

[33] RFC 6265 における Domain 属性の構文
 domain-av         = "Domain=" domain-value
 domain-value      = <subdomain>
                       ; defined in [RFC1034], Section 3.5, as
                       ; enhanced by [RFC1123], Section 2.1

先頭の .

[38] RFC 6265 の構文では先頭の . は認められていません。また、先頭にあった場合には、 これを無視することになっています >>34, >>46。

[17] RFC 2109 の定義では、ドメイン名の先頭は . でなければならない >>14 とされていました。 また、 RFC 2965 の定義では、先頭が . でなければ利用者エージェントが . を補う >>16 とされていました。[45] 現実には先頭に . をつけたドメイン名も多々用いられています。

末尾の .

[39] RFC 6265 の構文では末尾の . (末尾の点) は認められておらず、あった場合には属性全体が無視されることになっています >>34。

IDN

[9] Cookie が定義されたのは IDN 導入の遥かに前であり、仕様上は IDN の扱いが明確になっていません。

既定値

[40] Domain 属性を省略した場合、クッキーは起源鯖にのみ送られます。 >>34

[8] Netscape の仕様では、 Domain 属性が指定されていない場合は Cookie 応答を生成したホストの名前が指定されたとみなす >>1 とされていました。 RFC 6265 ではこれは誤った動作だけど利用者エージェントによってはそうすると述べられています >>34。

[41] 例えば example.com が Domain 属性無しのクッキーを発行した場合、 example.com への要求にはこれを送信しますが、 www.example.com への要求ではこれを送信してはなりません。

[19] RFC 2109 によるとrequest-host >>20、RFC 2965 によると実効request-host >>21 になります。 その場合最初に . が付かないので、ドメイン一致するのはそのドメイン自体だけになります >>21。

[72] HTTPサーバーが Host: の検査などを十分行っておらず、 任意のドメイン名でアクセスできる状態になっていると、悪意のある者が自身の保有する DNS ドメイン名に攻撃先の IPアドレスを割り当て、利用者をそのドメイン名に誘導することで、 攻撃先サービスのクッキーを当該ドメイン名下で発行させることができるかもしれません。 そのような攻撃を防ぐため、 Domain 属性は明示的に指定するべきかもしれません。

[73] もちろん、TLS を使ったり、 Host: の検査を行ったりすることが (他のセキュリティー上の問題を防ぐためにも) 重要なことには変わりありません。

文脈

[70] セッションクッキーその他セキュリティー的に重要なクッキーでは、 Domain 属性を適切な範囲に設定するべきです >>71。

構文解析

[47] 属性値が空文字列の場合、動作は未定義ですが、 属性を無視するべきです >>46。

[48] 属性値の最初の文字が . の場合、これは無視しなければなりません >>46。

[50] 属性値が . のみならこれにより空文字列になりますが、 >>47 は適用されないので無視はされません。

[49] 小文字に変換しなければなりません >>46。

処理モデル

[59] クッキーのドメインは、 Domain 属性の構文解析結果を使って次のように決定しなければなりません >>51。

  1. [60] Domain 属性があれば、 最後の Domain 属性の値をドメインとします。 なければ、空文字列をドメインとします。
  2. [61] 利用者エージェントが public suffix を拒むよう設定されており、 ドメインが public suffix なら、
    1. [62] ドメインが正準化要求ホストと同じなら、ドメインを空文字列とします。
    2. [63] そうでないなら、クッキー全体を無視してここで終わります。
  3. [64] ドメインが空文字列でないなら、
    1. [65] 正準化要求ホストがドメインにドメイン一致しないなら、 クッキー全体を無視してここで終わります。
    2. [52] そうでないなら、
      1. [53] クッキーのホストのみフラグを設定しません。
      2. [54] クッキーのドメインをドメインに設定します。
  4. [55] そうでないなら、
    1. [56] クッキーのホストのみフラグを設定します。
    2. [57] クッキーのドメインを正準化要求ホストに設定します。

[58] >>61 で public suffix が設定依存とされているのは謎ですが、 セキュリティー上、実際には有効にしなければ危険です。 (Public Suffix List が IETF の標準でないといったような政治的な理由でしょうか。)

[12] ポート番号はクッキーの処理には影響しません。

[18] RFC 2965 では別に Port 属性が用意されていますが、 実装されませんでした。

第三者クッキー

[6] Domain で指定されたドメインに属するホストだけがそのドメインの Cookie を設定することができます。 >>1 利用者エージェントは Domain 属性の範囲外の起源鯖からのクッキーを拒否します >>34。

[42] 例えば、 foo.example.com が起源鯖の場合、 Domain=example.com や Domain=foo.example.com は認められますが、 Domain=bar.example.com や Domain=baz.foo.example.com のクッキーは無視されます。 >>34

[22] RFC 2109 では、Domain が途中に . を含まない場合や . から始まらない場合にはその Cookie を蓄積storeしてはならないとされていました >>23。[25] RFC 2965 では Domain が途中に . を含まない場合でその値が .local ではない時にその Cookie を蓄積storeしてはならないとされていました >>24。[26] 更に、 RFC 2109 では Domain が request-host とドメイン一致しない場合、 RFC 2965 では Domain が request-host の実効ホスト名とドメイン一致しない場合に、その Cookie を蓄積storeしてはならないとされていました >>23、>>24。[27] 加えて、RFC 2109 と RFC 2965 では、 request-host が IPアドレスではなく、 . を含まない文字列 H と Domain の値 D を使って HD と表せる場合に、その Cookie を蓄積storeしてはならないとされていました >>23、>>24。

TLD

[7] Domain で設定するドメイン名には少なくても2つか3つの . が含まれていなければなりません。基本的には3つ以上で、2つでもよいのは .com, .edu, .net, .org, .gov, .mil, .int の7つの gTLD だけです。 >>1

[10] FQDN であることを明示する際に foo.example. のように最後に . を付けることがありますが、これと >>4 の処理モデルや >>7 の制約との関係は仕様上明確にされていません。

歴史

Netscape Cookie

[4] 妥当な Cookie を探す際に、Cookie の Domain 属性と、 fetch しようとしている URL のドメイン名の部分とを比較します。 ここで末尾一致していれば、更に Path の比較へと進みます。 >>1 一致していなければその Cookie は妥当ではなく、HTTP 要求の Cookie: 頭欄には含まれません。

[5] ここで末尾一致tail matchingとは、 fetch しようとしているホストの完全修飾ドメイン名 (FQDN) の末尾に Domain 属性の値が一致することをいいます。 >>1

例えば、 Domain=acme.com は anvil.acme.com や shipping.crate.acme.com と一致します。 >>1

[11] 仕様上明記されていませんが、ドメイン名は大文字・小文字を区別しないので、 この一致の際も差異は無視されるものと思われます。

  • [1] Netscape Cookie: Client Side State - HTTP Cookies http://web.archive.org/web/19961125090609/http://www2.netscape.com/newsref/std/cookie_spec.html

RFC 2109 の Set-Cookie の定義

[31] RFC 2109, RFC 2965 では、利用者エージェントには異なるドメインのホストでのセッション情報の共有を可能な限り阻止するべき >>30, >>29 とのよくわからない要件が課されていました。

仕様書

  • [13] RFC 2109 (廃止済み)
    • [14] 4.2.2 Set-Cookie2 Syntax
    • [20] 4.3.1 Interpreting Set-Cookie2
    • [23] 4.3.2 Rejecting Cookies
    • [30] 8.3 Unexpected Cookie Sharing

RFC 2965 の Set-Cookie2] の定義

仕様書

  • [15] RFC 2965
    • [16] 3.2.2 Set-Cookie2 Syntax
    • [21] 3.3.1 Interpreting Set-Cookie2
    • [24] 3.3.2 Rejecting Cookies
    • [29] 7.3 Unexpected Cookie Sharing

関連

[28] RFC 2109、RFC 2965 では利用者エージェントが返送する時に Cookie: に $Domain 属性として含めることになっていました。

メモ

[2] document.cookie の覚え書き - Ci.nsIZIGOROu - Mozilla 拡張機能勉強会 ( 版) http://moz-addon.g.hatena.ne.jp/ZIGOROu/20081001/1222845305

現在 test.example.com で実行してるとして、

document.cookie = "Z=1";
alert(document.cookie);
document.cookie = "Z=2;domain=example.com";
alert(document.cookie);
document.cookie = "Z=3;domain=test.example.com";
alert(document.cookie);
は IE6, 7 の場合、最終的に "Z=3;Z=2" となるのだが、Fx3, Safari だと、"Z=1;Z=2;Z=3" となる。

domain が省略された場合、test.example.com 相当で設定したとされるべきだと思うんだけど。

と思ったら、domain パラメータの挙動について見ている所が netscape の決めた奴と言う古い奴見てた事が判明。

Domain=domain
Optional. The Domain attribute specifies the domain for which the cookie is valid. An explicitly specified domain must always start with a dot.

RFC 2109 - 4.2.2 Set-Cookie Syntax

つまり、指定するなら "." から開始しないとだめぽって事。

省略した場合の挙動は、

Domain Defaults to the request-host. (Note that there is no dot at the beginning of request-host.)

RFC 2109 - 4.3.1 Interpreting Set-Cookie

"." を先頭につけないのが正しいと。

まぁこれらの結果分かるのは、domain 指定がある場合、別々の物として key-value のペアが管理されますよと考えられると。

この挙動、IEとそれ以外でだいぶ異なるみたいなので注意

[43] 252342 – fix cookie domain checks to not allow .co.uk ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=252342

[44] draft-pettersen-dns-cookie-validate-05 - Enhanced validation of domains for HTTP State Management Cookies using DNS ( ( 版)) http://tools.ietf.org/html/draft-pettersen-dns-cookie-validate-05

[66] draft-pettersen-dns-cookie-validate-05 - Enhanced validation of domains for HTTP State Management Cookies using DNS ( ( 版)) http://tools.ietf.org/html/draft-pettersen-dns-cookie-validate-05

[67] draft-pettersen-dns-cookie-validate-05 - Enhanced validation of domains for HTTP State Management Cookies using DNS ( ( 版)) http://tools.ietf.org/html/draft-pettersen-dns-cookie-validate-05

[68] RFC 2964 - Use of HTTP State Management ( ( 版)) http://tools.ietf.org/html/rfc2964#section-3.2

[69] Issue 56211 - chromium - chrome.cookies fails for localhost domains - An open-source project to help move the web forward. - Google Project Hosting ( 版) https://code.google.com/p/chromium/issues/detail?id=56211

[74] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes, https://groups.google.com/a/chromium.org/g/blink-dev/c/x3DY-PuZhNw