¿HTTPS es la única defensa contra el secuestro de sesiones en una red abierta?

Question

Así que con Firesheep, todos en un Wi-Fi público ahora tienen una herramienta de secuestro de sesión con un solo clic.

La forma en que funciona, a mi entender, es que simplemente captura todo el tráfico y toma la cookie de sesión (para que no robe las contraseñas).

Desde mi entender, esto también significa que un inicio de sesión seguro de HTTPS no resuelve esto solo, ya que el tráfico HTTP adicional incluiría nuevamente la Cookie de sesión en texto sin formato.

Conectar la sesión a una dirección IP específica es inútil gracias a NAT, y vincularlo al agente de usuario es fácil de falsificar.

Entonces, ¿el 100% de HTTPS es en todo momento la única forma de evitar este tipo de secuestro de sesión? ¿No podría la gente simplemente olfatear todo el tráfico HTTPS, incluido el apretón de manos, o es seguro? (Estoy pensando en los ataques de repetición, pero no tengo conocimiento en esa área.)

Por supuesto, no usar redes Wi-Fi públicas/abiertas es la mejor opción, pero todavía estoy interesado en lo que puede hacer un desarrollador de sitios web hacer para proteger a sus usuarios.

Answer 1

Firesheep es nada nuevo. El secuestro de la sesión ha existido por el tiempo que las aplicaciones web han estado usando ID de sesión. Por lo general, los piratas informáticos simplemente establecen su propia cookie tecleando esto en la barra de dirección: javascript:document.cookie='SOME_COOKIE'. Esta herramienta es para script kiddies que temen 1 línea de JavaScript.

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

1) Use httponly cookies.

2) Use "secure cookies" (nombre horrible, pero es una bandera que obliga al navegador para que sólo el HTTPS galleta.)

3) escanear su aplicación web para XSS.

Además, no se olvide de CSRF! (Que Firesheep no aborda.)

Answer 2

El Rook ha respondido algo de eso, responderé las otras partes de su pregunta.

es 100% HTTPS en todo momento la única manera de prevenir este tipo de secuestro de sesión?

Así es. 100% HTTPS es la única forma. Y el 100% es clave.

No se pudo personas simplemente oler todo el tráfico HTTPS incluyendo el apretón de manos, o es esto seguro? (Estoy pensando en los ataques de repetición, pero no tienen el conocimiento en esa área)

HTTPS ha incorporado en la protección contra los ataques de repetición. Si se implementa correctamente, HTTPS es realmente seguro.

Incluso si HTTPS se implementa correctamente, existen formas de evitarlo. SSL Strip es una de esas herramientas. La herramienta no explota SSL, simplemente explota el hecho de que las personas siempre escriben mybank.com en la url en lugar de https://mybank.com.

Answer 3

I do beleive SSL es barato y una solución completa. Pero hasta que no lo tengas o no busques capas adicionales, aquí es cómo proteger tus datos de SESSIOn.

Como siempre la defensa en el departamento es el camino a seguir. 1st Use Sessions para almacenar los datos de inicio de sesión de usuario 2nd Si el administrador ha iniciado sesión también verifica la base de datos, puede ralentizar un poco pero como hay un pequeño número de administradores y el resto son usuarios, esta es una ventaja de seguridad factible. 3º PROTEGE TU SESIÓN < =!

Protección de sesión: Ponga el inicio de sesión en un archivo de objeto donde llama a una función "is_session_valid()" en autoconstrucción. Esta función verificaría (IP/TIME/Browser) para $ _SERVER superglobal, y los almacenaría en sesión. Subir en la siguiente carga ver si los valores son los mismos si no solo no desperdicia más recursos desconecta al usuario y muestra la página de índice.

Esto no es una solución completa, ya que podría ser el mismo navegador en la misma red, p. Wifi con muchos usuarios y sesión secuestrada también podría ser reciente (a tiempo). Pero hasta que no se use SSL esto es MUCHO MEJOR que nada. De todos modos, rara vez sucede que la víctima y el secuestrador usen todo lo mismo ... ¡así que esto mitiga efectivamente las posibilidades de un ataque exitoso incluso sin SSL!

idea original de Kevin Skoglund si se interesó en asegurar su APLICACIÓN consulte su tutorial PHP seguro. https://www.lynda.com/PHP-tutorials/Creating-Secure-PHP-Websites/133321-2.html

P.S. Varias otras defensas (CSRF menos) debe ser utilizado para tener un punto de acceso seguro tanto

bye :-)