¿Puede subdominio.ejemplo.com establecer una cookie que se pueda leer con example.com?

Simplemente no puedo creer que esto sea tan difícil de determinar.

Incluso después de haber leído los RFC, no me queda claro si un servidor en subdominio.ejemplo.com puede establecer una cookie que se pueda leer con example.com.

subdominio.ejemplo.com puede establecer una cookie cuyo atributo de dominio es .ejemplo.com. RFC 2965 parece indicar explícitamente que dicha cookie no se enviará a example.com, pero también dice que si configura Domain = example.com, se antepone un punto, como si dijera .example.com. En conjunto, esto parece decir que si example.com devuelve establece una cookie con Domain = example.com, ¡no recupera esa cookie! Eso no puede estar bien.

¿Alguien puede aclarar cuáles son realmente las reglas?

Citando del mismo RFC2109 que lees:

       * Un Set-Cookie de request-host x.foo.com para Domain = .foo.com
         ser aceptado.

Entonces subdomain.example.compuede configurar una cookie para .example.com. Hasta aquí todo bien.

       Las siguientes reglas se aplican para elegir valores de cookies aplicables de
       entre todas las cookies que tiene el agente de usuario.

       Selección de dominio
            El nombre de host completo del servidor de origen debe coincidir con el dominio
            el atributo de dominio de la cookie

Entonces, ¿tenemos una coincidencia de dominio?

   * A es una cadena FQDN y tiene la forma NB, donde N es un nombre no vacío
     cadena, B tiene la forma .B ', y B' es una cadena FQDN. (Entonces, xycom
     coincidencias de dominio .y.com pero no y.com.)

Pero ahora example.comno coincidiría .example.comcon el dominio según la definición. Pero www.example.com(o cualquier otro "nombre no vacío" en el dominio) lo haría. Este RFC está en teoría obsoleto por RFC2965 , que dictaba cosas sobre forzar un punto líder para dominios en las Set-Cookie2operaciones.

Más importante, como lo señaló @Tony, es el mundo real. Para ver lo que los agentes de usuario reales están haciendo, vea

NsCookieService.cpp de Firefox 3

y

Cookie_monster.cc de Chrome

Para ponerlo en perspectiva en lo que los sitios reales están haciendo, trata de jugar con wgetel uso --save-cookies, --load-cookiesy --debugpara ver lo que está pasando.

Probablemente descubrirá que, de hecho, la mayoría de los sitios están utilizando alguna combinación de Set-Cookiela especificación RFC anterior con valores de "Host", implícitamente sin un punto inicial (como lo hace twitter.com ) o estableciendo valores de Dominio (con un punto inicial) y redirigiendo a un servidor como www.example.com(como lo hace google.com ).

Si el navegador implementa RFC 6265 , lo que cualquier navegador moderno debería estar haciendo en este punto, entonces un conjunto de cookies .example.comtendrá el punto inicial ignorado (sección 5.2.3), y la cookie se enviará al dominio simple y a todos subdominios

No confíe en este comportamiento si tiene tráfico significativo de navegadores antiguos; este RFC solo data de 2011.

No debería ser posible. Sin embargo, como dijiste, dado que este no es un estándar ampliamente documentado, depende de qué pieza de software estés usando.

La mayoría de los navegadores modernos se adhieren a un "modelo de seguridad web" definido. El modelo gobierna efectivamente el comportamiento de los navegadores con respecto a la seguridad, en cosas como las cookies (específicamente cómo se enviarán de regreso a un sitio web determinado). El modelo también tiene la regla de que "los navegadores no envían cookies a los nombres de dominio que no los configuraron".

Dicho esto, domain.com debería poder establecer cookies para js.domain.com. js.domain.com, sin embargo, solo puede establecer cookies por sí mismo. Pero todo esto depende de qué navegador esté utilizando.