Suponga que desea otorgar a algunos usuarios web acceso privilegiado a su sitio web, pero 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 de usuario que anule FireSheep, pero no cree una experiencia de usuario dolorosa?
En principio, puedes defenderte de 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 encriptación en Javascript para encriptar todo en el lado del cliente (en Javascript). La primera cosa con la que se encuentra es que esto tiene un bajo rendimiento, porque crypto en Javascript es sustancialmente más lento que el crypto nativo del navegador. La reacción natural es sugerir cifrar solo los datos más confidenciales, por ejemplo, solo las contraseñas del usuario. Sin embargo, esto es muy difícil de resolver y tiene muchas trampas sutiles:
Si no estás cifrando las cookies, eres vulnerable al secuestro de sesión y no has ganado nada. Y no es fácil cifrar las cookies u otros encabezados HTTP desde Javascript. Por lo tanto, probablemente se verá obligado a inventar su propio método de autenticación de usuario y usar algo que no sean las cookies (algo hecho en casa) para la administración de sesiones, que es un montón de trabajo y es fácil equivocarse.
Si solo cifra la contraseña, puede ser vulnerable a los ataques CSRF. Un intruso 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 contra esto con suficiente esfuerzo, pero aún requiere más trabajo tanto en el cliente como en el servidor, y es difícil hacerlo bien.
Si los usuarios pueden iniciar sesión en su sitio utilizando su cuenta de Facebook, ya que no controla Facebook, no puede evitar que un intruso robe su cuenta de Facebook y luego inicie sesión en su sitio.
Aún eres vulnerable a los ataques de intermediarios (ataques activos) que modifican el contenido de la página. No sería terriblemente técnicamente difícil modificar Firesheep para usar el secuestro ARP, los ataques de carrera u otros métodos para insertarse como un hombre en el medio y modificar todo el contenido de la página. Luego se pierde la seguridad, ya que el atacante puede insertar un Javascript malicioso que actúa como un registrador de teclas o roba las credenciales de autenticación.
Debe tener cuidado de no perder el beneficio del almacenamiento en caché.
Ahora no estoy diciendo que sea imposible. Es casi seguro que no lo es. Es casi seguro que es 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 considerable experiencia en seguridad para construirlo, y aún existe una posibilidad no trivial de arruinar 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 sobre los intentos de vanguardia para defenderse de las escuchas ilegales sin el uso de SSL, aquí hay un gran recurso para usted:
También me gustaría compartir con ustedes algunos recursos para que SSL funcione bien:
SSL no es gratis, 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.
Usted podría evitar el Firesheep actual a través de algún esquema de "seguridad a través de la oscuridad" que involucra la autenticación a través de la administración dinámica de la sesión como se explica aquí . Puede usar la "Autenticación de resumen" ( RFC 2617 ), pero aún es vulnerable a un ataque MITM, degrada la experiencia del usuario y requiere que el servidor almacene su contraseña (o una contraseña equivalente) sin cifrar.
Pero evitar SSL / TLS no solucionaría los dos problemas fundamentales que sin el cifrado: (1) todo el contenido privado se comparte a la intemperie, y (2) un atacante determinado podría resolver su esquema y derrotarlo.
Vea algunos ejemplos lindos de ataques activos, mitos sobre las 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 desbordamiento de pila en por qué no se ha solucionado en el desbordamiento de pila (todavía).
Tenga en cuenta que la exposición para sitios comunes es peor de lo que inicialmente pensé. P.ej. note esta arruga mientras el autor de Firesheep explica en una gran publicación
No puedes simplemente evitar visitar el Sitios que están siendo atacados aquí. Hay una enorme cantidad de mezcla contenido en la web de hoy, como el Botón "Me gusta" de Facebook, "Digg de Digg Botón ”, widgets de twitter, e incluso Imágenes incrustadas que están alojadas en Flickr u otros sitios para compartir fotos. Cada vez que accedas a alguna página web. que incluye cualquiera de estos contenidos, tu navegador también envía cualquier cookies de autenticación que tienes con la solicitud para bajar el widget.
Al menos puede 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 en cierta medida de estos ataques de "pirateo lateral", por ejemplo. para usar una VPN o buscar una red wifi WPA2 (pero vea los problemas de WPA2 aquí ).
Gracias a @ D.W. para un enlace al enfoque provisional mejor pensado que he visto: SessionLock Lite por Ben Adida. Al menos evita los secuestros persistentes por parte de atacantes pasivos: Benlog »keep Tus manos fuera de mis cookies de sesión . Simplemente no se detenga allí: diseñe una implementación SSL ....
Sin la menor duda, la respuesta es NO . Debe tener una capa de transporte completamente segura para transmitir su ID de sesión. En ningún momento se puede transmutar este ID de sesión a través de una conexión insegura, esto sería una violación de OWASP A9 - Insufficient Protección de la capa de transporte
Estoy de acuerdo con la respuesta de Rook. Sin embargo, tengo una idea que podría mitigar el uso de firesheep y, en general, 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 simplemente mirar en su navegador.
Puede encontrar más información sobre la creación de perfiles de usuarios web aquí:
En una palabra, no. Para prevenir ataques 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 criterios de autenticación, se encuentra en los encabezados). Esto significa seguridad a nivel de conexión. Y, para HTTP, eso significa HTTP protegido por TLS o SSL, más conocido como HTTPS.
Hay algunas cosas que pueden hacer que sea más difícil, pero hay maneras de evitarlas.
Lea otras preguntas en las etiquetas web-application attack-prevention session-management