it-swarm-es.com

¿Puede proteger una aplicación web de FireSheep sin usar SSL?

Suponga que desea otorgar acceso privilegiado a algunos usuarios web a su sitio web, pero que no puede (o no desea) ofrecer SSL a todos ellos, al menos después de la página de inicio de sesión inicial.

En este caso, ¿hay alguna forma de administrar la sesión del usuario que anule FireSheep, pero que no cree una experiencia de usuario dolorosa?

19
Falkayn

En principio, es posible que pueda defenderse de los ataques pasivos. Pero en la práctica no es trivial y no es una gran solución.

En principio, puede escribir su propio código de cifrado en Javascript para cifrar todo en el lado del cliente (en Javascript). Lo primero que se encuentra es que tiene un rendimiento deficiente, porque la criptografía en Javascript es sustancialmente más lenta que la criptografía nativa del navegador. La reacción natural es sugerir encriptar solo los datos más sensibles, por ejemplo, solo las contraseñas del usuario. Sin embargo, esto es muy difícil de hacer bien y tiene muchas trampas sutiles:

  1. Si no está cifrando las cookies, es vulnerable al secuestro de la sesión y no ha ganado nada. Y no es fácil cifrar las cookies u otros encabezados HTTP de Javascript. Por lo tanto, probablemente se verá obligado a terminar inventando su propio método de autenticación de usuario y usar algo que no sean cookies (algo casero) para la administración de sesiones, lo cual es un montón de trabajo y fácil de equivocarse.

  2. Si encripta solo la contraseña, entonces puede ser vulnerable a ataques CSRF. Un espía aún puede ver todo el contenido de la página y, en particular, si se incluyen tokens CSRF en el enlace, entonces el espía puede ver todos los tokens CSRF y montar un ataque CSRF. Es posible defenderse de esto con suficiente esfuerzo, pero requiere aún más trabajo tanto en el cliente como en el servidor, y es complicado hacerlo bien.

  3. Si los usuarios pueden iniciar sesión en su sitio usando su cuenta de Facebook, dado que usted no controla Facebook, no puede evitar que un fisgón robe su cuenta de Facebook y luego inicie sesión en su sitio.

  4. Aún eres vulnerable a los ataques man-in-the-middle (ataques activos) que modifican el contenido de la página. No sería muy difícil desde el punto de vista técnico modificar Firesheep para que utilice el secuestro de ARP, los ataques de carrera u otros métodos para insertarse como un intermediario y modificar todo el contenido de la página. Entonces se pierde la seguridad, ya que el atacante puede insertar Javascript malicioso que actúa como un keylogger o roba las credenciales de autenticación.

  5. Debe tener cuidado de no perder el beneficio del almacenamiento en caché.

Ahora no digo que sea imposible. Es casi seguro que no lo es. Es casi seguro que sea posible crear un sitio web y una solución que evite la mayoría de los ataques pasivos. Pero será complejo y no trivial. Eso significa que necesitará una experiencia considerable en seguridad para construirlo, y aún existe una posibilidad no trivial de que arruine algo. También significa que el resultado será caro. Y la seguridad es inherentemente limitada, cualquier esquema será solo una solución/mitigación parcial, por lo que el valor es limitado. No creo que sea una buena compensación.

Si desea leer acerca de los intentos de última generación para defenderse de las escuchas sin el uso de SSL, aquí tiene un gran recurso para usted:

También me gustaría compartir con ustedes algunos recursos sobre cómo hacer que SSL funcione bien:

SSL no es gratuito, pero también tenga en cuenta que las personas a veces asumen que el impacto en el rendimiento de SSL será peor de lo que realmente es.

7
D.W.

Puede evitar el Firesheep actual a través de algún esquema de "seguridad a través de la oscuridad" que involucre autenticación a través de la administración dinámica de sesiones como se discutió aquí . Puede utilizar "Autenticación implícita" ( RFC 2617 ), pero sigue siendo vulnerable a un ataque MITM, degrada la experiencia del usuario y requiere que el servidor almacene su contraseña (o una contraseña equivalente) en claro .

Pero evitar SSL/TLS no solucionaría los dos problemas fundamentales que sin el cifrado: (1) todo el contenido privado se comparte al aire libre y (2) un atacante determinado podría resolver su esquema y derrotarlo.

Vea algunos ejemplos lindos de ataques activos, eliminación de mitos sobre penalizaciones de rendimiento y consejos específicos sobre la implementación de SSL desde EFF: Cómo implementar HTTPS correctamente . Tenga en cuenta también la meta discusión de Stack Overflow sobre por qué no se ha corregido en Stack Overflow (todavía).

Tenga en cuenta que la exposición de los sitios comunes es peor de lo que pensé inicialmente. P.ej. tenga en cuenta esta arruga como el autor de Firesheep explica en una gran publicación

No puede simplemente evitar visitar los sitios que están siendo atacados aquí. En la actualidad, existe una enorme cantidad de contenido mixto en la web, como el botón "Me gusta" de Facebook, el botón "Digg It" de Digg, los widgets de Twitter e incluso imágenes incrustadas que se alojan en Flickr u otros sitios para compartir fotos. Cada vez que accede a cualquier página web que incluye cualquiera de estos contenidos, su navegador también envía las cookies de autenticación que tiene con la solicitud para desplegar el widget.

Puede al menos corregir los errores que analiza allí (¡como invalidar las cookies de sesión cuando un usuario cierra la sesión!).

También puede asesorar a sus usuarios sobre cómo protegerse hasta cierto punto de estos ataques de "secuestro lateral", p. Ej. para usar una VPN o encontrar una red wifi WPA2 (pero consulte los problemas de WPA2 aquí ).

Gracias a @ D.W. para obtener un enlace al enfoque provisional mejor pensado que he visto: SessionLock Lite de Ben Adida. Al menos previene secuestros persistentes por parte de atacantes pasivos: Benlog "mantén tus manos fuera de las cookies de sesión . No se detenga allí: diseñe una implementación de SSL ...

10
nealmcb

Sin lugar a dudas, la respuesta es [~ # ~] no [~ # ~] . Debe tener una capa de transporte completamente segura en la que transmitir su identificación de sesión. En ningún momento se puede transmutar esta identificación de sesión a través de una conexión insegura, esto sería una violación de OWASP A9 - Protección de la capa de transporte insuficiente

8
rook

Estoy de acuerdo con la respuesta de Rook. Sin embargo, tengo una idea que podría mitigar el uso de firesheep y, en general, todo el secuestro de sesiones.

Mi sugerencia es vincular una huella digital del navegador a cada usuario. Si la huella digital varía, el usuario debe volver a autenticar esta huella digital en su cuenta.

Básicamente me refiero a almacenar una huella digital similar que panopticlick.eff.org puede crear con solo mirar su navegador.

  • Cada vez que cambie la huella digital, asegúrese de que el usuario haya autenticado esta huella digital
  • Si la huella digital no está autenticada en esta cuenta de usuario, vuelva a autenticar al usuario.

Puede encontrar más información sobre la creación de perfiles de usuarios web aquí:

2
Chris Dale

En una palabra, no. Para prevenir ataques al estilo FireSheep, necesita alguna forma de proteger sus encabezados incluso contra un observador pasivo. (Después de todo, toda la información enviada por el cliente, incluida CUALQUIER forma de criterio de autenticación, está en los encabezados). Esto significa seguridad a nivel de conexión. Y, para HTTP, eso significa HTTP protegido con TLS o SSL, más comúnmente conocido como HTTPS.

Hay algunas cosas que pueden dificultar las cosas, pero hay formas de evitarlas.

1
David