Qué es la inyección SQL y por qué funciona: tres formas de entenderla

Cuando empecé con los módulos de inyección SQL en TryHackMe, lo primero que me sorprendió no fue lo complicado que era, sino lo sencillo que resulta el fallo de fondo. La inyección SQL (SQLi) es, probablemente, la vulnerabilidad web que mejor ilustra una idea que ya vimos en los fundamentos: qué pasa cuando un sistema confunde un dato con una instrucción.

Aviso importante: este artículo explica por qué funciona la inyección SQL para entenderla desde el punto de vista defensivo y de aprendizaje. Probar estas técnicas contra sistemas que no son tuyos y sin autorización es ilegal en España (delitos de intrusión informática del Código Penal). Practica solo en laboratorios propios o en plataformas legales como TryHackMe o HackTheBox.

El problema de raíz, en una frase

Muchas webs construyen sus consultas a la base de datos pegando directamente lo que el usuario escribe. Si esa mezcla no se hace con cuidado, lo que el usuario teclea deja de ser tratado como un simple dato y pasa a formar parte de la instrucción que se ejecuta. Ese es todo el secreto.

Un ejemplo mínimo para verlo

Imagina el típico formulario de login. Por detrás, la web podría construir una consulta así:

SELECT * FROM usuarios WHERE usuario = 'lo_que_escribas' AND password = 'tu_clave';

El problema aparece cuando la web coge tu texto y lo mete tal cual entre las comillas, sin comprobarlo. Si en el campo de usuario escribes algo que cierra la comilla y añade su propia lógica, cambias el significado de toda la consulta. La base de datos ya no recibe “busca al usuario X”, sino una instrucción distinta a la que el programador tenía en mente.

Este es exactamente el mismo patrón del archivo con guiones de Bandit, solo que a lo grande: algo que debía ser un dato (tu nombre de usuario) termina interpretándose como instrucción (parte de la consulta SQL).

Tres formas de inyección SQL (para entenderlas, no para ejecutarlas)

Estas son las tres categorías que más aparecen al empezar. Lo importante no es memorizar la sintaxis, sino entender en qué se diferencian por la forma en que el atacante obtiene la información.

1. In-band (o “en banda”)

Es la más directa y la más fácil de entender: el atacante introduce su inyección y el resultado aparece en la misma página. Por ejemplo, una web que muestra los datos de un producto podría acabar mostrando datos de otra tabla si la consulta se manipula para pedir más de lo previsto. Se llama “en banda” porque la información sale por el mismo canal por el que entró: la propia respuesta web.

2. Basada en errores

Aquí el atacante no obtiene los datos directamente, sino que fuerza a la base de datos a producir un error, y ese mensaje de error revela información sobre la estructura interna (nombres de tablas, tipos de datos, versión del gestor). Es una de las razones por las que mostrar errores detallados de base de datos al usuario final es una mala práctica de seguridad: le estás dando pistas gratis a quien intenta atacarte.

3. A ciegas (blind)

La más lenta y la más ingeniosa. La web no muestra ni los datos ni los errores, así que el atacante no puede “leer” la respuesta directamente. En su lugar, hace preguntas de sí/no y deduce la información por cómo se comporta la página:

• Blind basada en booleanos: se comprueba si la página responde distinto ante una condición verdadera o falsa (por ejemplo, si carga o no un contenido).
• Blind basada en tiempo: se introduce una condición que hace que la base de datos tarde más en responder si es verdadera. Midiendo el tiempo de respuesta, se deduce la información letra a letra.

Es como averiguar algo de alguien que solo puede responder con silencios de distinta duración: lento, pero funciona.

Por qué esto conecta con Nmap (y con la fase anterior de un pentest)

Antes de intentar una inyección SQL, un atacante (o un pentester autorizado) necesita saber qué hay ahí delante: qué servidor web, qué servicios, qué versiones. Ese es el trabajo de la fase de reconocimiento, donde entra Nmap.

La relación es de secuencia, no de alternativa:

Entender Nmap no es solo aprender a lanzar un escaneo — es entender que la información que revela (por ejemplo, la versión exacta de un servidor) es lo que luego permite buscar vulnerabilidades conocidas de esa versión concreta. Por eso el artículo de Nmap y este van de la mano: uno es el “mirar antes de tocar”, el otro es una de las cosas que puedes encontrar al mirar.

Cómo se defiende una web de esto (la parte que de verdad importa)

Entender el ataque sirve, sobre todo, para saber cómo evitarlo. Las defensas principales:

• Consultas parametrizadas (prepared statements): la defensa número uno. En lugar de pegar el texto del usuario dentro de la consulta, se envía por separado, de modo que la base de datos nunca lo interpreta como instrucción. Es la solución de raíz.
• Validación de entradas: comprobar que lo que llega tiene el formato esperado (un email parece un email, un número es un número).
• Principio de mínimo privilegio: que la cuenta de base de datos que usa la web solo pueda hacer lo justo, para que un fallo no lo comprometa todo.
• No mostrar errores detallados al usuario final, para no regalar información sobre la estructura interna.

Pon a prueba lo que has entendido

Resumen rápido

• La inyección SQL ocurre cuando una web mezcla el texto del usuario con su consulta sin separarlos bien, y ese texto acaba ejecutándose como parte de la instrucción.
• Es el mismo patrón “dato confundido con instrucción” de los fundamentos, aplicado a una base de datos.
• Tres formas de entenderla: in-band (el dato sale por la propia web), basada en errores (los mensajes de error revelan información) y a ciegas (se deduce por el comportamiento, sin ver datos directamente).
• Nmap y el reconocimiento vienen antes de cualquier explotación: primero se mira qué hay, luego se actúa.
• La defensa de raíz son las consultas parametrizadas: que el dato del usuario nunca pueda convertirse en instrucción.