2010-10-25 6 views
6

¿Qué metodologías recomiendan las personas para mitigar el método 'Firesheep' para aplicaciones de sitios web?¿Cómo mitigar el ataque de "incendio" en la capa de aplicación?

Hemos pensado en esto y, desde una perspectiva de usabilidad, que no sea encriptar todo el tráfico a un sitio, mitigar el ataque puede ser un problema para los desarrolladores web.

Una sugerencia que se nos ocurrió fue utilizar cookies basadas en ruta, y encriptar el tráfico para una ruta específica en la que se realizan operaciones de cuenta o interacción personalizada. Sin embargo, esto complica la usabilidad, ya que el resto del sitio (el bit no encriptado no autenticado) no sabe quién sería el usuario.

¿Alguien tiene alguna otra sugerencia para mitigar este vector de ataque, manteniendo un nivel utilizable de usabilidad?

+0

Dicho sea de paso, si uno de los moderadores desea agregar una etiqueta 'fireresheep' a esto, porque es bastante relevante. – pobk

+0

Una x-ref para [Firesheep] (http://gizmodose.com/firesheep-firefox-plugin-allows-users-to-steal-passwords-hack-facebook-accounts.html). –

+0

posible duplicado de [¿Es HTTPS la única defensa contra el secuestro de sesión en una red abierta?] (Http://stackoverflow.com/questions/4017344/is-https-the-only-defense-against-session-hijacking-in- an-open-network) – rook

Respuesta

7

Firesheep es nada nuevo. El secuestro de la sesión ha estado ocurriendo por más de dos décadas. No necesita "encriptar" su cookie, eso es manejado por su capa de transporte. Las cookies siempre deben ser cryptographic nonce.

Por lo general, los hackers simplemente configuran sus propias cookies tecleando esto en la barra de direcciones javascript:document.cookie='SOME_COOKIE', FireSheep es para script kiddies que temen 1 línea de JavaScript. Pero realmente no hace que este ataque sea más fácil de realizar.

Las cookies pueden ser secuestradas si no utiliza HTTPS durante toda la vida de la sesión y esto es aparte de OWASP A9 - Insufficient Transport Layer Protection. Pero también puedes secuestrar una sesión con XSS.

1) Use httponly cookies. (Lo hace para que JavaScript no pueda acceder a document.cookie, pero igual puede hacer la sesión con xss)

2) Use "secure cookies" (Nombre horrible, pero es una marca que obliga al navegador a hacer solo la cookie HTTPS.)

3) analice aplicación web para XSS usando Sitewatch(free) o wapiti (open source)

Asimismo, no se olvide de CSRF! (¿Qué fuego no se dirige?)

+0

Sí. No es nada nuevo. El nuevo como mencionas es que los niños skript pueden entrar en acción. Por eso es potencialmente un problema así. Quiero proteger a mis usuarios – pobk

+0

@pobk Debería habilitar estas funciones de seguridad antes de Firesheep. Esta herramienta no cambia nada. – rook

+0

Nuestra aplicación es tan segura como podemos hacerlo (cumple con las PCI DSS) ... Estamos mirando más allá de proteger a nuestros usuarios. – pobk

0

Cualquier persona intentó aprovechar el "almacenamiento web" en HTML 5 para almacenar una clave compartida (aprobada durante las respuestas cifradas SSL durante la autenticación) utilizada por javascript para alterar la cookie de sesión ¿a través del tiempo?

De esta forma, las cookies de sesión robadas (no encriptadas) solo serían válidas por un corto período de tiempo.

Supongo que el almacenamiento web está segmentado por puerto (además del host), por lo que no sería posible. Solo lanzando esa idea por ahí en caso de que alguien quiera correr con ella.

+0

El atacante simplemente tiene que inyectar javascript en una de las respuestas HTTP, que revela la clave compartida. – caf

-1

Cuando troncos de usuario, almacenar la dirección IP en la sesión.

En cada solicitud posterior de esta sesión, verifique que la dirección IP coincida con la almacenada en la sesión.

+0

Me temo que eso no funcionará. La dirección IP remota se compartiría en las instancias en las que prevalecería la llama del fuego – pobk

+0

, incluso si también almacena el valor del encabezado HTTP X-Forwarded-For junto con la dirección IP. –

Cuestiones relacionadas