INYECCIÓN SQL
ANDRÉS FELIPE MOYA GORDILLO
CORPORACIÓN UNIVERSITARIA MINUTO DE DIOS – UNIMINUTO
FACULTAD DE INGENIERÍA
ELECTIVA – SEGURIDAD DE APLICACIONES WEB
INGENIERO JUAN CARLOS VARGAS
BOGOTÁ. D.C – 27 DE ENERO DEL 2025
INTRODUCCIÓN
Por medio de este informe, hablaremos sobre la inyección SQL, que es y como puede afectar nuestros
aplicativos web, también haremos una revisión de un sitio web para ver el análisis sobre una inyección
SQL.
INYECCIÓN SQL
La inyección de lenguaje de consulta estructurada (SQL*) es una técnica de inyección de
código utilizada para modificar o recuperar datos de bases de datos SQL. Mediante la inserción
de sentencias SQL especializadas en un campo de entrada, un atacante es capaz de ejecutar
comandos que permiten la recuperación de datos de la base de datos, la destrucción de datos
confidenciales u otros comportamientos manipuladores.
Con la ejecución de comandos SQL adecuada, el usuario no autorizado es capaz de suplantar
la identidad de un usuario con más privilegios, convertirse a sí mismo o a otros en
administradores de la base de datos, manipular los datos existentes, modificar las transacciones
y los balances, y recuperar o destruir todos los datos del servidor.
En la informática moderna, la inyección de código SQL suele producirse a través de Internet
mediante el envío de consultas SQL maliciosas a un punto final de la API proporcionado por un
sitio web o un servicio (más información al respecto más adelante). En su forma más grave, la
inyección de código SQL puede permitir que un atacante consiga acceso raíz a una máquina, lo
que le da el control total.
*SQL es un lenguaje de programación usado para mantener la mayoría de las bases de datos.
¿Cómo funcionan los ataques de inyección de SQL?
Para entender la inyección de SQL, es importante saber qué es el lenguaje de consulta
estructurado (SQL). SQL es un lenguaje de consulta que se utiliza en programación para
modificar y eliminar los datos almacenados en bases de datos relacionales y acceder a ellos.
Debido a que la gran mayoría de los sitios y aplicaciones web utilizan bases de datos SQL, un
ataque de inyección de SQL puede tener consecuencias graves para las organizaciones.
Una consulta de SQL es una solicitud enviada a una base de datos por algún tipo de actividad o
función, como consultas de datos o una ejecución de código SQL que se debe realizar. Un
ejemplo es cuando la información de inicio de sesión se envía a través de un formulario web
para que el usuario pueda acceder al sitio. Normalmente, este tipo de formulario web está
diseñado para aceptar solo tipos muy específicos de datos, como un nombre o una contraseña.
Cuando se agrega esa información, esta se coteja contra una base de datos y, si coincide, se
otorga acceso al usuario. Si no coincide, se niega el acceso.
Los posibles problemas surgen porque la mayoría de los formularios web no tienen forma de
detener el ingreso de información adicional. Los atacantes pueden aprovechar esta debilidad y
utilizar los cuadros de entrada del formulario para enviar sus propias solicitudes a la base de
datos. Esto podría permitirles llevar a cabo una amplia gama de actividades maliciosas, desde
el robo de datos confidenciales hasta la manipulación de la información de la base de datos
para sus propios fines.
Aquí tenemos algunos ejemplos:
Consulta SQL normal:
En esta consulta SQL normal, la cadena studentId se pasa a una sentencia SQL. El objetivo es
buscar un alumno en la lista de estudiantes que coincida con el studentId introducido. Una vez
encontrado, se devolverá el registro de ese estudiante. En pocas palabras, el comando dice "ve
a buscar a este usuario y dame sus datos".
El código podría ser algo así:
studentId = getRequestString("studentId");
lookupStudent = "SELECT * FROM students WHERE studentId = " + studentId
Si un estudiante introduce una identificación de estudiante de 117 en un formulario de la página
web etiquetado como "Por favor, introduce tu número de identificación de estudiante
Consulta de inyección de código SQL:
En este ejemplo, un atacante en vez de introducir un comando SQL o una lógica condicional en
el campo de entrada, introduce un número de identificación de estudiante.
Donde normalmente la consulta buscaría en la tabla de la base de datos la ID correspondiente,
ahora busca una ID o comprueba si 1 es igual a 1. Como es de esperar, la sentencia es
siempre verdadera para cada estudiante de la columna, y como resultado, la base de datos
devolverá todos los datos de la tabla de estudiantes al atacante que realiza la consulta.
SELECT * FROM students WHERE studentId = 117 OR 1=1;
Tipos de inyección
Según la forma de acceso a los datos de backend y la extensión del posible daño provocado,
las inyecciones de SQL se pueden dividir en las siguientes tres categorías:
SQLi en banda:
Este tipo de ataque SQLi es sencillo para los atacantes, porque usan el mismo canal de
comunicación para lanzar ataques y obtener resultados. Este tipo de ataque SQLi tiene dos
subvariantes:
SQLi basado en errores: la base de datos genera un mensaje de error por las acciones del
atacante. El atacante obtiene información sobre la infraestructura de la base de datos en
función de los datos que generaron estos mensajes de error.
SQLi basado en unión: el atacante usa el operador UNION SQL para obtener los datos
deseados mediante la fusión de varias declaraciones Select en una única respuesta HTTP.
SQLi inferencial (también conocida como inyección de SQL ciega):
En este tipo de SQLi, los atacantes usan patrones de respuesta y comportamiento del servidor
después de enviar cargas útiles de datos para obtener más información sobre su estructura.
Los datos no se transfieren de la base de datos del sitio web al atacante, así que el atacante no
ve la información sobre el ataque en banda (por eso se usa el término “SQLi ciega”). La SQLi
inferencial se puede clasificar en dos subtipos:
SQLi basado en el tiempo: los atacantes envían una consulta de SQL a la base de datos, esto
hace que la base de datos espere unos segundos antes de responder si la consulta es
verdadera o falsa.
SQLi booleana: los atacantes envían una consulta de SQL a la base de datos, así permiten que
la aplicación responda mediante la generación de un resultado verdadero o falso.
SQLi fuera de banda:
Este tipo de ataque de SQL se puede llevar a cabo en las siguientes dos situaciones:
Cuando los atacantes no pueden usar el mismo canal para lanzar el ataque y compartir
información; o
cuando un servidor es demasiado lento o inestable para realizar estas acciones.
Para esta prueba, tomamos en cuenta el sitio web de una empresa llamada TaskUS, una
empresa de sector BPO de origen americano, la cual tiene sede en la ciudad de Cali Colombia.
Para las pruebas utilizamos la web PageSpeed.
PROPUESTAS PARA LA PROTECCIÓN DEL SITIO WEB
Una propuesta para la protección de sitio es hacer revisión del código fuente del sitio, este es el
más fundamental al momento de crear capas de seguridad.
Otra propuesta sería crear un cortafuegos contra ataques de ciberseguridad.
También se pueden utilizar estrategias más enfocadas a la protección de fuga de datos como
por ejemplo:
Uso de sentencias preparadas (con consultas parametrizadas): este método de sanear las
entradas de la base de datos implica obligar a los desarrolladores a definir primero todo el
código SQL y, a continuación, a pasar solo parámetros específicos a la consulta SQL; los datos
introducidos reciben explícitamente un alcance limitado que no pueden sobrepasar. Esto
permite que la base de datos distinga entre los datos que se introducen y el código que se va a
ejecutar, independientemente del tipo de datos introducidos en el campo de entrada. Algunas
bibliotecas de asignación objeto-relacional (ORM) se suelen utilizar para este propósito, ya que
algunas versiones sanean las entradas de la base de datos automáticamente.
Eludir toda la entrada suministrada por el usuario: cuando se escribe SQL, algunos caracteres o
palabras específicas tienen un significado particular. Por ejemplo, el carácter '*' significa
"cualquiera" y la palabra "O" es un condicional. Para evitar que los usuarios introduzcan estos
caracteres de forma accidental o malintencionada en una solicitud de la API a la base de datos,
se puede eludir la entrada suministrada por el usuario. Eludir un carácter es la forma de decirle
a la base de datos que no lo analice como un comando o condicional, sino que lo trate como
una entrada literal.
Uso de procedimientos almacenados: aunque no es una estrategia de seguridad robusta por sí
misma, los procedimientos almacenados pueden ayudar a limitar el riesgo asociado a la
inyección de código SQL. Al limitar adecuadamente los permisos de la cuenta de la base de
datos que ejecuta las consultas SQL, incluso el código de aplicación no robusto que es
vulnerable a la inyección SQL carecerá de los permisos necesarios para manipular tablas de la
base de datos no relacionadas. Los procedimientos almacenados también pueden comprobar el
tipo de los parámetros de entrada, impidiendo que se introduzcan datos que incumplan el tipo
que el campo está diseñado para recibir. En los casos en que las consultas estáticas sean
insuficientes, los procedimientos almacenados suelen evitarse.
Aplicar el mínimo privilegio: como regla general, en todos los casos en los que un sitio web
necesite utilizar SQL dinámico, es importante reducir la exposición a la inyección de código SQL
limitando los permisos al ámbito más estrecho necesario para ejecutar la consulta pertinente.
En su forma más obvia, esto significa que una cuenta administrativa no debería, en ningún
caso, ejecutar comandos SQL como resultado de una llamada a la API de una solicitud no
autorizada. Aunque los procedimientos almacenados se utilizan mejor para las consultas
estáticas, la aplicación de los privilegios mínimos puede ayudar a reducir los riesgos de las
consultas SQL dinámicas.
BIBLIOGRAFÍA
¿Qué es la inyección de código SQL? | cloudflare. Available at: [Link]
es/learning/security/threats/sql-injection/ (Accessed: 28 January 2025).
Kaspersky (2018) Inyección de SQL Y Cómo prevenirla, /. Available at:
[Link]
srsltid=AfmBOorr8GPOfGaCcO_JMxLpys1rvWX5GDlstXUbNF6LhlvFF1u8w3is (Accessed: 27
January 2025).
Page Speed (no date) Pagespeed Insights. Available at:
[Link]
(Accessed: 27 January 2025).