security - tipo - robar sesion php

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

Question

Entonces, con Firesheep , todos los que están 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 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 la cookie de sesión en texto claro de nuevo.

Atar 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 prevenir 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 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 un desarrollador de sitios web puede hacer para proteger a sus usuarios.

Answer 1

Creo que 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 del usuario 2nd Si el administrador ha iniciado sesión también verifica la base de datos, puede ralentizarse un poco, pero como hay un pequeño número de administradores y el resto son usuarios, se trata de un plus de seguridad factible. 3º PROTEGE TU SESIÓN <=!

Protección de sesión: ponga 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. En la próxima carga, compruebe si los valores son los mismos si no solo no desperdicia más recursos desconecte al usuario y muestre la página de índice.

Esta no es una solución completa, ya que podría ser el mismo navegador en la misma red, por ejemplo, WiFi con muchos usuarios y la 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 interesaba en asegurar su APLICACIÓN consulte su tutorial PHP seguro. https://www.lynda.com/PHP-tutorials/Creating-Secure-PHP-Websites/133321-2.html

PS: varias otras defensas (CSRF como mínimo) deben usarse para tener un AP algo seguro

Adiós :-)

Answer 2

The Rook ha respondido algo de eso, responderé las otras partes de tu pregunta.

¿El 100% de HTTPS es en todo momento la única forma de evitar este tipo de secuestro de sesión?

Está bien. 100% HTTPS es la única forma. Y el 100% es clave.

¿No podría la gente simplemente olfatear todo el tráfico HTTPS, incluido el apretón de manos, o es seguro? (Estoy pensando en ataques de repetición, pero no tengo conocimiento en esa área)

HTTPS tiene una protección integrada contra ataques de repetición. Si se implementa correctamente, HTTPS es realmente seguro.

Incluso si HTTPS se implementa correctamente, hay 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

Firesheep no 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 direcciones: javascript:document.cookie=''SOME_COOKIE'' . Esta herramienta es para script kiddies que temen 1 línea de JavaScript.

Las cookies pueden ser pirateadas si no utiliza HTTPS durante toda la vida de la sesión y esto forma parte de OWASP A9: Insuficiente protección de la capa de transporte . Pero también puedes secuestrar una sesión con XSS.

1) Use las cookies httponly .

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

3) Escanee su aplicación web para XSS.

¡No te olvides de CSRF ! (Que Firesheep no aborda).