¿Qué es la inyección SQL?

Inyección SQL: definición y causa

Las aplicaciones web suelen guardar clientes, pedidos y contenidos en una base de datos SQL y la consultan con comandos SQL. Si un comando así se construye insertando sin más las entradas del usuario en el texto, un atacante puede alterar la estructura del comando. La base de datos ya no puede distinguir entonces entre código y datos.

La causa es casi siempre la misma: las entradas de formularios, campos de búsqueda, cookies o parámetros de dirección se incorporan sin comprobar a las consultas a la base de datos. La inyección SQL forma parte desde hace años de la categoría «Injection» del OWASP Top 10, aunque la contramedida eficaz se conoce desde hace mucho. Afecta sobre todo a soluciones a medida antiguas y a plugins sin mantenimiento.

Cómo funciona un ataque

En lugar de un término de búsqueda, un atacante introduce un fragmento de texto que altera la consulta original, por ejemplo de modo que una condición sea siempre verdadera. Así pueden eludirse comprobaciones de inicio de sesión, leerse datos de otras tablas o modificarse entradas, en casos extremos incluso borrarlas. Los atacantes comprueban miles de sitios con herramientas automatizadas en busca de estas debilidades; los mensajes de error de la base de datos mostrados sin filtrar les facilitan el trabajo.

• Fuga de datos: se leen datos de clientes, pedidos o credenciales
• Manipulación: se modifican precios, contenidos o cuentas
• Elusión: se aceptan inicios de sesión sin una contraseña válida
• En el peor de los casos: toma de control del servidor de base de datos o de otros sistemas

Ejemplo práctico: el viejo filtro de la tienda

Un comercio especializado opera una tienda web basada en una solución antigua programada a medida. El filtro de productos construye la consulta a la base de datos directamente a partir del parámetro de la dirección. Un atacante modifica el parámetro y puede así recuperar tablas con datos de clientes; el comerciante solo se da cuenta cuando los clientes reciben correos fraudulentos con los datos reales de sus pedidos. El daño: pérdida de confianza, esfuerzo y, posiblemente, obligaciones de notificación.

La solución es puro oficio: las consultas se convierten en sentencias parametrizadas, se restringen los privilegios de base de datos de la tienda y se ocultan los mensajes de error hacia fuera. Un firewall de aplicaciones web ofrece una protección adicional, pero no sustituye la corrección en el código. Tras el incidente queda por aclarar qué datos se vieron afectados.

Medidas de protección y puesta en práctica

La protección más eficaz son las sentencias preparadas (consultas parametrizadas), en las que comando y datos permanecen estrictamente separados. Los ORM y los frameworks modernos las utilizan por defecto, siempre que las consultas no se construyan concatenando texto. Ayudan además la validación de entradas según una lista de valores permitidos, un usuario de base de datos con privilegios mínimos, software actualizado y pruebas de seguridad específicas.

Nano Concepts revisa código y configuraciones con revisiones de código y análisis de vulnerabilidades, corrige fallos en aplicaciones existentes y desarrolla software nuevo según estándares seguros desde el principio. En las soluciones a medida antiguas suele ser aconsejable una modernización gradual en lugar de reparaciones de emergencia permanentes, para que la seguridad no dependa de puntos aislados.

• Construir SQL concatenando entradas del usuario
• Usar un usuario de base de datos con privilegios de administrador para el sitio web
• Mostrar errores detallados de la base de datos en el navegador
• Confiar solo en filtros de entrada («eliminar caracteres especiales»)
• Seguir operando plugins obsoletos y scripts heredados