¡Protegiendo Tus Cookies de Hackers y Desarrolladores Hambrientos!

Hola a todos. Bienvenidos a mi charla, Protegiendo Tus Cookies de Hackers y Desarrolladores Hambrientos. Mi nombre es Mohamad. Todos me llaman Mo. Soy un apasionado code bizarre en ING Bank en los Países Bajos. Tengo 15 años de experiencia en la industria. Somos una familia de cuatro. Tengo dos hijos. Me encanta jugar videojuegos solo y con los niños. Estoy comenzando a compartir conocimiento. Así que por eso estoy aquí hoy.

Así que hoy se trata de cookies. Así que primero echemos un vistazo al nombre de la cookie en sí. ¿Cuándo se acuñó? Así que Lou en Netscape estaba desarrollando una aplicación de comercio electrónico. Como saben, las aplicaciones de comercio electrónico necesitan un carrito. Así que un carrito, significa que debes almacenar cuáles son los artículos del carrito. Así que para hacer eso, él optó por una lógica que ahora conocemos como cookies. Así que se trataba principalmente de almacenar un pequeño fragmento de datos en los navegadores del cliente, en tu navegador cliente. Así que significa que no lo vamos a enviar al servidor. Simplemente se queda allí. Lo llamó Cookie. Y de hecho, el nombre de la cookie en sí proviene de magic cookie. Sabes, en aquel entonces, cuando dos programas querían en el entorno Unix y Linux, querían comunicarse entre sí y enviar datos. Usaban el término magic cookie para enviar este tipo de datos. Así que por eso Lou de Netscape eligió la cookie de magic cookie. Y hoy en día, conocemos la cookie.

Así que comencemos desde el principio. Entonces, ¿dónde se almacena esta cookie, dónde la almacenamos y cómo funciona? Así que cada vez que abres el navegador, vas a Google.com, vas a enviar una solicitud a Google.com, ¿verdad? Va al servidor. Genera una respuesta para ti y contiene algunos encabezados. Este es el lugar donde las cookies entran en juego, que es un encabezado, un encabezado llamado set cookie header.

Cada vez que el navegador, nuestro navegador ve, ya sabes, enviar un cookie header. Así que lo va a almacenar en algún lugar, ¿verdad? Sí. Hay un almacenamiento de cookies, del cual voy a hablar más adelante. Así que la cookie está ahí. Pero después de eso, ¿qué deberíamos hacer con esa? Así que significa que en la siguiente solicitud, en las solicitudes que vienen después de esa, esas cookies deberían incluirse en la solicitud también, porque acabamos de almacenar algo en nuestra máquina. Deberíamos enviarlo al servidor. Solo imagina que es un token.

Así que la solicitud, cada vez que enviamos la solicitud, en realidad el navegador envía la solicitud, incluye algunos encabezados nuevamente. Uno de esos encabezados es el cookie header. Así que cada vez que nuestro servidor ve el cookie header, puede interactuar en consecuencia. Tal vez sea un token de autenticación y así sucesivamente. Así que sabemos cómo funciona la cookie y dónde están los lugares que estamos enviando eso. Significa que dentro de la solicitud y dentro de la respuesta.

Pero ¿cómo lo almacena el navegador? Hay un almacenamiento de cookies en tu máquina. Imagina que alguien tiene acceso no autorizado a tu máquina. Así que significa que pueden robar esos archivos de cookies y luego pueden realizar un ataque como una fijación de sesión o secuestro de sesión. Así que veamos cómo funciona eso. Si voy a esta carpeta exactamente, significa que en tu Mac, por ejemplo, usuario, tu nombre de usuario, biblioteca y luego soporte de aplicaciones. Puedes ver una carpeta llamada Google o Firefox. Así que Google y luego ve a Chrome, tu perfil predeterminado. Significa que tu perfil predeterminado u otros perfiles tendrían diferentes nombres. Voy a ver un archivo llamado cookies. Genial. Es un documento sin ninguna extensión. Voy a dejarlo en algún lugar porque podemos revisarlo juntos. Así que simplemente lo dejé, dejé la cookie en esta carpeta. Así que déjame abrir mi base de datos favorita.

Así que si voy a las tablas, puedo ver cookies, clic derecho, ver tabla, voilà. Todas mis cookies están aquí. Todos los sitios web que visité y todos los nombres y valores de las cookies. Pero como ves, el valor está encriptado. Para Chrome, está encriptado. Para Firefox, no está encriptado. Hay un artículo completo allí, que más adelante puedes revisar. Está en mi MindMap. Más tarde compartiré el enlace a todos los MindMaps y el código fuente que vamos a revisar hoy. No te preocupes.

Así que podrías preguntarte, el valor está encriptado, pero ¿puedo desencriptarlo? Por supuesto. Incluso puedes desencriptar eso en tu máquina. Si abres cualquier terminal y usas comandos de seguridad en MacOS o en entornos Linux o Windows, hay otras formas. Algunos de ellos son valores de texto plano, que se almacenan en el archivo JSON. No te preocupes. Pero en Mac, al menos es un poco más seguro. Así que si usas comandos de seguridad, encuentras contraseña genérica, guion W, que nos muestra la contraseña, el nombre de la aplicación, ChromeStorage es un almacenamiento seguro de Chrome.

Y luego si presiono enter, me va a mostrar una clave que todos pueden usar para desencriptar esos valores que están en la base de datos DB en la base de datos SQLite de Chrome. Así que significa que el acceso no autorizado a nuestra máquina es muy peligroso y pueden encontrar todas nuestras contraseñas. Así que esta es la parte que trata sobre el acceso autorizado. Pero cuando se trata de lo que podemos asegurar, nuestra empresa tal vez haga eso, tenemos muchas herramientas para encargarnos de eso. Pero cuando se trata de la cookie en sí, deberíamos saber cómo el navegador analiza la cookie y cómo interactúa con la cookie en sí.

Entonces, ¿cuáles son los parámetros que podemos establecer para hacerla más segura y proteger nuestras cookies? Como sabes, cada vez que configuramos la cookie, hay un par de atributos que podemos establecer. Quizás el más obvio es el nombre y el valor del nombre. Es solo un nombre.

Podría ser un US ASCII y cosas así, el valor podría ser el mismo. Pero una de las cosas interesantes sobre el nombre es que puede tener algunos prefijos. Puedes verificar todos los prefijos en el módulo de desarrollador, Mozilla.org, el MDN, el loan MDN. Por ejemplo, uno de los prefijos que puedes establecer es subrayado secure.

Así que obliga a que la cookie sea segura o el otro que puedes leer en la descripción. Algunos de ellos los cubriremos hoy. Por ejemplo, subrayado HTTP es el que obliga a que la cookie tenga la propiedad HTTP only, lo cual es útil para prevenir algunos ataques. A continuación, sigamos adelante.

Por ejemplo, tengo una aplicación aquí. Déjame abrir las herramientas de desarrollador. Cookies, no tengo ninguna cookie, pero puedo hacer clic en login as Mohammed para iniciar sesión como Mohammed. Así que va a establecer la cookie para mí. Así que es simple establecer una cookie. No es gran cosa.

Déjame ver el valor de la cookie. Sí, acaba de crear un valor de cookie para mí. El valor de la cookie es este. Así que solo imagina que no lo hice, como ves, el valor en sí, son caracteres aleatorios uno al lado del otro, pero en realidad, no es aleatorio.

Déjame copiar eso e intentar decodificarlo para ver cuáles son los problemas de mi aplicación para establecer una cookie. Así que si abro Burp suite, voy al decodificador, pego mi valor. Como ves, ya lo ha detectado. Está en rojo. Así que significa que puedo decodificarlo como una URL. Bien. Puedo ver igual, igual, significa que puedo decodificarlo como un base 64 la mayoría de las veces.

Bien. Así que era un texto plano que pusieron en su cookie. Así que significa que, bien, bien. Así que puedo cambiarlo a admin en lugar de Mohammed. Puedo codificarlo como un base 64 y copiar el valor y venir aquí.

Déjame ir a la página de inicio primero. En la página de inicio, mi nombre de usuario es Mohammed. Déjame reemplazarlo con el nuevo, actualizar la página. Voila. Soy admin ahora mismo. Voila, no. Así que ese es el punto. Así que el valor es muy importante.

El siguiente atributo es domain. Domain está relacionado con qué dominio y subdominio tiene acceso a esta cookie. Por defecto, si establezco una cookie, por ejemplo, en este caso, mi cookie de autenticación si voy a uno de mis subdominios como sub.victim.local, veamos si tengo acceso a mi cookie aquí o no.

Como sabes, aquí tengo acceso a la cookie. Perfecto. Mi cookie está ahí. No hay ningún mensaje apareciendo. Hay una imagen. Por cierto, ten en cuenta que la imagen que uso en esta aplicación está detrás de autenticación. Por eso no puedes verla. Así que, OK.

En el subdominio, como ves, no puedo ver nada. Eso es lo que quería. Pero el punto es, si estableces el dominio actual, estará disponible en los subdominios también. Así que si en tu aplicación intentas establecer tu dominio así, estará disponible en tus subdominios también. O el dominio podría ser así con un punto.

Así que todos los subdominios, lo cual no pretendemos. Así que ten en cuenta, el dominio es muy importante. La ruta es el camino en el que quieres que esta cookie esté disponible. Así que en este caso, quiero que esta cookie esté disponible en toda mi aplicación. Así que la ruta es raíz. Así que respecto a la ruta, el valor por defecto es el actual. Así que significa que si no lo estableces, será tu ruta actual. Así que si es ABC, ABC, será ABC, ABC. Pero en la mayoría de las herramientas que estamos usando hoy en día en Node.js, JavaScript y demás, lo establecerán por defecto a la raíz.

Así que los otros dos que son importantes y que pueden llevar a una vulnerabilidad son expires y max age. Ambos están relacionados con la expiración de esa cookie en las máquinas de las personas. El primero, expires, tiene el formato exactamente así. La semana de la fecha, luego coma, el día del mes, el nombre del mes en tres, y la palabra para el formato de tres caracteres, y el año, y así sucesivamente. Así que para este, simplemente establece la fecha de expiración a este.

Max age y el formato no podrían ser de otra manera. Siempre es así. Y es demasiado grande. No me gusta, para ser honesto. Pero max age, es un poco diferente porque usa milisegundos y tiene prioridad sobre expires. Así que significa que expires es solo tal vez para legado, pero max age es el preferido. Si ambos aparecen, va a elegir max age.

Pero lo más importante en este caso no es expirar la cookie en las máquinas de las personas. Deberíamos expirarla también en el lado del servidor, porque tal vez alguien ya ha secuestrado nuestra cookie y pueda usarla más tarde. Así que expirar en el lado del cliente no es la única opción, seguro. Deberías expirarla también en el lado del servidor lo cual podría llevar a una vulnerabilidad. El otro es secure. Tal vez puedas adivinar también. Lo discutimos hace un par de minutos. Bajo el seguro, ¿qué hace? En realidad, hace que nuestra cookie esté disponible solo en HTTPS, no en HTTP.

De hecho, hace que nuestra cookie esté disponible solo en HTTPS, no en HTTP. Y también, si no lo configuras por defecto, sería para HTTP. Así que HTTP y HTTPS siempre ponen seguro allí para asegurarse de que tu cookie esté disponible solo en modo HTTPS, porque de lo contrario no tendrás cifrado. HTTP only es muy importante porque si tu aplicación tiene un ataque XSS, así las personas pueden acceder fácilmente a document.

cookies que revelan tus cookies en todas las aplicaciones. Así que si pongo un document.cookies en todos los sitios web, puedes ver que mi token de autenticación está allí. Pero si voy a las cookies de la aplicación y configuro HTTP only como verdadero, si intento obtener las cookies de nuevo, no está disponible. ¿Entonces qué significa?

Significa que si tengo una vulnerabilidad, vulnerabilidad XSS, y olvidé configurar HTTP only como verdadero. Así que si un atacante me envía un enlace como este, hay un código promocional gratuito para tu sitio web. Así que estoy ansioso por hacer clic en ese, ¿verdad? Como ves en el mensaje, intenta usar la inyección de la etiqueta script porque mi aplicación ahora mismo tiene una vulnerabilidad XSS. Así que el atacante te envía el mensaje, tu código promocional es free 2026. Sí, todo bien. Puedo ver el uno.

Espera un momento. ¿Cuál es nuestra cookie ahora mismo? Es solo HTTP. Déjame quitar HTTP only primero. Sí, actualiza para asegurarte de que, sí, no es solo HTTP. Si actualizo, no me deja usarlo. Es mejor iniciar sesión de nuevo. Dame un segundo. Sin cookies, sin cookies. El enlace del atacante está ahí. Simplemente se actualizó. Así que HTTP only es para prevenir todos los ataques XSS para acceder a tus cookies. Ahora mismo, no tengo ninguna cookie. Acabo de iniciar sesión. No es solo HTTP. Puedo venir aquí. Bien. Déjame usar el mismo. Perfecto. Si voy a la consola, puedo ver que puedo ver mi cookie porque de lo contrario, como ves, como recuerdas, el registro anterior no contenía nada. ¿Por qué? Porque intentaron inyectar en la etiqueta script. Así que porque mi sitio web tuvo un ataque XSS. Bien.

Sigamos adelante. Así que, sí, como ves, si tienen acceso al nombre de tu cookie, significa que pueden atacar tu sitio web usando un ataque de secuestro de sesión porque tienen tu sesión, que es de alguna manera lo mismo. Es diferente de la fijación, pero la fijación podría ocurrir si tienen acceso a tu archivo también. Así que tal vez un mismo sitio para mí es el atributo más importante que puedes configurar para una aplicación que está relacionada literalmente con el mismo sitio. Antes de llegar al mismo sitio, quiero asegurarme de que conocemos las diferencias entre mismo sitio y mismo origen. Mismo origen es el error que siempre obtenemos de vez en cuando cuando estamos llamando a la API como desarrollador front-end, desarrollador de React. ¿Qué es? Está relacionado con el origen de una URL cuando estás llamando al backend en un puerto diferente o un nombre de host diferente. El origen es la combinación de puerto, nombre de host, y esquema.

Así que puerto, nombre de host, y esquema. Entonces, en el nombre de host, podría ser www.example.com, api.example.com, frontend.com. Podría ser cualquier cosa, ¿verdad? Así que estos son lo que llamamos origen. Pero cuando se trata del sitio, es un poco diferente. El puerto no está incluido. El dominio de nivel superior está incluido, que es .com, .nl, .it, y así sucesivamente, .org. Y dominio de nivel superior más uno. Así que significa que example.com, el subdominio, www, api, y todos ellos no son considerados. El esquema, por supuesto, es parte de eso también. HTTP o solo HTTP. Así que esto es lo que llamamos mismo origen porque provienen del mismo origen.

Pero a veces se vuelve un poco complicado. Como GitHub.io, GitHub.io, si consideramos solo el nivel superior y el nivel superior más uno. Así que significa que GitHub.io, solo imagina que bajo el mismo proyecto, vamos a tener bajo el mismo dominio, que es GitHub.io. Por supuesto, vamos a tener diferentes proyectos para GitHub porque todos ellos tienen su propia página. Así que si consideramos estos dos como el origen para este dominio, va a romper otros. Así que significa que todos los proyectos pueden tener acceso a los dominios de los demás.

Así que en este caso, hay una lista de public suffix.org. Es todo el dominio de nivel superior E. Así que significa que para GitHub.io, el dominio de nivel superior no es I-O, es GitHub.io. Así que el E de nivel superior más uno sería project.github.io. Así que en este caso, porque el proyecto es parte de la URL, significa que origen. Así que significa que todo estaría bien. Así que no se consideran como el mismo origen. Si quieres revisar la lista, sí, definitivamente revisa toda la lista, que está aquí. Si busco GitHub.io, definitivamente puedo encontrarlo porque este se considera un dominio de nivel superior. Un dominio de nivel superior E es mejor decir. Así que si no configuras el mismo conjunto correctamente, vas a tener un ataque de falsificación de solicitud entre sitios y un ataque de falsificación de solicitud del lado del servidor. ¿Cómo? Porque hay diferentes valores para ellos. Uno de ellos es ninguno, lax, y estricto.

Cuando lo configuras en none, primero que nada, se requiere el secure flag, así que significa que siempre debería ser HBPS. Siempre que lo configures en none, significa que no va a verificar que dos dominios estén en el mismo sitio. ¿Qué significa esto? Significa que si vengo aquí, configuro same site en none y secure en true. Así que si intento iniciar sesión rápidamente, voy a iniciar sesión para ver mi cookie. Mi cookie, como ves, es same site es nothing y secure es nothing. Por cierto, ten en cuenta que siempre que same site es none, se va a considerar por defecto lax. Ahora es secure también. Solo imagina que un atacante quiere atacar mi aplicación obteniendo uno de los recursos que está bajo autenticación, que es mi imagen. Veamos si el sitio web del atacante attacker.local puede tener acceso a ese recurso. Esperemos la respuesta mientras tanto. Así que esto es none. Se requiere el secure flag y el sistema de seguimiento entre sitios, del cual te hablaré en un momento. Así que significa que el atacante podría obtener algunos de mis recursos, que están detrás de la autenticación. No me gusta. Así que esto es none.

Así que el otro es lax. Si lo configuras en lax, va a ser un poco más relajado. Pero déjame mostrarte también un strict. Así que si intento iniciar sesión con un strict. Ahora mismo, same site es strict. Mi aplicación funciona bien. Vamos a comprobar el atacante. El atacante no tiene acceso a mi cookie. Genial. Pero la cosa es que, siempre que lo configuras en strict, va a ser muy estricto. Así que significa que si otra aplicación como gmail.com, solo imagina que esto es gmail.com. Ponen un enlace a tu aplicación como este. Si hago clic en ese, como ves en la solicitud inicial, no tengo acceso a mi cookie. Mira, la diferencia entre estos dos. Ambos tienen la imagen.

Porque estoy detrás de la autenticación y la imagen no es la primera solicitud que estamos enviando al servidor. Así que strict es muy estricto en ese término. Así que si quieres prevenir esto, si recibo un correo electrónico de booking.com y la gente hace clic en ese enlace, abre booking.com, y no ven que están conectados. Así que es un problema.

El valor predeterminado y el valor que está allí para establecer es lax. Lax es un poco relajado, como mencioné. Ahora mismo, es lax. Si voy al sitio web del atacante, seguro que no voy a ver la imagen más. Pero intentemos la aplicación de la víctima para ver si esa funciona normalmente o no. Sí, hagamos clic en esa. Sí, mira, tengo acceso a las cookies. Las cookies están disponibles en ambos al mismo tiempo. Genial.

Así que he discutido sobre todo, y hay un artículo que quiero que revises. Es same-side cookie explained, definitivamente sugerido. Así que échale un vistazo a este, porque va a explicar por qué anteriormente el valor predeterminado de same-side era none, lo cual causó muchas vulnerabilidades. Google y la comunidad web decidieron establecer el valor predeterminado en lax. Como sabes, lax no tiene esa vulnerabilidad que acabamos de discutir, como esta, y no se siente estricto, lo que no nos lleva a establecer las cookies para la navegación de nivel superior. Increíble.

Y también, te sugiero que eches un vistazo a las configuraciones de privacidad de Chrome. Chrome configuraciones de privacidad. Si vas a cookies de terceros, sabes que las cookies de terceros, se trata de las cookies que están configuradas en none, lo cual, como ves, como mencioné, si configuras la cookie en none, otras aplicaciones pueden enviar la cookie a tu sitio web. Así que significa que si eres un servicio de publicidad, puedes rastrear a las personas que visitan diferentes sitios web. Así que si las configuras para bloquear, se bloquearán para siempre. Genial.

Y también, otro punto sobre esto, por defecto, si vas al modo incógnito también, todo por defecto está bloqueado. Así que por último, pero no menos importante, atributo partitioned. El atributo partitioned es muy genial, y realmente me gusta. Como mencioné, siempre que uses same site y lo configures en none, puedes usar esa cookie entre diferentes dominios, ¿verdad? Porque no va a verificar el mismo sitio. Porque lo voy a usar para almacenar diferentes cosas a través de diferentes sitios web. Pero hay un atributo de propiedad que puedes configurar para tus cookies, que es partitioned. Partitioned está ahí exactamente para solucionar el problema de privacidad de las cookies con none, pero sin divulgar tu información. Entonces, ¿cómo funciona? Simplemente pon el atributo partitioned para tu cookie, y lo llamamos chips, de hecho. Cookies con estados de partición independientes. No se nombra de alguna manera. Se siente más como una oración, pero chips en corto.

Así que si usas chips, va a particionar tu cookie. Va a crear una clave para tu cookie, tu cookie incrustada, y el nivel superior, el sitio web principal. Así que significa que tu cookie sería diferente en diferentes aplicaciones si la usan. Déjame mostrarte una imagen en el sandbox de privacidad en google.com, lo cual tiene más sentido para ti. Esta. Siempre que no esté particionada, siempre que no tengas propiedad partitioned, la cookie se compartiría entre la aplicación A y la aplicación B. La aplicación A, en este caso, para nosotros, es nuestra víctima. C es la cookie que configuré para la víctima también. Pero B, quiere usar B, que es el atacante, quiere usar una cookie de la aplicación víctima, lo cual, en este caso, no es aceptable. Queremos prevenir esto, o tener algún tipo de problema de privacidad, rastreando a los usuarios. Pero quieres tener esta característica para tener una cookie y almacenar algo. En este caso, puedes poner partition. Partition consideraría A y C y como una clave para tu jarra de cookies.

Así que las cookies no se compartirán entre sí. La C tiene su propia cookie. El sitio web C tiene su propia cookie cuando se carga en B. A tiene su propia cookie cuando se carga. C tiene su propia cookie cuando se carga en la aplicación A. Así que hay muchas posibilidades de que puedas usar chips.

Por ejemplo, para widgets de clima incrustados, para widgets de chat, si deseas almacenar algunas preferencias. Incluso si abro las herramientas de desarrollador aquí, no aquí, por ejemplo, porque tenemos un script incrustado de YouTube. Así que si voy a la aplicación, mi dominio, como ves, tenemos algunas cookies particionadas en este caso, que pertenecen a YouTube.

Porque acabo de cargar un iframe incrustado o un script incrustado, que carga datos de youtube.com. Así que para no hacer seguimiento de los usuarios, no sé qué hacen con esa cookie, pero en resumen, está relacionado con esa. Y también, siempre que tengas partición, el flag secure es requerido también. Esa es la historia completa de las cookies. Si quieres aprender más sobre cookies, puedes ir a mi GitHub cookies masterclass.