drupal 6 – Previniendo la inyección de SQL

Pregunta:

En Drupal 6, las consultas se emiten con db_query() . Usando% -modifiers, los argumentos de la consulta se sustituyen en la consulta después de filtrarse. Las cadenas% s (y solo las cadenas) finalmente se ejecutan a través de mysqli_real_escape_string() (usando db_escape_string() ).

Mirando los documentos php para mysqli_real_escape_string() , veo la siguiente advertencia de seguridad:

El conjunto de caracteres debe establecerse a nivel de servidor o con la función API mysqli_set_charset() para que afecte a mysqli_real_escape_string() .

La respuesta a otra pregunta sobre mysql_real_escape_string / SQL Injection explica que:

Otra forma de meterse en problemas usando mysql_real_escape_string es cuando configuras la codificación de la conexión de la base de datos usando el método incorrecto. Usted debe hacer esto:

mysql_set_charset('utf8', $link);

Sin embargo, también puedes hacer esto:

mysql_query("SET NAMES 'utf8'", $link);

El problema es que este último pasa por alto la API mysql_, que todavía cree que estás hablando con la base de datos usando latin1 (o algo más). […] Esto se puede utilizar para ataques de inyección en determinadas situaciones de cadenas multibyte.

Drupal no llama a mysqli_set_charset (), sino que emite la consulta 'SET NAMES utf8'. Esto se puede ver en db_connect () .

Para proteger adecuadamente Drupal 6 contra la inyección SQL, ¿es necesario configurar el juego de caracteres en el nivel del servidor?

Respuesta:

Esta respuesta a una pregunta de stackoverflow hace un gran trabajo al explicar el ataque que puede sortear mysqli_real_escape_string () usando conjuntos de caracteres multibyte.

Llegué a la conclusión de que cuando ejecutamos Drupal 6, no tenemos que configurar el juego de caracteres en el nivel del servidor para estar a salvo del ataque.

Drupal siempre configura el cliente en UTF8 (y no en los conjuntos de caracteres GBK o BIG-5 que se requieren para el exploit). Las versiones más recientes de MySQL (> 5.1) tampoco son vulnerables.

SIN EMBARGO, aunque Drupal está a salvo de este exploit, debemos seguir la documentación de instalación que dice: "La base de datos debe crearse con codificación UTF-8 (Unicode), por ejemplo utf8_general_ci".

Un comentario útil sobre los documentos de instalación describe cómo crear su base de datos con codificación UTF8 y cómo asegurarse de que se utilice UTF8 al realizar una copia de seguridad / restauración:

Para lograr esto mediante la interfaz de línea de comandos de mysql, use los siguientes comandos:
$ mysql -u root -p # Login
mysql> CREATE DATABASE databasename CHARACTER SET utf8; # Create with utf-8

Cuando use mysqldump / mysql para realizar copias de seguridad / restaurar, también fuerce tanto al servidor como al cliente a utf8 insertando en /etc/mysql/my.cnf :
default-character-set = utf8 # Server
skip-character-set-client-handshake # Force client

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

web tasarım