Inyectar el signo y a la url

7

Digamos que hay un programa que envía algunos datos al servidor a través de GET:

http://server.com/gateway?value1=abc&value3=def

Luego, el servidor envía estos valores aún más, agregando value2: (código de Python)

SECURED_VALUE = "safe"
"http://externalAPI.com/?value1={0}&value2={1}&value3={2}".format ( get['value1'], SECURED_VALUE, get['value2'] )

Y mi punto es, ¿puedo inyectar otro atributo a la última solicitud de una manera como:

http://server.com/gateway?value1=abc&&value2=hacked&value3=def&&value2=hacked

entonces el servidor - > La solicitud de API se ve como:

http://externalAPI.com/?value1=abc&value2=hacked&value2=safe&value3=def&value2=hacked

Lo más probable es que la API externa lea solo la última o la primera aparición de la clave repetida.

Entonces, tengo dos preguntas, principal, si tal pirateo es posible y uno debería proteger sus aplicaciones contra él. En segundo lugar, cómo hacerlo realmente, no solo por el método GET, sino tal vez por POST, o modificando una cadena codificada JSON. Decodificar JSON con un signo y un punto y coma me da un error, poner el signo en el método POST se comporta igual que en el método GET.

Le pregunto esto, porque encontré un problema de seguridad y actualmente estoy escribiendo un ejemplo de un intento de piratería exitosa en caso de que un desarrollador de servidor no elimine los símbolos y otros personajes de riesgo. No quiero convertirme en un tipo estúpido que no sabe que tal inyección no se puede realizar y solo está perdiendo el tiempo de los administradores, así que pensé que primero te lo pediría.

Tercera, pequeña pregunta, ¿conoce alguna buena fuente de sabiduría sobre cómo protegerse de las inyecciones (qué funciones usar para eso) en Google App Engine, python, webapp2 framework?

    
pregunta Markus von Broady 28.04.2012 - 19:01
fuente

1 respuesta

6

Descripción general. Sí. Tienes razón. Muy buena captura haber notado esto.

Detalles. Esto es básicamente una instancia de un Contaminación de parámetros HTTP vulnerabilidad. Esto es básicamente una vulnerabilidad de inyección (similar a XSS, excepto que es una inyección en los parámetros HTTP en lugar de una inyección en HTML).

Defensas. Para defenderse de esto, te sugiero que hagas dos cosas:

  1. Desinfecte los valores de los parámetros. Cree una lista blanca de los caracteres que se espera que aparezcan en sus consultas y que también se sepa que son seguros en este contexto (asegúrese de que no incluya & , ? , = , # , % ), y elimine todo en el valor del parámetro que no esté en la lista blanca.

  2. La URL codifica los valores de los parámetros antes de interpolarlos en la nueva consulta.

Investigaciones relacionadas. Consulte también el siguiente documento de investigación:

respondido por el D.W. 28.04.2012 - 23:44
fuente

Lea otras preguntas en las etiquetas