Subdomain.example.com può impostare un cookie che può essere letto da example.com?

Semplicemente non riesco a credere che sia così difficile da determinare.

Anche dopo aver letto le RFC, non mi è chiaro se un server su subdomain.example.com può impostare un cookie che può essere letto da example.com.

subdomain.example.com può impostare un cookie il cui attributo Dominio è .example.com. RFC 2965 sembra dichiarare esplicitamente che un tale cookie non verrà inviato a example.com, ma poi dice anche che se si imposta Domain = example.com, un punto viene anteposto, come se si dicesse .example.com. Nel loro insieme, questo sembra dire che se return.com restituisce imposta un cookie con Domain = example.com, non recupera quel cookie! Non può essere giusto.

Qualcuno può chiarire quali sono veramente le regole?

Citando dallo stesso RFC2109 hai letto:

       * Un Set-Cookie da request-host x.foo.com per Domain = .foo.com sarebbe
         essere accettato.

Quindi subdomain.example.compuò impostare un cookie per .example.com. Fin qui tutto bene.

       Le seguenti regole si applicano alla scelta dei valori dei cookie applicabili da
       tra tutti i cookie che ha l'agente dell'utente.

       Selezione del dominio
            Il nome host completo del server di origine deve corrispondere al dominio
            l'attributo Dominio del cookie

Quindi abbiamo una corrispondenza di dominio?

   * A è una stringa FQDN e ha la forma NB, dove N è un nome non vuoto
     stringa, B ha la forma .B 'e B' è una stringa FQDN. (Quindi, xycom
     domain-match .y.com ma non y.com.)

Ma ora il example.comdominio non corrisponderebbe .example.comsecondo la definizione. Ma www.example.com(o qualsiasi altro "nome non vuoto" nel dominio) sarebbe. Questo RFC è in teoria obsoleto da RFC2965 , che ha dettato cose sul forzare un punto di riferimento per i domini sulle Set-Cookie2operazioni.

Più importante, come notato da @Tony, è il mondo reale. Per uno sguardo a ciò che stanno facendo gli agenti utente reali, vedere

NsCookieService.cpp di Firefox 3

e

Cookie_monster.cc di Chrome

Per la prospettiva in quello che i siti attuali stanno facendo, provare a giocare con wgetutilizzo --save-cookies, --load-cookiese --debugper vedere cosa sta succedendo.

Probabilmente scoprirai che in effetti la maggior parte dei siti utilizza una combinazione delle Set-Cookieprecedenti specifiche RFC con i valori "Host", implicitamente senza un punto iniziale (come fa Twitter.com ) o impostando i valori del dominio (con un punto iniziale) e reindirizzando a un server come www.example.com(come fa google.com ).

Se il browser implementa RFC 6265 , cosa che qualsiasi browser moderno dovrebbe fare a questo punto, un cookie impostato per .example.comverrà ignorato il punto iniziale (sezione 5.2.3) e il cookie verrà quindi inviato al dominio nudo e a tutti sottodomini.

Non fare affidamento su questo comportamento se si dispone di traffico significativo da browser meno recenti; questo RFC risale solo al 2011.

Non dovrebbe essere possibile. Tuttavia, come hai detto, poiché questo non è uno standard ampiamente documentato, dipende da quale software stai utilizzando.

La maggior parte dei browser moderni aderisce a un "modello di sicurezza Web" definito. Il modello governa efficacemente il comportamento dei browser in termini di sicurezza, su cose come i cookie (in particolare il modo in cui verranno rispediti a un determinato sito Web). Il modello ha anche la regola che "i browser non inviano cookie a nomi di dominio che non li hanno impostati".

Detto questo, domain.com dovrebbe essere in grado di impostare i cookie per js.domain.com. js.domain.com, tuttavia, può impostare cookie solo per se stesso. Ma tutto dipende dal browser che stai utilizzando.