it-swarm-es.com

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

Obtuvimos una revisión de seguridad de nuestro código PHP código y el equipo lo aconsejó en su informe (entre otras cosas):

/appdir/ 

Details
The HTTP header user-agent has been set to \" . 

Request
GET /appdir/ HTTP/1.0 
Accept: */* 
User-Agent: \" 
Host: localhost 
Cookie: PHPSESSID=08rtvlq03bd9d57qor4abjg7q4 
Connection: Close 
Pragma: no-cache 

Response
HTTP/1.1 200 OK 
Date: Sat, 18 Dec 2010 09:35:40 GMT 
Server: Apache/2.2.14 (Win32) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l mod_autoindex_color PHP/5.3.1 mod_apreq2-20090110/2.7.1 mod_Perl/2.0.4 Perl/v5.10.1 
X-Powered-By: PHP/5.3.1 
Expires: Thu, 19 Nov 1981 08:52:00 GMT 
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
Pragma: no-cache 
Connection: close 
Content-Type: text/html

¿Importa que el agente de usuario del encabezado HTTP se pueda establecer en\"?

11
siliconpi

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

A menudo veo sistemas que de una forma u otra usan 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 que se conocen como bots reciben un trato diferente. Hay muchos casos.

Inyección

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

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

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 por día, cuáles eran los navegadores más comunes, etc. Los números parecían estar basados ​​en el número de solicitudes. Crear un script rápido que hiciera suficientes solicitudes con mi XSS simplemente colocó a mi agente de usuario en la lista de los 100 mejores y el vector ahora era persistente y funcionaba contra otros usuarios

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

Prueba de vulnerabilidad

Agregue un "/" como en el ejemplo y vea qué sucede. Quizás reciba un mensaje de error o algo sucedió en otro lugar del sitio.

Comprobar qué sucede si usas 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 probar ese contenido en busca de vulnerabilidades.

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

EDITAR: En su ejemplo específico parece que el cliente que realiza la solicitud ha establecido el agente de usuario en\". Si esto es intencionalmente, un error o es difícil saber quién esconde a su agente de usuario, pero definitivamente examinaría otras solicitudes hechas por este usuario.

9
Chris Dale

No veo cómo insertar una comilla escapada 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 una 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 están obteniendo una respuesta normal, a pesar de que el agente de usuario ha cambiado del usuario original.

Aclaración:

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

Mozilla Compatible (MSIE)

El usuario A se le asigna la siguiente ID de sesión:

08rtvlq03bd9d57qor4abjg7q4

El usuario B (tipo 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 agente de usuario es:

\"

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

De ninguna manera estoy seguro de que esta sea la situación, ni el monitoreo del agente de usuario evitará un Secuestro de sesión, ya que los agentes de usuario son FALSAMENTE FALSOS, pero este es el único potencial que veo aquí.

10
Purge

Están intentando venderte algo que no valdrá nada.

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

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

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

Entonces, si su código PHP permite que cualquier entrada -incluida- una cadena de agente de usuario se inserte en una base de datos sin ser desinfectada adecuadamente, y el uso de una capa de abstracción de base de datos, estará tener un muy mal día.

Le daré una sugerencia gratuita , su encabezado de referencia se puede configurar para esto:

Referrer: \' -- TRUNCATE `Users`

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

Así que aquí está la pregunta, ¿quieres dejar que las personas que son agentes de usuario que no tienes en una mesa en algún lugar no usen tu sitio web? Probablemente sea una idea estúpida porque un hacker puede configurarlo como válido de todos modos.

7
Incognito

La respuesta es simple. No incluya ningún valor de encabezado pasado en la solicitud en el contenido de su respuesta sin antes limpiarlo. Por lo demás, nunca use los datos proporcionados por el usuario de ninguna manera sin antes limpiarlos. Siempre desinfecte las entradas.

Si no incluye valores de encabezado pasados ​​por el cliente en su contenido, puede ignorar esta advertencia.

2
bahamat

Si las personas que están siendo 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 pueden 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 tu prueba de lápiz.

No hay consejos en los detalles que ha publicado. No hay analisis.

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 un encabezado, la respuesta sugiere que quien escribió el código tampoco entiende HTTP. De rfc 2616 :

Nota: dado que el significado de "Pragma: no-cache como campo de encabezado de respuesta no se especifica realmente, no proporciona un reemplazo confiable para" Cache-Control: no-cache "en una respuesta

2
symcbean

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

Su especificación funcional debe definir qué 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 del encabezado, como todos los datos enviados por el usuario, son potencialmente peligrosos.

1
Bradley Kreider