¿Cómo funcionan los dominios de cookies del navegador?

Debido a los problemas extraños de cookies de dominio / subdominio que estoy recibiendo, me gustaría saber cómo los navegadores manejan las cookies. Si lo hacen de diferentes maneras, también sería bueno saber las diferencias.

En otras palabras, cuando un navegador recibe una cookie, esa cookie PUEDE tener un dominio y una ruta adjunta. O no, en cuyo caso el navegador probablemente los sustituya por defecto. Pregunta 1: ¿qué son?

Más tarde, cuando el navegador está a punto de realizar una solicitud, comprueba sus cookies y filtra las que debe enviar para esa solicitud. Lo hace al compararlos con la ruta y el dominio de las solicitudes. Pregunta 2: ¿cuáles son las reglas de coincidencia?

La razón por la que pregunto esto es porque estoy interesado en algunos casos extremos. Me gusta:

• ¿Estará disponible una cookie .example.compara www.example.com?
• ¿Estará disponible una cookie .example.compara example.com?
• ¿Estará disponible una cookie example.compara www.example.com?
• ¿Estará disponible una cookie example.compara anotherexample.com?
• ¿ www.example.comPodrá configurar cookies para example.com?
• ¿ www.example.comPodrá configurar cookies para www2.example.com?
• ¿ www.example.comPodrá configurar cookies para .com?
• Etc.

Agregado 2:

Además, ¿podría alguien sugerirme cómo debo configurar una cookie para que:

• Se puede establecer con cualquiera www.example.como example.com;
• Es accesible por ambos www.example.comy example.com.

Aunque existe el RFC 2965 (que Set-Cookie2ya había obsoleto el RFC 2109 ) que debería definir la cookie hoy en día, la mayoría de los navegadores no lo admiten por completo, sino que simplemente cumplen con la especificación original de Netscape .

Hay una distinción entre el valor del atributo de dominio y el dominio efectivo: el primero se toma del Set-Cookiecampo de encabezado y el segundo es la interpretación de ese valor de atributo. De acuerdo con el RFC 2965, se debe aplicar lo siguiente:

• Si el campo de encabezado Set-Cookie no tiene un atributo de dominio , el dominio efectivo es el dominio de la solicitud.
• Si hay un atributo de Dominio presente, su valor se usará como dominio efectivo (si el valor no comienza con un ., el cliente lo agregará).

Tener el dominio efectivo también debe coincidir con el dominio solicitado actual para ser configurado; de lo contrario, la cookie será revisada. La misma regla se aplica para elegir las cookies que se enviarán en una solicitud.

Al mapear este conocimiento en sus preguntas, se debe aplicar lo siguiente:

• Cookie con Domain=.example.com estará disponible para www.example.com
• Cookie con Domain=.example.com estará disponible por ejemplo.com
• La cookie con Domain=example.comse convertirá a .example.comy, por lo tanto , también estará disponible para www.example.com
• Galleta con Domain=example.comlo que no estará disponible para anotherexample.com
• www.example.com será capaz de establecer cookies para example.com
• www.example.com se no ser capaz de conjunto de cookies para www2.example.com
• www.example.com se no ser capaz de conjunto de cookies para .com

Y para configurar y leer una cookie para / by www.example.com y example.com , configúrela para .www.example.comy .example.comrespectivamente. Pero el primero ( .www.example.com) solo será accesible para otros dominios debajo de ese dominio (por ejemplo, foo.www.example.com o bar.www.example.com ) donde .example.comtambién puede acceder cualquier otro dominio debajo de example.com (por ejemplo, foo. ejemplo.com o bar.ejemplo.com ).

Las respuestas anteriores están un poco desactualizadas.

RFC 6265 fue publicado en 2011, basado en el consenso del navegador en ese momento. Desde entonces, ha habido algunas complicaciones con los dominios de sufijos públicos. He escrito un artículo que explica la situación actual: http://bayou.io/draft/cookie.domain.html

Para resumir, las reglas a seguir con respecto al dominio de cookies:

• El dominio de origen de una cookie es el dominio de la solicitud de origen.

• Si el dominio de origen es una IP, no se debe establecer el atributo de dominio de la cookie.

• Si no se establece el atributo de dominio de una cookie, la cookie solo es aplicable a su dominio de origen.

• Si se establece el atributo de dominio de una cookie,

  • la cookie es aplicable a ese dominio y a todos sus subdominios;
  • el dominio de la cookie debe ser el mismo o principal del dominio de origen
  • el dominio de la cookie no debe ser un TLD, un sufijo público o un padre de un sufijo público.

Se puede deducir que una cookie siempre es aplicable a su dominio de origen.

El dominio de cookies no debe tener un punto inicial, como en .foo.com- simplemente usefoo.com

Como ejemplo,

• x.y.z.compuede establecer un dominio de cookie para sí mismo o los padres - x.y.z.com, y.z.com, z.com. Pero no com, que es un sufijo público.
• una cookie con domain = y.z.comes aplicable a y.z.com, x.y.z.com, a.x.y.z.cometc.

Los ejemplos de sufijos públicos - com, edu, uk, co.uk, blogspot.com,compute.amazonaws.com

Para una amplia cobertura, revise el contenido de RFC2965 . Por supuesto, eso no significa necesariamente que todos los navegadores se comporten exactamente de la misma manera.

Sin embargo, en general, la regla para la ruta predeterminada si no se especifica ninguna en la cookie es la ruta en la URL desde la que llegó el encabezado Set-Cookie. Del mismo modo, el valor predeterminado para el Dominio es el nombre de host completo en la URL desde la que llegó la cookie configurada.

Las reglas de coincidencia para el dominio requieren que el dominio de la cookie coincida con el host al que se realiza la solicitud. La cookie puede especificar una coincidencia de dominio más amplia mediante include *. en el atributo de dominio de Set-Cookie (esta área que los navegadores pueden variar). Hacer coincidir la ruta (suponiendo que el dominio coincida) es una cuestión simple de que la ruta solicitada debe estar dentro de la ruta especificada en la cookie. Por lo general, las cookies de sesión se configuran con path = / o path = / applicationName / para que la cookie esté disponible para todas las solicitudes en la aplicación.

• ¿Habrá una cookie para .example.com disponible para www.example.com? si
• ¿Habrá una cookie para .example.com disponible para example.com? No se
• ¿Habrá una cookie por ejemplo.com disponible para www.example.com? No debería pero ... *
• ¿Habrá una cookie por ejemplo.com disponible para anotherexample.com? No
• ¿Podrá www.example.com establecer cookies para example.com? si
• ¿Podrá www.example.com establecer cookies para www2.example.com? No (excepto a través de .example.com)
• ¿Podrá www.example.com establecer cookies para .com? No (no se puede configurar una cookie tan alta en el espacio de nombres ni se puede configurar una para algo como .co.uk) .

*No puedo probar esto en este momento, pero tengo una idea de que al menos IE7 / 6 trataría la ruta example.comcomo si lo fuera .example.com.

El último (tercero para ser exactamente) RFC para este problema es RFC-6265 (Obsoletes RFC-2965 que a su vez obsoletos RFC-2109).

Según esto, si el servidor omite el atributo de Dominio, el agente de usuario devolverá la cookie solo al servidor de origen (el servidor en el que reside un recurso determinado). Pero también advierte que algunos agentes de usuario existentes tratan un atributo de dominio ausente como si el atributo de dominio estuviera presente y contuviera el nombre de host actual (por ejemplo, si example.com devuelve un encabezado Set-Cookie sin un atributo de dominio, estos agentes de usuario lo harán también envía la cookie por error a www.example.com).

Cuando se haya especificado el atributo Dominio, se tratará como un nombre de dominio completo (si hay un punto inicial en el atributo, se ignorará). El servidor debe coincidir con el dominio especificado en el atributo (tener exactamente el mismo nombre de dominio o ser un subdominio del mismo) para obtener esta cookie. Más exactamente se especifica aquí .

Así por ejemplo:

• el atributo de cookie Domain=.example.comes equivalente aDomain=example.com
• las cookies con dichos atributos de Dominio estarán disponibles para example.com y www.example.com
• las cookies con dichos atributos de Dominio no estarán disponibles para otro ejemplo.
• especificar el atributo de cookie como Domain=www.example.comcerrará el camino para www4.example.com

PD: la coma final en el atributo de dominio hará que el agente de usuario ignore el atributo = (

Probé todos los casos en el último Chrome, Firefox, Safari en 2019.

Respuesta a Agregado:

• ¿Habrá una cookie para .example.com disponible para www.example.com? SI
• ¿Habrá una cookie para .example.com disponible para example.com? SI
• ¿Habrá una cookie por ejemplo.com disponible para www.example.com? NO , el dominio sin comodín solo coincide con sí mismo.
• ¿Habrá una cookie por ejemplo.com disponible para anotherexample.com? NO
• ¿Podrá www.example.com establecer cookies para example.com? NO , podrá establecer cookies para '.example.com', pero no para 'example.com'.
• ¿Podrá www.example.com establecer cookies para www2.example.com? NO . Pero puede establecer cookies para .example.com, a las que puede acceder www2.example.com.
• ¿Podrá www.example.com establecer cookies para .com? NO

Se sabe que los RFC no reflejan la realidad.

Mejor revise draft-ietf-httpstate-cookie , trabajo en progreso.

Hay reglas que determinan si un navegador aceptará el encabezado de respuesta Set-header (escritura de cookies del lado del servidor), unas reglas / interpretaciones ligeramente diferentes para el conjunto de cookies usando Javascript (no he probado VBScript).

Luego, hay reglas que determinan si el navegador enviará una cookie junto con la solicitud de la página.

Existen diferencias entre los motores principales del navegador en cómo se manejan las coincidencias de dominio y cómo se interpretan los parámetros en los valores de ruta. Puede encontrar evidencia empírica en el artículo Cómo los diferentes navegadores manejan las cookies de manera diferente

Me sorprendió leer la sección 3.3.2 sobre rechazar cookies:

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

Eso dice que un navegador debe rechazar una cookie de xyzcom con el dominio .z.com, porque 'xy' contiene un punto. Entonces, a menos que esté malinterpretando el RFC y / o las preguntas anteriores, podría haber preguntas agregadas:

¿Habrá una cookie para .example.com disponible para www.yyy.example.com? No.

¿Una cookie establecida por el servidor de origen www.yyy.example.com, con el dominio .example.com, tendrá su valor enviado por el agente de usuario a xxx.example.com? No.

¿ www.example.comPodrá configurar cookies para .com?

No, pero example.com.frpuede establecer una cookie para example2.com.fr. Firefox protege contra esto manteniendo una lista de TLD: http://securitylabs.websense.com/content/Blogs/3108.aspx

Aparentemente, Internet Explorer no permite que los dominios de dos letras establezcan cookies, lo que supongo explica por qué o2.iesimplemente redirige a o2online.ie. A menudo me preguntaba eso.