¿Qué caracteres peligrosos deben filtrarse de las entradas del usuario antes de usarlos en una consulta SQL de DB2?

Navega tus respuestas
6

Busco entender completamente cómo filtrar / escapar adecuadamente los caracteres peligrosos de la entrada del usuario que se interpolará en una consulta SQL de DB2.

El enrutamiento de desinfección que estoy analizando funciona de la siguiente manera:

  • Eliminar todas las barras invertidas (s / \\ //)
  • Reemplace todas las comillas simples con comillas simples dobles (s / '/' '/)

Mi primer instinto fue examinar una función de desinfección de db2 existente, para verificar cualquier diferencia. Así que eché un vistazo a db2_real_escape_string que, al parecer, es bastante diferente: antepuesta barras diagonales inversas a caracteres especiales en el argumento de cadena. Los caracteres que se añaden con una barra invertida son \ x00, \ n, \ r, \, ', "y \ x1a.

Algunas preguntas específicas que tengo son:

  1. ¿Por qué db2_real_escape_string () backslash-escape quotes en lugar de duplicarlas? Esto parece incorrecto.
  2. La función de desinfección que estoy analizando no logra escapar o filtrar \ x00, \ n, \ r, \ x1a, ". ¿Cómo podría un atacante abusar de estos caracteres? Esta es mi pregunta principal.
  3. Otra deficiencia de mi función de desinfección es que no es compatible con el juego de caracteres, pero supongo que esto no es un problema porque db2, en este caso, está configurado para usar el juego de caracteres predeterminado (que estoy adivinar no es multi-byte). Entonces, AFAIK, a menos que se haya configurado un conjunto de caracteres de múltiples bytes como GBK, los ataques de inyección de múltiples bytes de SQL como esta vulnerabilidad conocida en mysql GBK no debería ser un problema.
  4. ¿Hay otras consideraciones / pasos que falte en la función de desinfección que estoy analizando?

Entiendo que el uso de consultas parametrizadas es la solución obvia. Sin embargo, en este caso, soy responsable de A) determinar si el diseño actual es explotable y B) proporcionar un parche para la función de desinfección (si es necesario).

editar Básicamente, estoy buscando construir una prueba de concepto de carga útil de inyección sql, dada la función de desinfección anterior y el siguiente uso: execute( " SELECT foo FROM bar WHERE col='" + my_sanitize($_GET['input']) + "'" )

Dado el diseño actual de la función de desinfección (eliminar barras diagonales y comillas dobles dobles), ¿hay alguna forma de romper las comillas simples como en el ejemplo de uso anterior?

Gracias por su ayuda!

    
pregunta octagonC 10.03.2013 - 00:03
fuente

3 respuestas

3

"La función de desinfección que estoy analizando no logra escapar o filtrar \ x00, \ n, \ r, \ x1a,". ¿Cómo podrían estos personajes ser abusados por un atacante? Esta es mi pregunta principal.

Las representaciones hexadecimales \ x00 y \ x1a para un espacio en blanco y un carácter sustituto. \ ny \ r son avance de línea y retornos de carro.

En la mayoría de los casos, no creo que estos sean personajes terriblemente explotables. Pensando mientras escribo aquí, podrías usar \ x00 (en blanco) para inundar un búfer estático. Un \ x1a (sub) carácter puede tener potencial si el sistema está en modo binario, o si está transmitiendo en modo binario, para engañar al sistema para que piense que ha llegado al final de un archivo prematuramente.

En cuanto a \ n & No puedo pensar en mucho.

Dependiendo de cuánta información tenga / pueda obtener en el sistema, es posible que desee investigar las diferentes codificaciones de caracteres posibles. A veces, puede hacer cosas como pasar un UTF-8 a un proceso configurado a UTF-7 (ejemplo aleatorio, no a ninguna aplicación práctica en la que esté pensando) y obtener resultados emocionantes de la magia de los errores de conversión.

La mejor de las suertes con tu prueba de lápiz.

    
respondido por el grauwulf 10.03.2013 - 06:22
fuente
8

"Desinfección" es frágil. Debe pensar en cada detalle de cómo la base de datos interpreta los "caracteres especiales", y debe realizar un seguimiento de la misma en caso de que una nueva sub-versión de la base de datos introduzca caracteres especiales adicionales. Este es un trabajo agotador y con frecuencia falla.

La forma (muy) preferida de insertar datos de usuarios en consultas SQL es utilizar declaración preparada . Esto será más fácil para usted (el programador), más sólido, más seguro y posiblemente más rápido.

    
respondido por el Thomas Pornin 10.03.2013 - 01:50
fuente
0

Para la validación de la entrada de usuario crítica, eso puede romper sus cadenas SQL. Haría una "matriz / cadena de caracteres válida" y luego verificaría que cada carácter en la entrada del usuario debe estar dentro de la cadena permitida.

Como si solo permitieras números, la cadena se podría hacer algo como: 

function ParseIntoValid(userinput)
{
    string validOutput = "";
    Array allowedChars = new Array("0123456789");

    foreach (char c in userinput[])
    {

        if (c.instr(allowedChars))
        {

            // if this is a parser, then add valid chars to new output
            validOutput += c;
         }
         else
         { 
            // exit loop and return false/error if you just need a check or just ignore the illigal chars
         }
    }
}

puede ajustar fácilmente esta comprobación en un simple "CheckIfValid (input)" o "ParseIntoValid (input)" dependiendo de su objetivo.

Al analizar y no solo verificar, se obtiene una salida válida, quizás tenga menos caracteres, pero si el usuario ingresa un solo carácter ilícito por defecto, esta función ayudará al "buen usuario" y al "mal usuario" Todavía no puedo acceder usándolos.

    
respondido por el BerggreenDK 11.03.2013 - 12:30
fuente

Lea otras preguntas en las etiquetas

¿Qué tan útil es rkhunter? ¿Cuánto cuesta una solicitud GET a través de HTTPS revelar a un espía?