Comprobación de la cadena del agente del navegador para la seguridad de la aplicación

4

Recientemente he encontrado algunos registros en mi aplicación en los que he visto que se cambiaba la información del agente del navegador del usuario. Incluso si el usuario está utilizando el mismo navegador, la información del agente se ha modificado para solicitudes consecutivas.

Por ejemplo, una solicitud del usuario vino de

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0)

Pero el usuario no ha cambiado su navegador, y la información del navegador era:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/7.0)

Si ni siquiera puedo confiar en la información del agente del navegador, ¿cuál es la manera ideal de confirmar que el agente del navegador no se ha modificado?

Problema que estoy tratando de resolver

Problema de reparación de sesión: estoy intentando detectar cuándo un usuario hace lo siguiente:

1) Grabs solicita encabezados que pertenecen a una sesión autenticada. 2) Va a otra computadora en una ubicación diferente (por ejemplo, una computadora / navegador diferente). 3) Dispara una nueva solicitud con los mismos encabezados de la sesión autenticada y recibe una respuesta exitosa con recursos (por ejemplo, archivo / página con datos privados).

Originalmente intenté resolverlo con la dirección IP y las comprobaciones del agente del navegador, pero me di cuenta de que debido a la conmutación de NAT, la verificación de la dirección IP es totalmente impráctica. Ahora parece que la verificación del agente del navegador tampoco es buena.

    
pregunta ha9u63ar 13.12.2016 - 11:57
fuente

3 respuestas

3

No utilice el agente de usuario por motivos de seguridad.

  • No es confiable y fácil de cambiar. Como han dicho otros, cada navegador puede establecer el agente de usuario en un valor arbitrario. Es solo un encabezado de información que puede decidir enviar.
  • No es privado y fácilmente predecible. Hay listas de los agentes de usuarios más comunes . Por lo tanto, un atacante puede hacer adivinanzas informadas o atraer a la víctima a un sitio propio para registrar la cadena de agente de usuario y utilizar el valor obtenido.

El problema que describe tampoco es una vulnerabilidad de fijación de sesión . Es un comportamiento aceptable que la misma solicitud autenticada funcione desde diferentes ubicaciones. Por ejemplo, cuando inicie sesión en Github, puede extraer la cookie user_session de un navegador y simplemente usarla en otra máquina. Dado que un atacante no puede acceder fácilmente al tarro de cookies de su navegador, esto no es un problema de seguridad general.

    
respondido por el Arminius 13.12.2016 - 12:39
fuente
0

Como usted sabe, el agente de usuario se puede cambiar, manipular, etc. en el lado del cliente. Entonces, puedes intentar almacenar ips, agentes de usuarios y hacer algún tipo de verificación ... pero necesitas un tercer factor aquí: tiempo . ¿En cuánto tiempo va a aceptar una conexión proveniente de la misma ip con un agente de usuario diferente? No es fácil diferenciar las conexiones "naturales-legales" de las conexiones "spoffing-try-to-hack-you-request". Creo que no hay un método del 100% para hacer esto.

    
respondido por el OscarAkaElvis 13.12.2016 - 12:33
fuente
0

Dado que el agente de usuario se puede cambiar fácilmente y está contenido en los encabezados que le preocupan en su declaración de problema, el método que propone para solucionar el problema no es válido.

La declaración del problema describe el secuestro de la sesión, no la reparación de la sesión.

Muchas personas han tratado de encontrar soluciones al problema; Ninguno de ellos es robusto. Estas soluciones generalmente se rompen cuando el usuario abre una nueva ventana, o usa el botón Atrás - si puede vivir con esto, y realmente hay un beneficio neto, entonces eche un vistazo a los tokens CSRF.

Las medidas preventivas más importantes para proteger contra la repetición / el secuestro de sesiones son:

  • siempre use TLS
  • asegúrese de que está configurando los marcadores httponly y de seguridad en las cookies de sesión
  • proporcione la facilidad clara y explícita de LOGOUT
  • hacer cumplir los tiempos de espera de sesión
respondido por el symcbean 13.12.2016 - 13:55
fuente

Lea otras preguntas en las etiquetas