Come funzionano i domini dei cookie del browser?

A causa di strani problemi relativi ai cookie di dominio / sottodominio che sto riscontrando, vorrei sapere come i browser gestiscono i cookie. Se lo fanno in modi diversi, sarebbe anche bello conoscere le differenze.

In altre parole, quando un browser riceve un cookie, quel cookie può avere un dominio e un percorso ad esso collegati. O no, nel qual caso il browser probabilmente sostituisce alcuni valori predefiniti per loro. Domanda 1: cosa sono?

Successivamente, quando il browser sta per fare una richiesta, controlla i suoi cookie e filtra quelli che dovrebbe inviare per quella richiesta. Lo fa abbinandoli al percorso e al dominio delle richieste. Domanda 2: quali sono le regole di abbinamento?

Il motivo per cui lo sto chiedendo è perché sono interessato ad alcuni casi limite. Piace:

• Sarà disponibile un cookie .example.comper www.example.com?
• Sarà disponibile un cookie .example.comper example.com?
• Sarà disponibile un cookie example.comper www.example.com?
• Sarà disponibile un cookie example.comper anotherexample.com?
• Saranno www.example.comin grado di impostare i cookie per example.com?
• Saranno www.example.comin grado di impostare i cookie per www2.example.com?
• Saranno www.example.comin grado di impostare i cookie per .com?
• Eccetera.

Aggiunto 2:

Inoltre, qualcuno potrebbe suggerire come devo impostare un cookie in modo che:

• Può essere impostato da www.example.como example.com;
• È accessibile da entrambi www.example.come example.com.

Sebbene esista RFC 2965 (che Set-Cookie2aveva già obsoleto RFC 2109 ) che dovrebbe definire il cookie al giorno d'oggi, la maggior parte dei browser non lo supporta completamente, ma si conforma alle specifiche originali di Netscape .

Esiste una distinzione tra il valore dell'attributo Dominio e il dominio effettivo: il primo è preso dal Set-Cookiecampo dell'intestazione e il secondo è l'interpretazione di quel valore dell'attributo. Secondo la RFC 2965, si dovrebbe applicare quanto segue:

• Se il campo di intestazione Set-Cookie non ha un attributo Dominio , il dominio effettivo è il dominio della richiesta.
• Se è presente un attributo Dominio , il suo valore verrà utilizzato come dominio effettivo (se il valore non inizia con un .verrà aggiunto dal client).

Avendo il dominio effettivo, deve anche corrispondere al dominio per il dominio corrente richiesto per essere impostato; altrimenti il ​​cookie verrà rivisto. La stessa regola si applica alla scelta dei cookie da inviare in una richiesta.

Mappando questa conoscenza sulle tue domande, si dovrebbe applicare quanto segue:

• I cookie con Domain=.example.com saranno disponibili per www.esempio.com
• I cookie con Domain=.example.com saranno disponibili per esempio.com
• I cookie con Domain=example.comverranno convertiti in .example.come quindi saranno disponibili anche per www.esempio.com
• Cookie con Domain=example.comsarà non disponibile per anotherexample.com
• www.example.com sarà in grado di impostare i cookie per example.com
• www.example.com sarà non essere in grado di biscotto set per www2.example.com
• www.example.com sarà non essere in grado di biscotto set per .com

E per impostare e leggere un cookie per / da www.example.com e example.com , impostarlo per .www.example.come .example.comrispettivamente. Ma il primo ( .www.example.com) sarà accessibile solo per altri domini al di sotto di quel dominio (ad esempio foo.www.example.com o bar.www.example.com ) a cui è .example.compossibile accedere anche da qualsiasi altro dominio sotto example.com (ad esempio foo. esempio.com o bar.esempio.com ).

Le risposte precedenti sono un po 'datate.

RFC 6265 è stato pubblicato nel 2011, in base al consenso del browser in quel momento. Da allora, ci sono state alcune complicazioni con i domini dei suffissi pubblici. Ho scritto un articolo che spiega la situazione attuale - http://bayou.io/draft/cookie.domain.html

Riassumendo, le regole da seguire per quanto riguarda il dominio dei cookie:

• Il dominio di origine di un cookie è il dominio della richiesta di origine.

• Se il dominio di origine è un IP, l'attributo di dominio del cookie non deve essere impostato.

• Se l'attributo del dominio di un cookie non è impostato, il cookie è applicabile solo al dominio di origine.

• Se è impostato l'attributo di dominio di un cookie,

  • il cookie è applicabile a quel dominio e a tutti i suoi sottodomini;
  • il dominio del cookie deve essere uguale o genitore al dominio di origine
  • il dominio del cookie non deve essere un TLD, un suffisso pubblico o un genitore di un suffisso pubblico.

Si può derivare che un cookie è sempre applicabile al suo dominio di origine.

Il dominio dei cookie non dovrebbe avere un punto iniziale, come in .foo.com- semplicemente usarefoo.com

Come esempio,

• x.y.z.compuò impostare un dominio cookie a se stesso o dei genitori - x.y.z.com, y.z.com, z.com. Ma no com, che è un suffisso pubblico.
• un cookie con domain = y.z.comè applicabile a y.z.com, x.y.z.com, a.x.y.z.cometc.

Esempi di suffissi pubblici - com, edu, uk, co.uk, blogspot.com,compute.amazonaws.com

Per una vasta copertura rivedere i contenuti di RFC2965 . Naturalmente ciò non significa necessariamente che tutti i browser si comportino esattamente allo stesso modo.

Tuttavia, in generale, la regola per Percorso predefinito se nessuno specificato nel cookie è il percorso nell'URL da cui è arrivata l'intestazione Set-Cookie. Analogamente, il valore predefinito per il dominio è il nome host completo nell'URL da cui è arrivato Set-Cookie.

Le regole di corrispondenza per il dominio richiedono che il dominio dei cookie corrisponda all'host a cui viene effettuata la richiesta. Il cookie può specificare una corrispondenza di dominio più ampia includendo *. nell'attributo di dominio di Set-Cookie (questa area in cui i browser possono variare). La corrispondenza del percorso (presupponendo che il dominio corrisponda) è una questione semplice che il percorso richiesto deve trovarsi all'interno del percorso specificato sul cookie. In genere i cookie di sessione sono impostati con path = / o path = / applicationName / quindi il cookie è disponibile per tutte le richieste nell'applicazione.

• Sarà disponibile un cookie per .example.com per www.example.com? sì
• Un cookie per .example.com sarà disponibile per example.com? Non lo so
• Un cookie per esempio.com sarà disponibile per www.esempio.com? Non dovrei ma ... *
• Sarà disponibile un cookie per example.com per anotherexample.com? No
• Www.example.com sarà in grado di impostare i cookie per example.com? sì
• Www.example.com sarà in grado di impostare i cookie per www2.example.com? No (tranne tramite .example.com)
• Www.example.com sarà in grado di impostare i cookie per .com? No (non è possibile impostare un cookie così in alto nello spazio dei nomi né è possibile impostarne uno per qualcosa come .it) .

*Non sono in grado di testarlo in questo momento, ma ho una vaga idea che almeno IE7 / 6 tratterà il percorso example.comcome se fosse .example.com.

L'ultimo (terzo per essere esattamente) RFC per questo problema è RFC-6265 (Obsoletes RFC-2965 che a sua volta oscura RFC-2109).

In base a ciò, se il server omette l'attributo Dominio, l'agente utente restituirà il cookie solo al server di origine (il server su cui risiede una determinata risorsa). Ma sta anche avvisando che alcuni agenti utente esistenti trattano un attributo Dominio assente come se l'attributo Dominio fosse presente e contenesse il nome host corrente (Ad esempio, se example.com restituisce un'intestazione Set-Cookie senza un attributo Dominio, questi agenti utente inviare erroneamente anche il cookie a www.example.com).

Quando l'attributo Dominio è stato specificato, verrà trattato come un nome di dominio completo (se è presente il punto iniziale nell'attributo verrà ignorato). Il server deve corrispondere al dominio specificato nell'attributo (avere esattamente lo stesso nome di dominio o essere un sottodominio di esso) per ottenere questo cookie. Più precisamente specificato qui .

Quindi, per esempio:

• l'attributo cookie Domain=.example.comè equivalente aDomain=example.com
• i cookie con tali attributi di dominio saranno disponibili per example.com e www.example.com
• i cookie con tali attributi di dominio non saranno disponibili per another-example.com
• la specifica dell'attributo cookie come Domain=www.example.comchiuderà la strada per www4.example.com

PS: la virgola finale dell'attributo Dominio farà sì che l'agente utente ignori l'attributo = (

Ho testato tutti i casi nell'ultimo Chrome, Firefox, Safari nel 2019.

Risposta a Aggiunto:

• Sarà disponibile un cookie per .example.com per www.example.com? SÌ
• Un cookie per .example.com sarà disponibile per example.com? SÌ
• Un cookie per esempio.com sarà disponibile per www.esempio.com? NO , il dominio senza carattere jolly corrisponde solo a se stesso.
• Sarà disponibile un cookie per example.com per anotherexample.com? NO
• Www.example.com sarà in grado di impostare i cookie per example.com? No , sarà in grado di impostare i cookie per ".example.com", ma non per "example.com".
• Www.example.com sarà in grado di impostare i cookie per www2.example.com? NO . Ma può impostare cookie per .example.com, a cui www2.example.com può accedere.
• Www.example.com sarà in grado di impostare i cookie per .com? NO

È noto che le RFC non riflettono la realtà.

Meglio controllare draft-ietf-httpstate-cookie , lavori in corso.

Esistono regole che determinano se un browser accetterà l'intestazione della risposta Set-header (scrittura di cookie sul lato server), regole / interpretazioni leggermente diverse per i cookie impostati tramite Javascript (non ho testato VBScript).

Quindi ci sono regole che determinano se il browser invierà un cookie insieme alla richiesta della pagina.

Esistono differenze tra i principali motori di browser nel modo in cui vengono gestite le corrispondenze di dominio e in che modo vengono interpretati i parametri nei valori del percorso. Puoi trovare alcune prove empiriche nell'articolo Come diversi browser gestiscono i cookie in modo diverso

Sono stato sorpreso di leggere la sezione 3.3.2 sul rifiuto dei cookie:

http://tools.ietf.org/html/rfc2965

Ciò significa che un browser dovrebbe rifiutare un cookie da xyzcom con dominio .z.com, perché "xy" contiene un punto. Quindi, a meno che io non stia interpretando male la RFC e / o le domande sopra, potrebbero esserci delle domande aggiunte:

Un cookie per .example.com sarà disponibile per www.yyy.example.com? No.

Un cookie impostato dal server di origine www.yyy.example.com, con dominio .example.com, avrà il valore inviato dall'agente utente a xxx.example.com? No.

Saranno www.example.comin grado di impostare i cookie per .com?

No, ma example.com.frpotrebbe essere possibile impostare un cookie per example2.com.fr. Firefox protegge da questo mantenendo un elenco di TLD: http://securitylabs.websense.com/content/Blogs/3108.aspx

Apparentemente Internet Explorer non consente ai domini di due lettere di impostare cookie, cosa che suppongo spiega perché o2.iereindirizzare semplicemente o2online.ie. Lo avevo spesso chiesto.