FlawOpen

flawopen.com/Inyección SQL

Inyección SQL

Crítica CWE-89
Idioma: English Português (Brasil) Español Français Deutsch Русский 简体中文 日本語 हिन्दी 한국어 Bahasa Indonesia

La inyección SQL ocurre cuando una aplicación construye una consulta pegando la entrada del usuario en el texto SQL, y la base de datos interpreta parte de esa entrada como órdenes. La corrección es la misma en todos los lenguajes: enviar la consulta con marcadores y pasar los valores por separado. Elige tu lenguaje abajo para ver las llamadas de API exactas, el código vulnerable y el corregido, y las reglas de CI que lo detectan.

Explicación en Lenguaje Sencillo (ELI5)

Le das a un bibliotecario una papeleta que dice 'Traer la ficha de: ___' y en el hueco escribes: 'Juan. Y además abre el archivo y trae todas las carpetas.' Un bibliotecario que lee la papeleta entera como una sola orden hace ambas cosas. Pegar la entrada del usuario en una cadena SQL construye exactamente esa papeleta. Una consulta parametrizada es un formulario impreso con una casilla sellada que dice 'nombre': lo que se escriba dentro solo se busca como nombre, diga lo que diga.

Conceptos Clave y Términos

SQL injection (CWE-89)
La entrada no fiable se concatena o se formatea en el texto SQL, así que las comillas, palabras clave y operadores de la entrada cambian la estructura de la consulta en lugar de tratarse como un solo valor.
Prepared statement and bind parameters
La consulta se envía con marcadores (?, $1, :name) y se analiza antes de que llegue ningún valor; los valores viajan por separado y siempre se tratan como datos. Es la defensa principal en todo driver y ORM.
Blind SQL injection
Cuando la página no muestra resultados ni errores, el atacante deduce los datos bit a bit por las diferencias en la respuesta (basada en booleanos) o en su tiempo (basada en tiempo). Que no haya salida visible no significa que no haya fallo.
Second-order SQL injection
Un valor se guarda de forma segura, luego se lee de tu propia base de datos y se concatena en otra consulta. Toda consulta debe ir parametrizada, incluidas las que reciben datos de tus propias tablas.
Identifiers and allowlists
Los marcadores solo llevan valores, no nombres de tabla, nombres de columna ni sentidos de ordenación. Esos deben elegirse de una lista permitida fija en el código, nunca copiarse de la petición.

Flujo de Ataque Paso a Paso

Paso 1

La entrada llega a una consulta

Un campo de formulario, un parámetro de URL, una cabecera o un campo de API se pasa al código que construye una sentencia SQL.

Paso 2

La entrada se pega en el texto SQL

La concatenación, la interpolación o el formateo insertan el valor directamente. El valor de prueba inofensivo ' OR '1'='1 convierte WHERE name = '...' en una condición siempre verdadera.

Paso 3

La base de datos la interpreta como sintaxis

La base de datos recibe una sola cadena, no sabe qué parte vino del usuario y ejecuta la sentencia alterada con los privilegios de la aplicación.

Paso 4

Los datos se leen, cambian o borran

Según la consulta y la cuenta, el atacante se salta un login, vuelca tablas con consultas UNION o extrae datos a ciegas. La brecha de MOVEit Transfer de 2023 (CVE-2023-34362) empezó con este tipo de fallo.

Guías de inyección SQL por lenguaje

Python JavaScript Go Java PHP C# Ruby C/C++ Rust Kotlin Swift

Lista de Verificación de Seguridad para Ingeniería

Fuentes

Lecturas relacionadas

Consultas parametrizadas explicadas ¿Basta con un ORM? ¿Evitan los procedimientos almacenados la inyección SQL? Inyección SQL en MOVEit Transfer (2023) Inyección en psql de PostgreSQL (2024)