La Medición Cross-Site y las Cookies
Cuando visitamos cualquier sitio en internet, por ejemplo www.misitio.com, éste puede solicitar recursos (imágenes, scripts…) de su propio servidor bajo el dominio misitio.com y al mismo tiempo solicitar recursos de otros dominios diferentes antes de presentar la página al usuario en su navegador, por ejemplo los últimos tweets que hemos publicado en @misitio. A esto se le denomina origen cross-site o carga cross-site y es una parte esencial de cómo funciona Internet.Sin embargo, a la vez que que estos recursos alojados en otros dominios pueden ofrecer servicios o contenidos integrados en nuestro sitio web también se puede usar esta posibilidad para hacer un seguimiento desde estos servidores de terceros de lo que hacen los usuarios en nuestro site utilizando scripts, widgets o sencillamente pequeñas imágenes invisibles para el usuario alojadas en nuestro servidor. En este proceso el dominio de origen de estos recursos de terceros tienen la posibilidad de instalar una cookie en nuestro navegador que será la que le permitirá recopilar información del navegador según interactúa con nuestro sitio web. En muchas ocasiones este comportamiento es absolutamente licito pero en otras estos terceros están recopilando información de nuestro comportamiento sin nuestro conocimiento y/o consentimiento.
Porqué Existen las Cookies
Decimos que el protocolo HTTP es stateless lo que básicamente quiere decir que el servidor carece de memoria, es decir, no guarda información sobre quién hace la petición (HTTP request). Esto significa que cada visita a un site, incluso cada pagina nueva en el contexto de una visita, para el servidor es siempre como si fuera un nuevo usuario. Las cookies son el mecanismo del que disponemos para pasarle al servidor información que proporcione una aproximación del concepto de usuario a través de su navegador.
Siguiendo una sencilla analogía que leí hace tiempo el comportamiento de una cookie se puede asemejar al funcionamiento de una lavandería. Cuando entregamos la ropa al dependiente éste nos entregará a cambio un ticket, en nuestro caso una cookie. Ese ticket será lo que necesitaremos para recoger la ropa pasados unos días. Si cuando volvamos a la lavandería hemos perdido el ticket el dueño de la lavandería no podrá saber quienes somos ni cuales son nuestras prendas, pues el único identificador que conecta ambas cosas es ese ticket.
Si los servidores carecen de memoria entonces necesitamos algún mecanismo que nos permita cosas como persistir un carrito de la compra a lo largo de una sesión en un ecommerce, permanecer logados mientras navegamos por nuestra red social favorita o recibir recomendaciones en Amazon cuando volvemos a visitarlo después de un tiempo. En su origen las cookies se crearon como un mecanismo para poder persistir ciertos elementos en la navegación, como la cesta de la compra, a lo largo de una sesión o visita y trascender así las limitaciones de memoria de los servidores.
En función de si la necesidad de persistir la información del usuario a lo largo del tiempo se extiende más allá de la visita o finaliza al acabar ésta surgen dos tipos distintos de cookies:
Cookies de Sesión:
Son cookies cuya duración se extiende al tiempo que dura nuestra visita al sitio web y desaparecen tan pronto cerramos nuestro navegador. Las cookies de sesión se almacenan en la memoria temporal y no se guardan más allá de la sesión del usuario. Generalmente sirven para conectar los diferentes hitos de una misma sesión y, sólo en el caso de que el usuario navegue logado, podría contener información que sirva para identificar al usuario.
Cookies Persistentes:
Se trata de cookies que se almacenan en el disco duro del dispositivo hasta la fecha de expiración que se haya definido o hasta que el usuario las elimine. Generalmente se usan para identificar al usuario a lo largo de varias sesiones. Algunos usos comunes se basan en su utilidad como mecanismo para poder guardar información del comportamiento del usuario en el sitio web o para personalizar la experiencia basándonos en sus preferencias o en su perfil.
Como Se Crea Una Cookie
En realidad hay dos mecanismos diferentes por los que podemos crear un cookies, desde el servidor o desde el navegador del usuario usando JavaScript.
Cuando tecleamos la url en nuestro navegador www.misitio.com, el navegador realiza una petición HTTP al servidor donde están alojados los contenidos. El mensaje de contestación a esa petición HTTP tiene varias partes, una de ellas es la cabecera (header). En esta cabecera el servidor utiliza la instrucción Set-Cookie para instalar la cookie.
Una vez que la cookie (persistente) se ha almacenado en la memoria del navegador la próxima vez que el navegador haga una petición a uno de los servidores del mismo dominio cumpliendo todos los requisitos que se establecieron cuando instalamos la cookie en el navegador (Path, vigencia en el tiempo…) modificará la cabecera de la petición (HTTP Request) ligeramente con los siguientes datos:
Content-type: text/html
Cookie: nombre=valor
De esta manera el servidor será consciente de la presencia de una cookie llamada “nombre” cuyo valor es “valor”. Estos son los únicos parámetros que son realmente obligatorios.
La otra forma de crear una cookie es, como hemos dicho, a través de JavaScript. Para ello usamos la propiedad document.cookie que se crearía de la siguiente manera:
document.cookie = «nombreCookie=ValorCookie»
Adicionalmente podremos asignar los mismos parámetros usando JS, por ejemplo
document.cookie = «nombreCookie=ValorCookie; expires= Thu, 21 Aug 2019 20:00:00 UTC; path=/»
Luego para leer la cookie tendremos que usar
var x = document.cookie
Lo que nos devolverá todas las cookies en una cadena de texto con cada una de las cookies separadas por un punto y coma.
Técnicamente una cookie no es más que un par clave=valor (key=value) al que acompañan una serie de atributos a través de una serie de parámetros que sirven para definir cómo y cuándo se usará esa cookie.
Parámetros de una Cookie
Los parámetros de una cookie se escriben en una cadena de texto (string) donde cada parámetro se separa mediante punto y coma. Los principales parámetros son los siguientes:
- Nombre, Valor El par formado por el nombre y el valor de la cookie Set-Cookie: nombre=valor;…”.
- Expires define la duración de la vida de la cookie en el siguiente formato … expires=Mon, 01-Jan-2020 00:00:00 GMT …
- Path fija el URL Path para el que la cookie es válida. Aquellas páginas que no estén dentro de ese path no podrán tener acceso a leer esta cookie.
- Domain es un parámetro que proporciona flexibilidad sobre el parámetro Path ya que si un dominio utiliza varios servidores para ese mismo dominio permite que la cookie sea accesible a las páginas de cualquiera de esos servidores. … domain=www.misitio.com … Las cookies pueden asignarse a máquinas específicas o a un dominio entero de internet.
- Secure es un parámetro para indicar que una cookie solo debería ser utilizada bajo un servidor seguro, tal como SSL. Si fuese ese el caso el parámetro utiliza valores booleanos y se fijaría a “TRUE”.
SameSite es un parámetro más reciente en el estándar que permite a los servidores exigir que la cookie no sea enviada a una petición cross-site (donde el sitio es definido como el domino registrado) . Puede tomar dos valores:
- Strict como su propio nombre indica en este caso la regla se aplica de manera estricta, sólo enviará la cookie si y solo si la petición fue realizada por el mismo dominio que creo la cookie en su origen.
- Lax si se usa este valor las cookies del mismo sitio se retienen en solicitudes secundarias, es decir, aquellas que no modifican la URL en la barra del navegador como llamadas para cargar imágenes o iframes. pero si se enviarán cuando un usuario navegue a la URL desde un sitio externo, por ejemplo, siguiendo un enlace.
SameSite es un parámetro que ha sido promovido por Mozilla y Google desde 2016 y que Chrome empezó en teoría a empujar con fuerza a partir de Julio de este año más exactamente desde su versión 76. Como hemos visto SameSite nos permite restringir el uso de la cookie a un entorno de primera parte o un contexto “same-site”. Tenemos que aclarar qué cuando hablamos de contexto same-site nos referimos al sufijo del dominio y la parte justo delante, www.misitio.com es parte del sitio misitio.com.
En el blog de chromium en mayo de este año Google hacia el anuncio
We are making a number of upcoming changes to Chrome to enable these features, starting with modifying how cookies work so that developers need to explicitly specify which cookies are allowed to work across websites — and could be used to track users. The mechanism we use builds on the web’s SameSite cookie attribute
A partir de ahora Chrome se sumará a la batalla por el mayor control de la privacidad de los usuarios cuando navegamos por Internet. Una cookie con el valor strict sólo será accesible cuando visitemos el mismo dominio que la fijo en su origen. Esta es una medida que sirve para proteger del riesgo de CSRF.
Si el valor es puesto en lax las cookies serán accesibles a terceras partes siempre que estas usen peticiones HTTP GET pero no si lo hacen por el método POST. Esto no limita significativamente las capacidades de medición pero de nuevo aporta mayor protección ante ataques CSRF..
Como no podría ser de otra manera podemos encontrar opinionesde todo tipo sobre las intenciones del líder absoluto a la hora de mover inversión publicitaria. No podemos obviar que, de todos sus ingresos en 2017, la nada despreciable suma de 110,8 Miles de millones de dólares vinieron de la publicidad lo que, según investopedia supone un 86,78% de todos lo ingresos de la compañía.
Tanto si es movimiento provocado por las iniciativas de Apple y WebKit.org o si es una iniciativa bien intecionada en favor de un mayor control de la privacidad, como usuarios todo movimiento del sector en pos de incrementar la protección de nuestra información y del uso que hacen terceros de ella debería ser una buena noticia.
Algunos Datos Sobre el Uso de Parámetros
Según el post de MIke West en GitHub, del equipo de Google Chromium, a pesar de que las cookies, como hemos visto, ofrecen un abanico de opciones de configuración para generar entornos más seguros lo cierto es que sólo un 8,31% de las cookies generadas desde JavaScript usan el atributo HttpOnly, un 92,15% usan secure=false por defecto, y sólo un 0,06% usan el atributo SameSite . Al parecer a pesar de que el estándar permite establecer parámetros que proporcionarían un mayor control al uso de las cookies la mayor parte del sector no los usa.
Cookies de Primera y Tercera Parte
Como hemos visto cuando un navegador solicita información a un servidor lo hace a través de una petición HTTP (HTTP Request). Hemos visto también que en esa petición se puede incluir en la cabecera la información sobre la cookie del usuario. La manera más fácil de hacer que el navegador realice esta petición en la que se incluya información sobre la acción del usuario mediante la instalación de un pequeño snippet de código JavsScript que se ejecuta en el navegador del usuario (cliente).
Cuando se carga una nueva página este código se ejecuta y hace que el navegador solicite el pixel 1×1 al servidor. Si el usuario no tenía una cookie es en ese momento a través de la respuesta del servidor cuando se instalará la cookie en la memoria del navegador. Esta será la cookie que se envíe a partir de ahora en todas las peticiones nuevas del pixel de seguimiento (Tracking pixel).
Si el tracker se solicita al mismo servidor del dominio principal de la página que estamos visitando (el que está visible en la barra de navegación) entonces el identificador se guarda en una cookie de primera parte (first-party cookie). Este será el caso de las cookies que se usan con la analítica web, por ejemplo Google Anaytics.
Si por el contrario la petición se realiza a un servidor de un dominio diferente al que está visitando el usuario decimos entonces se usará una cookie de tercera parte (third-party cookie). Típicamente este es el tipo de cookies que se han venido usando en la medición del performance de las campañas publicitarias.
Técnicamente ambas cookies son exactamente iguales, sin embargo el uso que podemos hacer de cada una es diferente.
Cómo hemos visto las cookies se fijan para un uso restringido en el tiempo pero también en un dominio e incluso en un path determinado. Fuera de ese contexto las cookies no podremos acceder a la cookie. Cuando usamos un pixel 1×1 (o cualquier alternativa similar) estamos conectado el identificador con el tracker y su dominio, y es precisamente ese tracker junto a la cookie creada los que nos permiten conectar las diferentes llamadas al servidor como pertenecientes a un mismo usuario.
Al usar el mismo tracker en diversos sitios web podemos usar la misma cookie en todos ellos (cross-site tracking) permitiendo virtualmente hacer un seguimiento de ese navegador (cookie) a través de distintos dominios.
Algunos Riesgos de la Medición Cross-Site
En términos de seguridad cuando visitamos un www.misitio.com que solicita recursos de terceros las cookies tanto de misitio.com como de los terceros se añaden a la petición HTTP que misitio.com realizará al sitio terceros.com. En este proceso hay un riesgo de que la sesión que pertenece a terceros.com pueda ser utilizada por terceros de manera que resulte en un riesgo de seguridad.
A este uso abusivo se le denomina Cross-site Request Forgery (CSRF). Que, siguiendo la definición de owasp.org, es un tipo de ataque que fuerza al usuario a ejecutar acciones no deseadas dentro de una aplicación web en la que el usuario se encuentra previamente logado. CSRF realiza su “magia negra” engañando al usuario para realizar una petición maliciosa en su nombre adquiriendo los privilegios y la identidad de la víctima.
En la mayoría de los sitios online las peticiones al servidor incluyen automáticamente credenciales asociadas con el sitio web como el identificador de la sesión (cookie), la dirección IP… en este contexto en que el usuario está logado el sitio que reciba la petición no tendrá manera de distinguir si es una petición legítima realizada por el usuario o una petición falsificada en nombre del usuario.
Normalmente este tipo de ataques se producen cuando hay un cambio de estado en el servidor, como un cambio de la dirección de email o contraseña o durante un proceso de compra.
Cómo podemos ver en las estadísticas publicadas sobre el uso de CSRF según OWASP la tabla en el año 2013 este problema ocupaba el puesto 8 del top ten de problemas de seguridad en Internet
Aunque los últimos datos de 2017 el CSRF ha desaparecido del top-ten los riesgos de esta brecha de seguridad tan sólo se han reducido pero no han desaparecido. Una de las medidas que más influencia han tenido, aunque no la única, es el uso del parámetro SameSite que hemos visto más arriba
