Resumen ejecutivo

• Una inyección SQL ocurre cuando una aplicación mete texto ingresado por el usuario directamente dentro de una consulta SQL, y ese texto cambia lo que la consulta hace.

• Los tipos más comunes son la clásica (in-band), la ciega (blind) y la basada en errores; todas pueden exponer, modificar o borrar datos.

• La inyección sigue dentro del OWASP Top 10, la lista de referencia de riesgos en aplicaciones web.

• La defensa principal son las consultas parametrizadas, complementadas con ORM bien usado, validación por lista permitida y mínimos privilegios en la base.

La inyección SQL es una de esas vulnerabilidades que parecen de otra época y, sin embargo, siguen apareciendo en aplicaciones reales. Entenderla bien te sirve dos veces: para escribir código más seguro y para responder una de las preguntas clásicas de entrevistas de backend y ciberseguridad. El ángulo de esta guía es concreto: un login vulnerable explicado paso a paso, los tipos de ataque y cómo prevenirlo con buenas prácticas. ¿Por qué ahora? Porque une dos temas con mucha demanda, SQL y seguridad, y casi no hay explicaciones en español que vayan del ejemplo a la solución. Si querés el contexto general del área, empezá por ciberseguridad: qué es, tipos de amenazas y por qué es una carrera tan demandada.

Qué es una inyección SQL

Una aplicación web suele armar consultas SQL para buscar usuarios, productos o pedidos. Si en lugar de tratar lo que escribe el usuario como dato lo concatena como parte del código SQL, un atacante puede escribir algo que altere la lógica de la consulta. La guía de prevención de OWASP explica que estos fallos aparecen cuando se construyen consultas dinámicas concatenando cadenas con datos ingresados por el usuario.

Ejemplo: un login vulnerable

Imaginá un formulario con usuario y contraseña, y un backend que arma la consulta así:

Código vulnerable: consulta = "SELECT * FROM usuarios WHERE usuario = '" + usuario + "' AND clave = '" + clave + "'"

Si alguien escribe en el campo usuario el texto admin' --, la consulta final queda así:

Consulta resultante: SELECT * FROM usuarios WHERE usuario = 'admin' --' AND clave = '...'

En muchos motores, -- inicia un comentario: todo lo que sigue se ignora, incluida la verificación de la contraseña. Resultado: el atacante entra como admin sin conocer la clave. Otra variante clásica es ingresar ' OR '1'='1, que convierte la condición en algo siempre verdadero.

Tipos de inyección SQL

Clásica o in-band

El atacante ve el resultado en la misma respuesta de la aplicación. Una técnica típica es usar UNION para sumar datos de otras tablas a lo que muestra la página.

Basada en errores

Aprovecha mensajes de error detallados de la base de datos que la aplicación muestra al usuario, y que revelan nombres de tablas, columnas o versiones.

Ciega (blind)

La aplicación no muestra datos ni errores, pero responde distinto según si una condición es verdadera o falsa (booleana), o tarda más en responder (basada en tiempo). Con paciencia, el atacante deduce la información de a un dato por vez. PortSwigger Web Security Academy tiene laboratorios gratuitos para entender cada tipo de forma legal y controlada.

Por qué sigue en el OWASP Top 10

En la edición más reciente del OWASP Top 10, la categoría Injection aparece en el puesto 5. OWASP señala que es una de las categorías más testeadas, que el 100% de las aplicaciones analizadas se probó contra alguna forma de inyección y que la inyección SQL acumula más de 14.000 CVE registrados. Es decir: es de baja frecuencia relativa, pero de alto impacto cuando aparece.

Las razones de fondo son conocidas: código heredado, consultas armadas a mano "por apuro", procedimientos almacenados que concatenan texto y equipos que asumen que el framework los protege siempre.

Cómo prevenirla

1. Consultas parametrizadas (prepared statements): es la defensa principal. Escribís la consulta con marcadores (por ejemplo, WHERE usuario = ?) y pasás los valores por separado; la base los trata siempre como datos, nunca como código.

2. ORM bien usado: herramientas como Sequelize, Prisma, Hibernate o el ORM de Django parametrizan por defecto. Ojo con los métodos de "consulta cruda" que permiten concatenar texto.

3. Procedimientos almacenados seguros: sirven solo si no arman SQL dinámico concatenando entradas.

4. Validación por lista permitida: para partes que no se pueden parametrizar, como nombres de columnas u orden ASC/DESC, aceptá solo valores definidos en tu código.

5. Mínimos privilegios: el usuario de base de datos de la aplicación no debería poder borrar tablas ni leer lo que no necesita.

6. Errores genéricos: no muestres mensajes de error de la base al usuario final; registralos en logs internos.

7. Testing de seguridad: revisión de código y herramientas de análisis estático y dinámico en el pipeline de CI/CD, como recomienda OWASP.

Escapar caracteres a mano no es una defensa confiable: OWASP la desaconseja fuertemente frente a las consultas parametrizadas.

Cómo practicar de forma legal

• Usá laboratorios diseñados para eso (como los de PortSwigger) o aplicaciones vulnerables a propósito en tu propia computadora.

• Nunca pruebes ataques en sitios o sistemas sin autorización escrita: además de no ser ético, puede ser delito.

• Repasá tus bases de SQL para entender qué hace cada consulta; si estás empezando, mirá cómo aprender SQL desde cero.

Cursos recomendados de Coderhouse

Si te interesa el lado defensivo, el Curso de Ciberseguridad te da el panorama de amenazas y controles. Si sos developer, la Carrera de Desarrollo Backend te enseña a construir APIs y a trabajar con bases de datos con buenas prácticas. Y para dominar el lenguaje, el Curso de SQL es la base.

CTA: buscá en tu último proyecto cualquier consulta armada concatenando texto y reemplazala por una consulta parametrizada. Si querés profundizar en seguridad aplicada, mirá el Curso de Ciberseguridad de Coderhouse.

Preguntas frecuentes

¿Usar un ORM me protege por completo? Te protege en la mayoría de los casos, siempre que no uses consultas crudas concatenando entradas del usuario.

¿La inyección SQL solo afecta a logins? No. Cualquier parámetro que llegue a una consulta (buscadores, filtros, URLs, cookies o cabeceras) puede ser un punto de entrada.

¿Qué diferencia hay entre inyección SQL y XSS? La inyección SQL ataca la base de datos a través de consultas; el XSS inyecta scripts que se ejecutan en el navegador de otros usuarios. OWASP agrupa ambas en la categoría Injection.

¿Es una pregunta frecuente en entrevistas? Sí, sobre todo en puestos de backend y seguridad. Explicar el ejemplo del login y la solución con consultas parametrizadas suele ser lo que se espera.