HTTP, el protocolo que se usa para ver páginas web, es un protocolo sin estado, lo que quiere decir que cada petición es independiente de las demás, así que hace falta algún mecanismo que permita relacionar todas las peticiones, es decir, las cookies.
Cuando inicias sesión en una página, digamos friendface.com, pones tu nombre de usuario y tu password y le das a enviar (eso es una petición), vas al perfil de un amigo (otra petición). Si no se relacionasen las peticiones, no podrías ver el perfil de tu amigo, porque para el servidor, al ser independientes las peticiones, no habrías iniciado sesión. Esto mismo se aplica cuando te conectas a la página del banco, a la de gmail o a cualquier cosa.
Cuando se hace la primera petición a un sitio, éste nos devuelve su respuesta, un documento HTML normalmente, junto con una identificador aleatorio que debería ser único, es decir, la cookie. En cada petición posterior a ese mismo sitio, le adjuntamos la cookie, de forma que sepa que esa petición está relacionada con la primera. Por eso precisamente no es necesario poner login y password en cada petición.
El problema en sí
Entonces tenemos que una cookie sirve para identificar todas las peticiones que se hacen bajo una sesión, de forma que se entiende que se trata de la misma persona, haciendo todas esas peticiones.
Pero, ¿y qué pasa si consigo la cookie de friendface.com de otra persona?. Efectivamente, podrías hacer peticiones a friendface.com y hacer creer al servidor de friendface.com que eres esa otra persona, teniendo acceso a toda su información.
Para evitar que las contraseñas puedan ser vistas en la red, se utilizan protocolos de cifrado (HTTPS por ejemplo) para enviarlas, pero el tráfico que se genera a partir del momento de iniciar sesión, van en claro, por lo que la cookie va en claro, permitiendo acceder a la información crítica.
Un ejemplo
Está Alice, la mujer de Bob en una cafetería con su portatil usando la wifi y decide conectarse a friendface.com. Su clave va encriptada por HTTPS, si, pero la cookie que identifica su sesión no. Trudy que es un poco travieso está también con su portatil y, puesto que ambos están usando la misma wifi y los datos viajan en claro por la red, Trudy puede robar la cookie de friendface.com de Alice y se hace pasar por ella, cotilleando las cartas de amor que le escribe a Bob y dejando comentarios en sus fotos insinuándole que se está poniendo gordo y feo.
Conclusión
La única forma de que alguien te robe las cookies, como le ha pasado a la pobre Alice, es que se cumplan una serie de requisitos
- Tanto el ladrón como tú uséis un medio compartido para conectaros.
- Que la conexión vaya en claro, es decir, no use HTTPS.
- Que haya alguien con mala idea cerca.
 |
| Maaaal! |
Lista de sitios web a evitar desde conexiones públicas:
- amazon
- basecamp
- bitly
- cisco
- cnet
- dropbox
- enom
- evernote
- flickr
- foursquare
- github
- gowalla
- hackernews
- harvest
- live
- nytimes
- pivotal
- sandiego_toorcon
- slicemanager
- tuenti
- tumblr
- wordpress
- yahoo
- yelp
¿En qué te has basado para confeccionar la lista de marras?
ResponderSuprimirLa verdad es que está bien tener información divulgativa para no técnicos sobre este tema, porque la gente parece que llega a entender que sus contraseñas deben viajar bajo HTTPS, pero nadie se preocupa una vez se ha autenticado de que las cookies no sean seguras.
Desgraciadamente, la opción de marcar las cookies como seguras (obligando a enviarlas siempre bajo SSL y evitando así que te las puedan robar) no es factible, porque implicaría que cualquier web que use cookies de sesión tenga que visitarse enteramente a través de HTTPS, y eso es algo que no va a ocurrir jamás.
Pero si que hay métodos para tratar de minimizar el riesgo. El primero es poner marcas que se puedan comprobar a posteriori dentro de la cookie. La dirección IP de origen del usuario, su User-Agent-ID, etc, que se suponen inmutables (y remarco el "suponen") y permitirían detectar un robo de cookies al comprobarlas con la conexión actual.
Pero luego aparece el problema de cómo proteger el contenido de la cookie para que no se pueda cambiar. Si ponemos la IP del usuario dentro de la cookie, el atacante que robe la cookie podría cambiarla y sustituirla por la suya propia, dando validez a la cookie para si mismo. La forma de evitar esto depende del nivel de seguridad/privacidad que deban tener los datos de la cookie. Podemos firmar digitalmente los datos que no deben modificarse, y adjuntar la firma. De esta forma aunque los datos sigan expuestos a los ojos de todos, podemos detectar modificaciones en los mismos, que no se pueden enmascarar al no disponer el atacante de la clave con la que se han firmado dichos datos. Otra opción es encriptar completamente la cookie, lo cual no sólo garantiza su integridad, sino que además sus contenidos no sean visibles.
Soluciones hay, aunque hacen que todo esto sea menos flexible. Mecanismos como estos obligan a que una sesión vaya ligada forzosamente a una localización física, y ni tan siquiera son una garantía completa (NATs, spoofing a nivel IP, IPs dinámicas...), por lo que la mayoría de las veces se prefiere la comodidad del usuario a la seguridad, amparándose en la baja probabilidad de que ocurra un ataque de este estilo.
¡Buen artículo! Existe otra forma muy típica de robo de cookies, mediante un ataque cross-site scripting (XSS). Si una página permite a sus visitantes añadir código javascript, puedes meter un script que capture el contenido de una cookie y lo envíe mediante una petición HTTP al servidor del atacante. Esto se puede arreglar usando el fag HttpOnly, o mejor todavía, impidiendo hacer XSS.
ResponderSuprimirEn cualquier caso, solucionar el problema de raiz queda en manos de la propia página web.
Jaime, si compartes red, y puedes capturar peticiones, entonces ya puedes emular ese "checksum", porque utilizáis la misma IP, y puedes conocer user agent. Lo hace más laborioso, pero es igualmente fácil.
ResponderSuprimirYo cuando he programado sesiones, usaba una "pseudofirma". Toda la cookie en base64, diferentes campos separados por ":". Uno contiene el id de usuario, y otro un checksum de distintos datos concatenados, entre ellos una clave privada que el atacante no puede conocer.
¿Y si los navegadores contaran con un sistema criptográfico asimétrico para firmar cookies? De esta forma, si una cookie no estuviera firmada por el navegador autorizado (identificado por su clave pública), no se podría utilizar.
Jaime, la lista es básicamente la misma que la lista de addons que vienen con el firesheep, es decir, aquellos sitios de los cuales se puede capturar la cookie e inyectarla sin saber NADA. Puedes añadirte más addons, simplemente con el nombre de la cookie y poco más.
ResponderSuprimirEn cuanto a otros métodos que propones, está muy bien, pero la realidad es que las cosas no son así, por lo que más vale prevenir.
A robar carteras!
ResponderSuprimir