2010-12-15 9 views
10

Bajo el principio de "si camina como un pato y suena como un pato", parece que las consultas con sabor SQL que admite SimpleDB de Amazon deberían ser susceptibles a los ataques de inyección SQL. He aquí un ejemplo sencillo que asume de entrada del atacante es entrar en la categoría de $ variable y que puede adivinar un nombre de columna:¿Cómo puedo proteger Amazon SimpleDB de SQL Injection?

$category = "Clothes' OR Category LIKE '%"; 
$results = $sdb->select("SELECT * FROM `{$domain}` WHERE Category = '$category'"); 

Si estás jugando el juego en casa, estas líneas pueden ser un lugar en el reemplazo para la línea 119 en el archivo html-sdb_create_domain_data.php en el código de muestra en el PHP SDK de Amazon (1.2).

Amazon publica quoting rules, y supongo que podría escribir algo que asegure que cualquier "o" en la entrada del usuario se duplique ... pero siempre he entendido que escapar es básicamente una carrera de armamentos, lo que hace que la parametrización sea mi arma de elección cuando se utiliza, por ejemplo, MySQL.

¿Cuáles son otras personas que utilizan para defender consultas SimpleDB?

Respuesta

8

la operación SimpleDB Select es no destructiva, por lo que la única cosa para proteger contra la trata de datos de consulta adicionales que van a el atacante.

La solución para desinfectar el usuario inp ut a la consulta es bastante fácil con SimpleDB ya que no se permiten sub-selecciones y declaraciones compuestas. Entonces no es realmente una carrera armamentista; las secuencias de uno o más caracteres de comillas en la entrada deben escaparse si la longitud de la secuencia es impar.