Abordar la vulnerabilidad de 'parámetros del cuerpo aceptados en la consulta'

Question

Abordar la vulnerabilidad de 'parámetros del cuerpo aceptados en la consulta'

#1 de John Wu (2 votos)
#2 de peterh (0 votos)
#3 de Frank Marin (0 votos)

4

Recibí una falla en una evaluación de vulnerabilidad porque una heurística determinó que probablemente estaba procesando los parámetros de la cadena de consulta como valores de formulario (usaron las palabras 'parámetros del cuerpo').

Creo que esto es un falso positivo porque MVC (la tecnología), de manera similar a otros marcos, enruta GET y POST basado en reglas. El método que se ejecuta en GET se separa fundamentalmente del formulario.

Además, AppScan parece indicar que determinó este error basándose en que la "respuesta de prueba" es similar a la "respuesta original". No puedo encontrar información en línea para comprender o abordar este problema.

http penetration-test

pregunta Sprague 17.08.2016 - 10:25

fuente

3 respuestas

Lea otras preguntas en las etiquetas http penetration-test

¿Por qué los sistemas de mensajería cifrada de extremo a extremo están limitados a un dispositivo por usuario? ¿El cifrado de la información varias veces con solo pequeños cambios debilita la seguridad?

score 2 · Answer 1

Esta vulnerabilidad se considera "baja" y tiene una puntuación de CVSS de 5.0. La prueba de lápiz toma una página existente y simplemente cambia el verbo en el envío, pasando la carga útil del formulario en la cadena de consulta. Si el sitio web genera un error o muestra una página diferente de la normal, es un PASS. Si el sitio web devuelve una página que es sustancialmente similar a la página normal, es un ERROR.

Los manejadores para solicitudes POST a menudo tienen mitigaciones diferentes; por ejemplo, CSRF a menudo se implementa para POST y no para GET. Al cambiar el verbo, un atacante podría potencialmente omitir la comprobación. Se puede encontrar un ejemplo en la base de datos de vulnerabilidad común, aquí , si sientes curiosidad por si esto es un problema.

En realidad, podría tener una vulnerabilidad si ha utilizado ActionName para asignar el GET y POST a diferentes métodos y los métodos tienen diferentes filtros (por ejemplo, POST tiene el AuthorizeAttribute y GET no lo hace). Eso sería una supervisión bastante seria y debería corregirse antes de cerrar este problema.

Por otra parte, es probable que este tipo de prueba produzca falsos positivos, especialmente en páginas donde el contenido publicado no tiene un efecto inmediato en la experiencia del usuario.

Si encontré este informe para un sitio de MVC, solo me aseguraría de que haya una restricción de verbo en el método de acción, y luego marcaré el elemento como "falso positivo" y seguiré adelante, sin pensarlo demasiado. , por los motivos que el OP ha explicado.

Si no hay una restricción de verbo, deberá agregarla (con un HttpPostAttribute ), o presenta una justificación de por qué la página / manejador no es sensible o no es menos vulnerable cuando se accede a través de GET.

score 0 · Answer 2

"parámetros del cuerpo" es al menos una terminología poco común. Puede no estar completamente equivocado, si es la terminología del marco específico. En el desarrollo web común, no existe tal cosa.

La falla de seguridad es que un atacante puede dar aquí una consulta de SQL incrustada en el formulario. Por ejemplo, imagine una consulta como

SELECT 1 FROM users WHERE user='$_GET[user]';

Si el atacante da una cadena

anything'; UPDATE users SET password='cr4ck';

para el campo de usuario, mediante una solicitud GET o POST con script, puede cambiar todas las contraseñas a 'cr4ck'.

La protección es bastante fácil, todo lo que viene del navegador y va a la base de datos, debe estar entre comillas. No es tan trivial si al marco que está utilizando realmente no le gusta esto, por ejemplo, juega cincuenta veces con las variables en todas partes en el código hasta que se conviertan en una consulta de sql real.

score 0 · Answer 3

Esta vulnerabilidad se considera "baja" y tiene una puntuación CVSS de 5.0. La prueba de lápiz toma una página existente y simplemente cambia el verbo en el envío, pasando la carga útil del formulario en la cadena de consulta. Si el sitio web genera un error o muestra una página diferente de la normal, es un PASS. Si el sitio web devuelve una página que es sustancialmente similar a la página normal, es un ERROR.

Si está usando MVC, puede agregar el atributo [HttpGet] o [HttpPost] para cada método que esté seguro. Quiero decir que este método no responderá si se solicita como GET y usted lo etiqueta como HttpPost.