with texto strip_tags remove limpiar from eliminar allow all php security session

php - texto - string strip_tags



Previniendo el secuestro de la sesión (8)

¿Podemos hacer algo como esto?

Almacenar la identificación de sesión en la base de datos. También almacene la dirección IP y HTTP_USER_AGENT para esa identificación de la sesión. Ahora, cuando llega una solicitud al servidor que contiene esa identificación de sesión coincidente, compruebe de qué agente e IP proviene en su secuencia de comandos.

Puede hacer que esta función funcione haciendo una función o clase común para la sesión, de modo que cada solicitud se verifique antes de que se procese. Difícilmente tomaría unos micro segundos. Pero, si muchos usuarios visitan su sitio y usted tiene una gran base de datos de sesiones, entonces este podría ser un problema de rendimiento. Pero, seguramente sería muy seguro comparado 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 se copia la identificación de la sesión del usuario y que el usuario no está trabajando o activo por algún tiempo y no se realiza ninguna solicitud al servidor con la identificación de la sesión vieja pidiendo que se regenere la nueva. Luego, en caso de que la identificación de la sesión sea secuestrada, el pirata informático usará esa identificación de sesión y realizará una solicitud al servidor con esa identificación, luego el servidor responderá con una identificación de sesión regenerada y para que el pirata informático pueda seguir utilizando los servicios. El usuario real ya no podrá operar porque se desconoce cuál es el id. Regenerado y qué ID de sesión de solicitud se pasará cuando se solicite. Completamente ido.

Por favor corrígeme si estoy equivocado en alguna parte.

¿Cómo se evita que varios clientes utilicen la misma ID de sesión? Pregunto esto porque quiero agregar una capa adicional de seguridad para evitar el secuestro de la sesión en mi sitio web. Si un pirata informático de alguna manera descubre la ID de sesión de otro usuario y realiza las solicitudes con ese SID, ¿cómo puedo detectar que hay diferentes clientes que comparten un solo SID en el servidor y luego rechazar el intento de secuestro?

EDITAR

He aceptado la respuesta de Gumbo después de una cuidadosa consideración porque me he dado cuenta de que lo que estoy pidiendo es imposible debido a las restricciones de un protocolo HTTP sin estado . Me olvidé de lo que quizás sea el principio más fundamental de HTTP, y ahora que pienso en esta pregunta parece un poco trivial.

Permítanme explicar lo que quiero decir:

Después de que el usuario A inicia sesión en example.com, se le da una identificación de sesión aleatoria, por simplicidad, que sea ''abc123''. Esta ID de sesión se almacena como una cookie en el lado del cliente y se valida con una sesión del lado del servidor para garantizar que el usuario que inició sesión permanezca conectado mientras se mueve de una página web a otra. Esta cookie, por supuesto, no necesitaría existir si HTTP no fuera apátrida. Por esa razón, si el usuario B roba el SID del usuario A y crea una cookie en su computadora con el valor ''abc123'', habría secuestrado exitosamente la sesión del usuario A, pero simplemente no hay forma de que el servidor reconozca legítimamente que el usuario B la solicitud es diferente de las solicitudes del Usuario A y, por lo tanto, el servidor no tiene motivos para rechazar ninguna solicitud. Incluso si tuviéramos que enumerar las sesiones que ya estaban activas en el servidor e intentar ver si alguien está accediendo a una sesión que ya está activa, ¿cómo podemos determinar que es otro usuario el que está accediendo a la sesión de forma ilegítima y no al mismo usuario? quien ya inició sesión con una ID de sesión, pero simplemente intenta hacer otra solicitud con ella (es decir, navegar a una página web diferente). No podemos. ¿Verificando el agente de usuario? Puede ser falso, pero bueno como medida de defensa en profundidad. ¿Dirección IP? Puede cambiar por razones legítimas, pero en lugar de no verificar la dirección IP, sugiero verificar algo así como los dos primeros octetos de la IP, ya que incluso un usuario de una red de plan de datos que constantemente tiene una IP cambiante por razones perfectamente legítimas solo tendrían generalmente los últimos dos octetos de su IP cambiando.

En constricción, es el HTTP sin estado que nos condena a no poder proteger completamente nuestros sitios web del secuestro de sesión, pero las buenas prácticas (como las que Gumbo ha proporcionado) serán lo suficientemente buenas para evitar una buena mayoría de los ataques de la sesión. Por lo tanto, tratar de proteger las sesiones contra el secuestro mediante la denegación de múltiples solicitudes del mismo SID es simplemente absurdo, y podría frustrar todo el propósito de las sesiones.

@Anandu M Das:

Creo que a lo que se refiere es al uso de tokens de sesión con cada ID de sesión. Este sitio puede explicar el uso de tokens con sesiones:

https://blog.whitehatsec.com/tag/session-token/

Aunque los tokens de sesión se ven fácilmente comprometidos por un ataque XSS, esto no significa que nunca se deben usar. Quiero decir, enfrentémoslo, si algo fue comprometido por una vulnerabilidad de seguridad en el servidor, no es culpa del método, es culpa del programador que introdujo esa vulnerabilidad (para resaltar los puntos hechos por Hesson y Rook).

Si sigue las convenciones y prácticas de seguridad adecuadas y protege su sitio de inyección SQL, XSS, y requiere que todas las sesiones se administren a través de HTTPS, entonces puede administrar fácilmente el posible ataque de CSRF mediante el uso de tokens del lado del servidor, almacenados dentro de la sesión. y actualizado cada vez que el usuario causaría una manipulación en su sesión (como un $ _POST enviado). Además, NUNCA almacene las sesiones o sus contenidos en una url, sin importar qué tan bien piense que están codificados.

Cuando la seguridad de sus usuarios es primordial (lo que debería ser), el uso de tokens de sesión permitirá ofrecer funcionalidades mejores o más avanzadas sin comprometer la seguridad de la sesión.

En mi opinión, puede almacenar la identificación de la sesión en la base de datos cuando los usuarios inician sesión y comprobar que todos sean iguales antes de iniciar sesión. Elimine la misma ID de sesión que ha almacenado en la base de datos cuando los usuarios se desconectan. Puede encontrar fácilmente la ID de sesión de todos y cada uno de los usuarios o, si no, puedo ayudarlo.

Hay muchas defensas estándar contra el secuestro de la sesión. 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 encabezado de usuario-agente enviado por el cliente
  • el SID
  • una clave secreta almacenada en el servidor

La razón por la que solo se utiliza 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 verdaderamente seguro, realmente debe forzar SSL para todas las solicitudes para que el SID no pueda ser interceptado por atacantes potenciales en primer lugar. Pero no todos los sitios hacen esto ( :: tos :: Desbordamiento de pila :: tos ::) .

Lamentablemente, no existe una forma efectiva de identificar inequívocamente una solicitud que se origina de un atacante en oposición a una solicitud genuina. Debido a que la mayoría de las propiedades que controlan las medidas 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 pueden falsificarse fácilmente (p. Ej ., Encabezado de solicitud del agente de usuario ). usuario genuino cambió la dirección IP) o falsos negativos (es decir, el atacante pudo forzar la solicitud con el mismo User-Agent ).

Es por eso que el mejor método para evitar el secuestro de sesión 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 gestión de sesión que (1) un atacante no adivine una ID de sesión válida usando suficiente entropía, y (2) que no haya otra forma para que un atacante obtenga una ID de sesión válida mediante ataques conocidos / vulerabilities como oler la comunicación de la red, cross-site scripting, leakage through Referer , etc.

Dicho eso, debes:

Además de eso, también debe regenerar la ID de sesión invalidando la anterior (consulte la función session_regenerate_id ) después de ciertos cambios en el estado de la sesión (por ejemplo, confirmación de autenticidad después del inicio de sesión o cambio de autorización / privilegios) y también puede hacerlo periódicamente para reducir el tiempo span para un ataque exitoso de secuestro de sesión.

No sé bien sobre la parte de codificación. Entonces puedo decirte un algoritmo para hacer esto. Establecer elementos como SSL o configurar la cookie de sesión como segura y httpOnly no funcionará si un usuario olfatea la identificación de la sesión desde una red LAN (el usuario provisto y el atacante están en la misma LAN).

Entonces, lo que puede hacer es, una vez que el usuario inicie sesión exitosamente en la aplicación, establecer un token único para todas y cada una de las páginas de la aplicación web y mantener un seguimiento de esto en el lado del servidor. De modo que si el usuario válido envía la solicitud para acceder a una página en particular, el token de esa página también se enviará al lado del servidor. Como los tokens son únicos para un usuario para una sesión en particular, incluso si el atacante puede obtener la identificación de la sesión, no puede secuestrar la sesión de los usuarios ya que no puede proporcionar el token válido al servidor.

Obviamente, cuando configure la cookie de sesión en el navegador, esa cookie se enviará en la solicitud. Ahora cuando llega la solicitud, el Servidor verificará la identificación de la sesión en la base de datos y otorgará acceso. Para evitar eso, solo es importante almacenar el agente y la ip de modo que, antes de comprobar el servidor, se asegure de que el acceso a las sesiones se otorgue al cliente exclusivo y no a la identificación única de la sesión que puede ser secuestrada.

Una de las implementaciones más sencillas puede hacerse creando una tabla en la base de datos, como usuarios registrados, luego al iniciar sesión, actualizar esa tabla con el nombre de usuario y su SID, esto evitará que otros inicios de sesión sean el mismo usuario, ahora en el momento de cerrar la sesión, solo ejecute una consulta simple, que borra los datos de inicio de sesión en la base de datos, esto también se puede utilizar para rastrear usuario conectado en su sitio web a la vez.