Domain

Domain 属性 (Cookie)

[3] Cookie 設定時の Domain 属性は、その Cookie の対象となるドメイン名を指定します。 HTTPSet-Cookie: 応答頭欄JavaScriptdocument.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.comDomain 属性無しのクッキーを発行した場合、 example.com への要求にはこれを送信しますが、 www.example.com への要求ではこれを送信してはなりません。

[19] RFC 2109 によるとrequest-host >>20RFC 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] >>61public suffix が設定依存とされているのは謎ですが、 セキュリティー上、実際には有効にしなければ危険です。 (Public Suffix ListIETF の標準でないといったような政治的な理由でしょうか。)

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

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

第三者クッキー

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

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

[22] RFC 2109 では、Domain が途中に . を含まない場合や . から始まらない場合にはその Cookie蓄積 (store) してはならないとされていました >>23
[25] RFC 2965 では Domain が途中に . を含まない場合でその値が .local ではない時にその Cookie蓄積 (store) してはならないとされていました >>24
[26] 更に、 RFC 2109 では Domainrequest-hostドメイン一致しない場合、 RFC 2965 では Domainrequest-host実効ホスト名ドメイン一致しない場合に、その Cookie蓄積 (store) してはならないとされていました >>23>>24
[27] 加えて、RFC 2109RFC 2965 では、 request-hostIPアドレスではなく. を含まない文字列 HDomain の値 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 の制約との関係は仕様上明確にされていません。

歴史

RFC 2965 の Set-Cookie2] の定義

仕様書

関連

[28] RFC 2109RFC 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