2010-08-18 25 views
11

Consideremos la confianza que el servidor tiene con el usuario.Secuestro de sesión y PHP

fijación de sesión: Para evitar la fijación utilizo "session_regenerate_id()" SOLAMENTE en la autenticación (login.php)

Sesión sidejacking: el cifrado SSL para todo el sitio.

¿Estoy seguro?

Gracias.

+0

¿Qué tipo de sitio es? –

+9

@MrXexxed un sitio donde los desarrolladores no quieren que sea pirateado. – rook

+0

@The Rook, estaba hablando con el OP, era una pregunta genuina, su comentario es divertido y completamente inútil. –

Respuesta

28

Lea OWASP A3-Broken Authentication and Session Management. Lea también sobre OWASP A5-CSRF, que a veces se denomina "sesión riding".

Debe utilizar este código en un archivo de cabecera php:

ini_set('session.cookie_secure',1); 
ini_set('session.cookie_httponly',1); 
ini_set('session.use_only_cookies',1); 
session_start(); 

Este código impide session fixation. También ayuda a proteger contra xss del acceso document.cookie, que es una forma en que Session Hijacking puede ocurrir. La aplicación de cookies HTTPS solo es una buena forma de dirigirse a OWASP A9-Insufficient Transport Layer Protection. Esta forma de usar HTTPS a veces se denomina "cookies seguras", que es un nombre terrible para ella. También STS es una característica de seguridad muy buena, pero no todos los navegadores lo admiten (todavía).

+1

Su respuesta merece al menos un +10, y con mi voto lo consiguió. Un par de preguntas para asegurarme de haber entendido: 1) 'cookie_secure' me obligaría a trabajar siempre en https cuando esté en sesión, ¿no? 2) ¿Qué hace 'cookie_httponly'? Leí la explicación de PHP, pero no entiendo cuando dice que impide que JS lea las cookies; en realidad, las cookies deben leerse en muchas circunstancias. Gracias, y para tu información: desde PHP 5.3.0 'session.use_only_cookies' es 1 por defecto http://it.php.net/manual/en/session.configuration.php#ini.session.use-only-cookies –

2

También sugiero almacenar el agente de usuario y la información de IP en la sesión, y verificarla en cada solicitud. No es a prueba de balas, pero es un aumento bastante significativo en robustez. Mientras que forjar UA es realmente fácil, forjar IP, mientras sea posible, es MUCHO más difícil ... Pero puede tener problemas con los usuarios que están detrás de un sistema de IP round-robin como los usuarios de AOL ...

+5

" ip forging "o, más comúnmente, llamado ip spoofing, es imposible para una conexión TCP a través de Internet debido al handshake de tres vías. Sin embargo, la dirección IP de un usuario legítimo puede cambiar durante una sesión debido a los equilibradores de carga en una red corporativa o al cambio de puntos de acceso wifi. – rook

+0

Es bastante posible. Solo requiere un ataque de estilo MITM (donde el atacante obtiene acceso a uno de los enrutadores de punto final y luego puede hacer lo que desee) ... – ircmaxell

+1

No se "falsifica" si se puede acceder a los paquetes enrutados a esa IP. –

0

la mejor práctica i Alguna vez se ha encontrado guardar los datos de la sesión en la base de datos o un archivo de texto. la base de datos tendrá agente de usuario y registro de IP y verificará cada solicitud para asegurarse de que la sesión nunca haya sido secuestrada por otra.

por ejemplo, cómo se guarda la sesión en la base de datos, puede ver la implementación en la biblioteca de la sesión codeigntier. en mi opinión, esta forma de ahorrar bastante para evitar que alguien para secuestrar la sesión.

+3

La comprobación del agente de usuario no tiene sentido porque es una variable controlada por el atacante. Almacenar el ID de la sesión en la base de datos significa que la inyección sql le da al atacante acceso inmediato al sistema, por lo que no necesitará romper un hash de contraseña para iniciar sesión. Comprobar la dirección IP es propenso a errores porque esto puede cambiar en un sistema legítimo, por ejemplo, si está detrás de un equilibrador de carga en una red corporativa. – rook

+0

@Rook: supones que la base de datos es vulnerable a la inyección de SQL. El uso adecuado de declaraciones preparadas o procedimientos almacenados, y el saneamiento adecuado de los parámetros, no permitirán la inyección de SQL. – AgmLauncher

+0

@AgmLauncher equivale a guardar una contraseña en texto plano en la base de datos. Uno debe planear en el fracaso. – rook