Cómo elegir un escáner de inyección SQL

Supongamos, por ejemplo, que el valor introducido en un formulario de búsqueda se incorpora directamente como parte de una sentencia SQL. Las pruebas dinámicas envían solicitudes reales y buscan problemas a partir de indicios como las diferencias entre las respuestas. El análisis de código sigue el recorrido del valor desde su punto de entrada hasta la consulta a la que se pasa.

Las pruebas dinámicas no pueden examinar una interfaz o una API a la que no logran acceder. El análisis de código también puede pasar por alto problemas, según los lenguajes y frameworks compatibles y la configuración del alcance del análisis. Aunque uno de los métodos no encuentre ningún problema, no se puede concluir que el otro sea innecesario.

ZAP: es una opción de código abierto para revisar una aplicación web en su conjunto. Cuenta con reglas de escaneo activo para detectar inyecciones SQL y permite buscar también otras vulnerabilidades web. Sin embargo, ZAP Baseline realiza un escaneo pasivo de forma predeterminada, por lo que ejecutarlo no basta para afirmar que se han realizado pruebas activas de inyección SQL.

sqlmap: es una herramienta de código abierto adecuada cuando se sospecha de un punto de entrada concreto y se quiere centrar la comprobación en la inyección SQL. Como incluye funciones para automatizar la explotación, además de la detección, debe utilizarse con un alcance autorizado bien definido y en un entorno donde se pueda limitar el impacto.

Burp Suite Professional: está orientado a quienes quieren combinar el escáner con comprobaciones manuales mientras revisan las solicitudes HTTP. El escáner automático se incluye en ediciones de pago como Professional, pero no en la versión gratuita Community Edition.

Wapiti: es una herramienta de código abierto que permite examinar aplicaciones web como caja negra desde la línea de comandos. Su documentación oficial describe pruebas de inyección SQL basadas en errores, valores booleanos y diferencias de tiempo, así como escaneos de API mediante archivos OpenAPI. Comprueba en cada caso si puede acceder a las rutas necesarias en aplicaciones que incluyan SPA o autenticación compleja.

Todas estas herramientas envían solicitudes a aplicaciones en funcionamiento. Registra junto con los resultados hasta dónde han logrado acceder, teniendo en cuenta no solo las interfaces, sino también las API accesibles tras la autenticación, los paneles de administración y los permisos de cada usuario. El análisis estático del código fuente se combina con ellas como una opción aparte.

En un mismo entorno de preproducción, prepara entradas con problemas conocidos y entradas parametrizadas de forma segura para compararlas. Además de comprobar si la herramienta detecta las primeras, verifica que no marque erróneamente las segundas como problemáticas. Comprueba también que las pruebas no se hayan detenido a mitad de camino por haber caducado la autenticación y que se hayan recorrido todos los puntos de entrada necesarios, incluidas las API que utilizan JSON.

El escaneo puede afectar a los datos de prueba o a la disponibilidad. Obtén autorización explícita del propietario del sistema que vas a examinar y acuerda el alcance, el horario de ejecución, la carga y las operaciones que se excluirán. Si es posible, haz las pruebas en un entorno separado del de producción.

En el registro de NVD sobre CVE-2023-34362 de MOVEit Transfer se indica que una inyección SQL podría permitir a un atacante no autenticado acceder a la base de datos; también se documenta su explotación entre mayo y junio de 2023. Durante el desarrollo, es necesario revisar no solo los procesos posteriores al inicio de sesión, sino también las rutas públicas. El siguiente ejemplo didáctico ficticio utiliza TypeScript y node-postgres: no representa la implementación de MOVEit ni es código que reproduzca esa CVE. Limita las pruebas a los sistemas para los que tengas autorización.

La corrección básica consiste en pasar los valores externos como parámetros, en lugar de concatenarlos en una cadena SQL. Sin embargo, en algunos casos la estructura misma del SQL, como el orden de los resultados o los nombres de las tablas, no se puede gestionar únicamente vinculando valores a parámetros. En esos casos, hay que elegir entre opciones fijas definidas en la aplicación.

En el siguiente ejemplo, el valor de búsqueda se vincula a un parámetro y el orden se elige entre dos consultas fijas. Además, los permisos del usuario de la base de datos deben limitarse al mínimo necesario, y hay que comprobar por separado que el usuario de la aplicación tenga permiso para ver esos datos. Después de corregir el problema, vuelve a verificar que el hallazgo original se haya resuelto y que las búsquedas habituales sigan funcionando.

import type { Pool } from "pg";

export async function findProducts(
  db: Pool, name: string, sort: string,
) {
  const queries = {
    newest: "SELECT id, name FROM products WHERE name = $1 ORDER BY created_at DESC, id DESC LIMIT 50",
    oldest: "SELECT id, name FROM products WHERE name = $1 ORDER BY created_at ASC, id ASC LIMIT 50",
  } as const;
  if (sort !== "newest" && sort !== "oldest") {
    throw new Error("Invalid sort");
  }
  return db.query(queries[sort], [name]);
}