este problema se puede resolver de diversas formas, pero nosotros te compartimos la que en nuestra opinión es la resolución más completa.
Solución:
Desafortunadamente, no existe una forma efectiva de identificar inequívocamente una solicitud que se origina en un atacante en oposición a una solicitud genuina. Debido a que la mayoría de las propiedades que contramedidas verifican, como la dirección IP o las características del agente de usuario, no son confiables (la dirección IP puede cambiar entre varias solicitudes) o se pueden falsificar fácilmente (por ejemplo, Agente de usuario encabezado de solicitud) y, por lo tanto, puede producir false positivos (es decir, una dirección IP auténtica cambiada por el usuario) o false negativos (es decir, el atacante pudo falsificar con éxito la solicitud con el mismo Agente de usuario).
Es por eso que el mejor método para evitar el secuestro de sesiones es asegurarse de que un atacante no pueda encontrar la ID de sesión de otro usuario. Esto significa que debe diseñar su aplicación y su administración de sesión de modo que (1) un atacante no pueda adivinar una ID de sesión válida utilizando suficiente entropía y (2) que no haya otra forma de que un atacante obtenga una ID de sesión válida mediante ataques conocidos. /vulnerabilidades como olfatear la comunicación de la red, Cross-Site Scripting, fugas a través de referenteetc.
Dicho esto, deberías:
- use suficiente entrada aleatoria para generar la ID de sesión (ver session.entropy_file, session.entropy_lengthy session.hash_function)
- use HTTPS para proteger la ID de la sesión durante la transmisión
- almacene la ID de sesión en una cookie y no en la URL para evitar fugas referente (ver session.use_only_cookies)
- establecer la cookie con el
HttpOnlyySecureattributes prohibir el acceso a través de JavaScript (en caso de vulnerabilidades XSS) y prohibir la transmisión a través de un canal no seguro (ver sesión.cookie_httponly y sesión.cookie_secure)
Además de eso, también debe regenerar la ID de sesión mientras invalida la anterior (ver session_regenerate_id función) después de ciertos cambios en el estado de la sesión (por ejemplo, confirmación de autenticidad después de iniciar sesión o cambio de autorización/privilegios) y, además, puede hacerlo periódicamente para reducir el lapso de tiempo para un ataque de secuestro de sesión exitoso.
¿Podemos hacer algo como esto?
Almacene la identificación de la sesión en la base de datos. Almacene también la dirección IP y el HTTP_USER_AGENT para esa identificación de sesión. Ahora, cuando llega una solicitud al servidor que contiene esa identificación de sesión coincidente, verifique de qué agente e IP proviene en su secuencia de comandos.
Puede hacer que esta funda funcione haciendo una función o clase común para la sesión para que cada solicitud se verifique antes de que se procese. Apenas tardaría unos microsegundos. Pero, si muchos usuarios visitan su sitio y tiene una gran base de datos de sesiones, entonces esto podría ser un pequeño problema de rendimiento. Pero seguramente sería muy seguro en comparación con otros métodos como => Usar sesiones de regeneración.
Al regenerar los identificadores de sesión, nuevamente hay pocas posibilidades de secuestro de sesión.
supongamos que la identificación de la sesión del usuario se copia y ese usuario no está trabajando o activo durante algún tiempo y no se realiza ninguna solicitud al servidor con la identificación de sesión anterior que solicita regenerar una nueva. Luego, en caso de que la identificación de la sesión sea secuestrada, el hacker usará esa identificación de la sesión y hará una solicitud al servidor con esa identificación, luego el servidor responderá con la identificación de la sesión regenerada y el hacker podrá seguir usando los servicios. El usuario real ya no podrá operar porque no sabe cuál es la identificación regenerada y qué identificación de sesión de solicitud se debe pasar en la solicitud. Completamente ido.
Por favor, corrígeme si me equivoco en alguna parte.
Hay muchas defensas estándar contra el secuestro de sesiones. Uno de ellos es hacer coincidir cada sesión con una sola dirección IP.
Otros esquemas pueden usar un HMAC generado a partir de:
- la dirección de red de la IP del cliente
- el agente de usuario encabezado enviado por el cliente
- el DSI
- un secreto key almacenado en el servidor
La razón por la que solo se usa la dirección de red de la IP es en caso de que el usuario esté detrás de un proxy público, en cuyo caso su dirección IP puede cambiar con cada solicitud, pero la dirección de red sigue siendo la misma.
Por supuesto, para estar realmente seguro, realmente debe forzar SSL para todas las solicitudes para que los posibles atacantes no puedan interceptar el SID en primer lugar. Pero no todos los sitios hacen esto (::tos:: Desbordamiento de pila ::tos::).
Puedes auxiliar nuestra misión ejecutando un comentario o dejando una valoración te lo agradecemos.