Revisión de seguridad: "El agente de usuario del encabezado HTTP se ha configurado en (algo)"

La inyección en el usuario-agente (o el referente para ese asunto) puede ser una amenaza potencial de varias maneras, sin embargo, si su situación actual es de hecho una vulnerabilidad es difícil de distinguir sin mirar la imagen más grande de su sistema.

A menudo veo sistemas que de alguna manera u otra utilizan el agente de usuario. A menudo se utiliza para almacenar información sobre el navegador más utilizado y similares. A veces, los agentes de usuario conocidos como bots se tratan de manera diferente. Hay muchos casos.

Inyección

No es infrecuente ver que los ataques XSS se intentan en el campo de agente de usuario. Por ejemplo, un sitio que estaba probando hace algún tiempo me presentó algunos fragmentos de información sobre mí.

Lo interesante fue que me devolvió el agente de usuario. Cuando inyecté el user-agent 'FooBar"> <img src="javascript:alert('document.cookie')' me lo alertó.

Ahora, para aprovechar este ataque contra otros usuarios, el sitio también tenía una página de estadísticas donde presentaba cuántos usuarios promedio al día, cuáles eran los navegadores más comunes, etc. Los números parecían estar basados en el número de solicitudes. La creación de un script rápido que hizo suficientes solicitudes con mi XSS simplemente colocó a mi agente de usuario en la lista de los 100 principales y el vector ahora era persistente y estaba funcionando en contra de otros usuarios

Lo mismo es posible para la inyección de SQL. Intenta correr con useragent Im Harmless";DROP TABLE users . Tal vez rompas algunos sistemas.

Comprobación de vulnerabilidad

Lance una / "como en el ejemplo y vea qué sucede. Tal vez reciba un mensaje de error, o algo sucedió en otra parte del sitio.

Verifique qué sucede si utiliza un agente de usuario muy antiguo o un agente de usuario de motor de búsqueda a veces puede ser muy útil. A veces, esta es la única forma de desbloquear parte del contenido del sitio y de buscar vulnerabilidades en ese contenido.

Al usar, por ejemplo, Burpsuite , este último es muy fácil de automatizar y luego busca rápidamente todas las diferentes necesidades para las diferencias.

EDITAR: En su ejemplo específico, parece que el cliente que realiza la solicitud ha configurado el agente de usuario en \ ". Si esto es intencionalmente, un error o simplemente alguien que oculta su agente de usuario es difícil de decir, pero definitivamente me gustaría ver otras solicitudes hechas por este usuario.

No veo cómo insertar una comilla de escape en la cadena de agente de usuario es una vulnerabilidad.

No estoy seguro de que este sea el caso, creo que se necesita más información. Lo ÚNICO en lo que puedo pensar es que posiblemente están exponiendo un potencial para un secuestro de sesión.

Básicamente, PHPSESSID = 08rtvlq03bd9d57qor4abjg7q4 pertenece a una sesión de usuario diferente, están falsificando este ID de sesión a través de una cookie y obtienen una respuesta normal, aunque el agente de usuario haya cambiado del usuario original.

Aclaración:

El usuario A abre el sitio web, utilizando la siguiente cadena User-Agent:

Mozilla Compatible (MSIE)

Al usuario A se le asigna el siguiente ID de sesión:

08rtvlq03bd9d57qor4abjg7q4

El usuario B (malo) envía una solicitud al servidor utilizando una cookie con el mismo ID de sesión en su cookie, sin embargo, su cadena de Usuario-Agente es:

\"

Tu aplicación debería darse cuenta de que no es el mismo usuario y destruir la sesión.

De ninguna manera estoy seguro de que esta sea la situación, ni la supervisión del agente de usuario evitaría un secuestro de sesión, ya que los agentes de usuario se falsifican FÁCILMENTE, pero este es el único potencial que veo aquí.

Están tratando de venderte algo que debería ser inútil.

El protocolo HTTP permite este tipo de cosas. Podría establecer el User-Agent (AKA, "¿Qué tipo de navegador está usando?") Para "User Agent: User Agent: User Agent: Trust no one"

Si su software no está considerando la inyección de código (SQL, Script, etc.) de una manera moderna, esto podría haber sido un problema. Pero usted escribió su software con las mejores prácticas y ha saneado correctamente todas las entradas y está utilizando una capa de abstracción de la base de datos, right?

En términos de formas de mejorar su seguridad, monitorear cosas como el origen, la frecuencia de las solicitudes, perfilar las solicitudes que realizan, verificar el agente del usuario, verificar la página de referencia, verificar ... todo, es una supervisión activa que puede hacer para proporcionar Más seguridad. No creo que esto es lo que intentaban decirte que hicieras (según parte de la respuesta de Alex), solo que "puedes cambiar esto", que es un "no-duh" total para cualquiera que sepa HTTP lo suficientemente bien , pero probablemente solo sea una forma de asustar a algunas pelusas de valor agregado.

Por lo tanto, si su código PHP permite que se inserte cualquier entrada, incluida una cadena de usuario-agente en una base de datos sin una correcta eliminación, y el uso de una capa de abstracción de base de datos, tendrá un día realmente malo. .

Te daré una sugerencia gratuita , el encabezado de tu remitente se puede configurar a esto:

Referrer: \' -- TRUNCATE 'Users'

El problema no es que pueda configurar estos encabezados, puede enviar esos datos tan fácilmente como "Nombre" en forma de dirección.

Entonces, esta es la pregunta: ¿quieres que las personas cuyo agente de usuario que no tienes en una tabla en algún lugar no utilicen tu sitio web? Probablemente sea una idea estúpida porque un hacker solo puede configurarlo en uno válido de todos modos.

La respuesta es simple. No incluya los valores de encabezado pasados en la solicitud en el contenido de su respuesta sin primero limpiarlo. En este caso, nunca utilice los datos proporcionados por el usuario de ninguna manera sin antes limpiarlos. Siempre desinfectar las entradas.

Si no está incluyendo los valores de encabezado pasados por el cliente en su contenido, puede ignorar esta advertencia.

Si las personas que están empleadas para probar la seguridad de su sitio web, y presumiblemente han pasado una cantidad significativa de tiempo trabajando en él, no pueden explicar cómo esto hace que su sitio sea vulnerable de alguna manera, pero puede afirmar que es un punto débil de seguridad en su sitio, entonces parece que ha perdido mucho tiempo y esfuerzo en ellos. Parece que has contratado a script-kiddies para hacer tus pruebas de lápiz.

No hay consejos en los detalles que has publicado. No hay análisis.

Además, el hecho de que parecen estar ejecutando sus pruebas contra 'localhost' sugiere que no saben lo que están haciendo.

Y

Pragma: no-cache

En una respuesta de encabezado, sugiere que quien haya escrito el código tampoco entiende HTTP. De rfc 2616 :

  

Nota: porque el significado de "Pragma: no-cache como respuesta        el campo del encabezado no está realmente especificado, no proporciona un        reemplazo confiable para "Cache-Control: no-cache" en una respuesta

Debe ver su especificación funcional si le dicen que valide los campos del encabezado.

Su especificación funcional debe definir cuál es el comportamiento permitido. Puede definir cualquiera / todos los agentes de usuario como aceptables, en cuyo caso debe aceptarlo. Tenga en cuenta que los datos de encabezado, como todos los datos enviados por el usuario, son potencialmente peligrosos.