Explosiones de caracteres multibyte - PHP / MySQL

Resumen. Sí, el problema es que, en algunas codificaciones de caracteres (como UTF-8), un solo carácter se representa como varios bytes. Una forma en que algunos programadores intentan evitar la inyección de SQL es escapar de todas las comillas simples en una entrada no confiable, antes de insertarla en su consulta SQL. Sin embargo, muchas funciones estándar de comillas que se escapan ignoran la codificación de caracteres que la base de datos utilizará y procesará su entrada como una secuencia de bytes, sin tener en cuenta el hecho de que un solo carácter puede rellenar varios bytes. Esto significa que la función de comillas de escape está interpretando la cadena de manera diferente a como lo hará la base de datos. Como resultado, hay algunos casos en los que la función de escape de comillas puede dejar de escapar partes de la cadena que la base de datos interpretará como una codificación de múltiples bytes de una comilla simple; o podría romper inadvertidamente una codificación de caracteres de múltiples bytes de una manera que introduce una comilla simple donde uno no estaba presente anteriormente. Por lo tanto, las explotaciones de caracteres de múltiples bytes ofrecen a los atacantes una forma de realizar ataques de inyección SQL incluso cuando el programador pensó que estaban escapando adecuadamente de sus entradas a la base de datos.

El impacto. Si usa declaraciones preparadas / parametrizadas para formar todas las conexiones de la base de datos, está seguro. Los ataques de múltiples bytes fallarán. (Salvo errores en la base de datos y en la biblioteca, por supuesto. Pero empíricamente, parecen ser raros).

Sin embargo, si intenta escapar de entradas que no son de confianza y luego forma una consulta SQL de forma dinámica mediante la concatenación de cadenas, puede ser vulnerable a los ataques de múltiples bytes. El hecho de que sea vulnerable depende de los detalles específicos de la función de escape que utiliza, la base de datos que utiliza, la codificación de caracteres que está utilizando con la base de datos y posiblemente otros factores. Puede ser difícil predecir si los ataques de múltiples bytes tendrán éxito. Como resultado, la formación de consultas SQL mediante concatenación de cadenas es frágil y no se recomienda.

Detalles técnicos. Si desea leer sobre los detalles de los ataques, puedo proporcionarle una serie de enlaces que explican los ataques con gran detalle. Hay varios ataques:

• Ataques básicos en, por ejemplo, UTF-8 y otras codificaciones de caracteres consumiendo barras invertidas / comillas adicionales introducidas por la función de comillas: vea, por ejemplo, here .

• Ataques furtivos en, por ejemplo, GBK, que funcionan engañando la función de comillas para introducir una cita adicional para usted: vea, por ejemplo, blog de Chris Shiflett , aquí , o aquí .

• Ataques en, por ejemplo, UTF-8, que ocultan la presencia de una cita mediante el uso de una codificación no canónica (demasiado larga) no válida de la comilla simple: ver, por ejemplo, aquí . Básicamente, la forma normal de codificar una comilla simple se ajusta a una secuencia de un solo byte (es decir, 0x27 ). Sin embargo, también hay secuencias de múltiples bytes que la base de datos puede decodificar como una comilla simple y que no contienen el byte 0x27 ni ningún otro valor de byte sospechoso. Como resultado, las funciones estándar de comillas que escapan pueden fallar al escapar de esas comillas.

Los ataques de varios bytes no se limitan a la inyección SQL. En un sentido general, los ataques de múltiples bytes conducen a una condición de "consumo de bytes" en la que el atacante está eliminando los caracteres de control. Esto es lo opuesto al clásico ' or 1=1-- , en el que el atacante está introduciendo el carácter de control de comilla simple. Para mysql hay mysql_real_escape_string() que está diseñado para solucionar problemas de codificación de caracteres. Las bibliotecas de consultas parametrizadas como PDO utilizarán automáticamente esta función. MySQLi en realidad envía los parámetros de la consulta como un elemento separado dentro de una estructura, lo que evita el problema por completo.

Si una página HTML se procesa a través de Shift-JIS, entonces es posible consumir caracteres de control para obtener XSS. Un excelente ejemplo de esto se proporcionó en " A Tangled Web " (¡libro fantástico!) En la página 207:

<img src="http://fuzzybunnies.com/[0xE0]">...thisisstillapartofthemkarup......butthesreverdosn'tknow..." onload="alert('this will execute!')"
<div>
...page content continues...
</div>

En este caso, 0xE0 es un byte especial que significa el inicio de un símbolo de 3 bytes. Cuando el navegador presente este html, el "> que fluye se consumirá y se convertirá en un solo símbolo Shift-JIS. Si el atacante controla la siguiente entrada por medio de otra variable, puede introducir un controlador de eventos para obtener la ejecución del código.