Inyección SQL

Qué es la inyección SQL

La inyección SQL es una vulnerabilidad que permite a un atacante ejecutar sentencias SQL arbitrarias cuando la entrada del usuario se incorpora a las consultas de base de datos de una aplicación web sin ser procesada adecuadamente. Es una de las vulnerabilidades web más peligrosas que ha estado clasificada en el OWASP Top 10 durante años, y el daño puede extenderse desde el robo, alteración y eliminación de todos los datos de la base de datos hasta la ejecución de comandos del sistema operativo del servidor.

Desde que se reportó públicamente por primera vez en 1998, más de un cuarto de siglo después, la inyección SQL sigue siendo uno de los principales métodos de ataque contra aplicaciones web. A pesar de que las medidas fundamentales son claras, los casos de vulnerabilidades residuales por deficiencias de implementación no cesan.

Principio y tipos de ataque

La inyección SQL ocurre cuando la aplicación construye consultas SQL mediante concatenación de cadenas. Por ejemplo, si el nombre de usuario ingresado en un formulario de inicio de sesión se incrusta directamente en la consulta como SELECT * FROM users WHERE name = 'valor_entrada', cuando el atacante ingresa ' OR '1'='1 como valor de entrada, la cláusula WHERE siempre es verdadera, permitiendo evadir la autenticación.

Principales tipos de ataque

• Basado en UNION: Inyectar UNION SELECT para obtener datos de tablas a las que normalmente no se tiene acceso. Es necesario hacer coincidir el número y tipo de columnas, pero se puede deducir a partir de mensajes de error o cambios en la respuesta.
• Basado en errores: Provocar errores intencionalmente y leer la información de la base de datos (nombres de tablas, nombres de columnas, datos) contenida en los mensajes de error.
• Inyección SQL ciega: Cuando no se muestran mensajes de error, se extrae información bit a bit utilizando bifurcaciones de condiciones booleanas (Boolean-based) o diferencias en el tiempo de respuesta (Time-based).
• Fuera de banda (Out-of-Band): Hacer que la base de datos envíe datos a un servidor externo a través de solicitudes DNS o HTTP.

La existencia de herramientas automatizadas (como sqlmap) permite la detección y explotación de inyecciones SQL sin conocimientos técnicos avanzados.

Realidad del daño y alcance del impacto

El daño por inyección SQL no se limita al robo de datos.

• Robo de datos: Toda la información almacenada en la base de datos puede filtrarse, incluyendo información personal de usuarios, credenciales, números de tarjetas de crédito.
• Alteración y eliminación de datos: Inyectar sentencias UPDATE o DELETE para alterar o eliminar datos. También es posible eliminar tablas completas con DROP TABLE.
• Evasión de autenticación: Manipular la consulta de inicio de sesión para acceder como cualquier cuenta (incluido el administrador) sin conocer la contraseña.
• Toma de control del servidor: Explotar funciones de la base de datos (como LOAD_FILE de MySQL o xp_cmdshell de SQL Server) para ejecutar comandos a nivel de sistema operativo.

Muchos de los grandes incidentes de filtración de información del pasado han involucrado inyección SQL. La detección mediante WAF es una medida auxiliar efectiva, pero también se conocen técnicas para evadir el WAF mediante codificación ingeniosa o inserción de comentarios, por lo que no sustituye las medidas fundamentales.

Medidas fundamentales

Las medidas fundamentales contra la inyección SQL son claras, y si se implementan correctamente, la vulnerabilidad se puede eliminar por completo.

Sentencias preparadas (consultas parametrizadas)

Separan la estructura SQL de los datos, previniendo que la entrada del usuario se interprete como sintaxis SQL. Esta es la medida más segura y recomendada. Todas las bibliotecas de acceso a bases de datos soportan sentencias preparadas.

Uso de ORM

El uso de ORM (Object-Relational Mapping) reduce las oportunidades de escribir SQL directamente, disminuyendo el riesgo de inyección SQL. Sin embargo, al usar funciones de consulta raw o consultas personalizadas del ORM, se requiere la misma precaución que con las sentencias preparadas.

Defensa multicapa

• Principio de privilegios mínimos: Minimizar los privilegios de la cuenta de base de datos utilizada por la aplicación. Usar cuentas de solo lectura para operaciones de solo lectura.
• Validación de entrada: Aceptar solo valores numéricos en campos numéricos, solo formatos apropiados en campos de correo electrónico. Sin embargo, esta es una medida auxiliar y no sustituye las sentencias preparadas.
• Control de mensajes de error: No mostrar directamente los mensajes de error de la base de datos al usuario. Prevenir la filtración de información mediante inyección SQL basada en errores.
• Gestión de vulnerabilidades: Descubrir vulnerabilidades de inyección SQL tempranamente mediante escaneos de seguridad y revisiones de código regulares.
• Configuración de encabezados de seguridad: Aunque no es una medida directa contra la inyección SQL, fortalece la postura de seguridad general.

Conceptos erróneos comunes

Escapar los valores de entrada previene la inyección SQL

El proceso de escape es propenso a errores de implementación y pueden producirse omisiones por diferencias en la codificación de caracteres o casos especiales. Las sentencias preparadas separan fundamentalmente la estructura SQL de los datos, eliminando el riesgo de omisiones de escape. Se deben usar sentencias preparadas en lugar de escape.

Las bases de datos NoSQL no tienen inyección SQL

La inyección SQL no ocurre, pero existe una vulnerabilidad similar llamada inyección NoSQL. En MongoDB, si se incrusta directamente la entrada del usuario en consultas JSON, es posible inyectar operadores de consulta. Independientemente del tipo de base de datos, el procesamiento adecuado de la entrada del usuario es obligatorio.

Comparación entre inyección SQL y XSS

Términos relacionados

Artículos relacionados