¿Hay alguna forma de explotar los parámetros GET POST no utilizados en la aplicación web?

2

Así que hay una aplicación que acepta algunos datos del exterior. Suponiendo que acepte solo un número finito de diferentes parámetros POST / GET y que la aplicación maneje correctamente todos los datos enviados con estos parámetros, hay una manera de explotar una aplicación enviando parámetros adicionales.

Con esto quiero decir lo siguiente: suponiendo que mi aplicación acepte solo un parámetro de publicación ' number ', ¿hay alguna manera de enviar otros parámetros (puede haber demasiados parámetros, o pueden ser parámetros demasiado grandes) para explotar el aplicación?

La pregunta no es específica del idioma / servidor.

    
pregunta Salvador Dali 10.03.2014 - 10:06
fuente

3 respuestas

3

En circunstancias normales, su aplicación solo debe manejar los parámetros que espera. Sin embargo, si usa un marco, podría haber problemas de seguridad adicionales como "Asignación en masa" (buena lectura en Ruby on Rails '-fecha- seguridad problem ).

Pero, como en su ejemplo, si la aplicación solo acepta el "número" como argumento POST, no debería manejar nada más.

    
respondido por el ndrix 10.03.2014 - 11:36
fuente
1

Hay algunos casos en que esto puede ser explotado. Un ejemplo que he visto es cuando la aplicación hace eco de una solicitud GET completa en el cuerpo de la página resultante, por ejemplo, en un campo de enlace o algún código de seguimiento.

Si se hace esto y la URL no se codifica correctamente, podría haber un problema de XSS en un parámetro que su aplicación no usa.

    
respondido por el Rоry McCune 10.03.2014 - 12:08
fuente
1

Sí, ciertamente. Hay Mapeo de objetos inseguros , que es un término más general para "Asignación de masa" en @ La respuesta de m1ke.

En su caso, puede ser posible explotar la aplicación incluyendo dos parámetros number .

por ejemplo https://www.example.com?number=1&number=2 (esto es un GET, pero lo mismo se aplica para POST).

todo depende de cómo la aplicación lo maneja. Algunos marcos pueden hacer que el primer parámetro esté disponible para la aplicación ( 1 ), algunos pueden hacer que el segundo esté disponible ( 2 ) y algunos pueden proporcionar ambos ( 1,2 ). Sin embargo, este último es a menudo equivalente a que la cadena de consulta simplemente es number=1,2 .

La ubicación de una vulnerabilidad podría ser si la cadena de consulta se analiza de dos maneras diferentes en diferentes puntos. Por ejemplo, un script de autorización se puede escribir utilizando un marco que comprueba si el usuario actual tiene permiso para acceder al number proporcionado. Este marco toma el primer valor de cadena de consulta ( 1 ). Sin embargo, el marco que maneja el number para el procesamiento de back-end toma el último number proporcionado ( 2 ), lo que le da a un atacante una manera de evitar la verificación de autorización.

Como usted dice, puede ser posible que exista un exploit donde exista un gran valor de cadena de consulta única, o que haya muchos parámetros proporcionados. Cualquier vulnerabilidad aquí podría estar relacionada con el servidor web y la pila de tecnología del lado del servidor y se han descubierto tales vulnerabilidades .

    
respondido por el SilverlightFox 10.03.2014 - 15:41
fuente

Lea otras preguntas en las etiquetas