Kann subdomain.example.com ein Cookie setzen, das von example.com gelesen werden kann?

Ich kann einfach nicht glauben, dass das so schwer zu bestimmen ist.

Selbst wenn ich die RFCs gelesen habe, ist mir nicht klar, ob ein Server unter subdomain.example.com ein Cookie setzen kann, das von example.com gelesen werden kann.

subdomain.example.com kann ein Cookie setzen, dessen Domain-Attribut .example.com ist. RFC 2965 scheint explizit anzugeben, dass ein solches Cookie nicht an example.com gesendet wird, sagt aber auch, dass, wenn Sie Domain = example.com festlegen, ein Punkt vorangestellt wird, als ob Sie .example.com sagten. Zusammengenommen scheint dies zu bedeuten, dass, wenn example.com ein Cookie mit Domain = example.com zurückgibt, dieses Cookie nicht zurückgegeben wird! Das kann nicht richtig sein.

Kann jemand klarstellen, was die Regeln wirklich sind?

Zitiert aus demselben RFC2109, den Sie gelesen haben:

       * Ein Set-Cookie vom Request-Host x.foo.com für Domain = .foo.com würde
         akzeptiert sein.

So subdomain.example.comkann ein Cookie für gesetzt werden .example.com. So weit, ist es gut.

       Die folgenden Regeln gelten für die Auswahl der zutreffenden Cookie-Werte aus
       Unter all den Cookies, die der User Agent hat.

       Domain-Auswahl
            Der vollständig qualifizierte Hostname des Ursprungsservers muss mit der Domäne übereinstimmen
            das Domain-Attribut des Cookies

Haben wir also ein Domain-Match?

   * A ist eine FQDN-Zeichenfolge und hat die Form NB, wobei N ein nicht leerer Name ist
     Zeichenfolge, B hat die Form .B ', und B' ist eine FQDN-Zeichenfolge. (Also, xycom
     Domain-Übereinstimmungen .y.com, aber nicht y.com.)

Aber jetzt example.comwürde nicht Domain-Match .example.comnach der Definition. Aber www.example.com(oder jeder andere "nicht leere Name" in der Domain) würde. Dieser RFC ist theoretisch durch RFC2965 überholt , der bestimmte Dinge zum Erzwingen eines führenden Punkts für Domänen in Set-Cookie2Operationen vorschrieb .

Wichtiger ist, wie @Tony feststellt, die reale Welt. Einen Einblick in die tatsächlichen Aktivitäten von Benutzeragenten finden Sie unter

NsCookieService.cpp von Firefox 3

und

Chrome's cookie_monster.cc

Für Perspektive in dem, was tun tatsächliche Websites, versuchen Sie mit dem Spielen wgetmit --save-cookies, --load-cookiesund --debugzu sehen , was los ist .

Sie werden wahrscheinlich feststellen, dass die meisten Websites eine Kombination Set-Cookieaus der älteren RFC-Spezifikation mit "Host" -Werten verwenden, implizit ohne einen führenden Punkt (wie bei twitter.com ) oder ohne das Festlegen von Domain-Werten (mit einem führenden Punkt) und Weiterleiten auf einen Server wie www.example.com(wie google.com ).

Wenn der Browser RFC 6265 implementiert , was jeder moderne Browser zu diesem Zeitpunkt tun sollte, .example.comwird der führende Punkt eines gesetzten Cookies ignoriert (Abschnitt 5.2.3), und das Cookie wird dann an die nackte Domäne und an alle gesendet Subdomains.

Verlassen Sie sich nicht auf dieses Verhalten, wenn Sie erheblichen Datenverkehr mit älteren Browsern haben. Dieser RFC stammt nur aus dem Jahr 2011.

Es sollte nicht möglich sein. Wie Sie sagten, hängt dies jedoch von der verwendeten Software ab, da dies kein allgemein dokumentierter Standard ist.

Die meisten modernen Browser halten sich an ein definiertes "Web-Sicherheitsmodell". Das Modell regelt effektiv das Sicherheitsverhalten von Browsern in Bezug auf Cookies (insbesondere die Art und Weise, wie diese an eine bestimmte Website zurückgesendet werden). Das Modell hat auch die Regel, dass "Browser keine Cookies an Domain-Namen senden, die diese nicht gesetzt haben."

Abgesehen davon sollte domain.com in der Lage sein, Cookies für js.domain.com zu setzen. js.domain.com kann jedoch nur Cookies für sich selbst setzen. Dies hängt jedoch davon ab, welchen Browser Sie verwenden.