El OWASP Top 10, tal y como lo aplica realmente un WAF

Qué es en realidad el Top 10

OWASP —el Open Worldwide Application Security Project— publica una lista clasificada de categorías de riesgo de aplicaciones web, revisada cada pocos años a partir de datos reales de incidentes y escaneos. La lista actual la encabezan la pérdida de control de acceso, los fallos criptográficos y la inyección.

De cómo está construida se derivan dos cosas, y las dos se pierden en el discurso comercial de los proveedores.

Son categorías, no vulnerabilidades. "Inyección" cubre la inyección SQL, la inyección de comandos, la inyección LDAP y la inyección de plantillas. Un producto no puede "soportar" una categoría; solo puede detectar técnicas concretas dentro de ella.

Es una herramienta de priorización para quienes construyen la aplicación. Te dice dónde invertir el tiempo de revisión. Nunca fue una checklist de cumplimiento, y un firewall delante de una aplicación no hace que la lista desaparezca.

Qué es un WAF, en un párrafo

Un firewall de aplicaciones web se sitúa delante de tu aplicación e inspecciona cada petición —la ruta, la cadena de consulta, las cabeceras, las cookies y el cuerpo— contra un conjunto de reglas. Cuando una regla coincide, la petición se bloquea, se registra, o ambas cosas, antes de que tu aplicación llegue siquiera a ejecutarse.

El conjunto de reglas abierto sobre el que se construyen la mayoría de los WAF es el OWASP Core Rule Set (CRS), un conjunto de reglas de detección genéricas mantenido por la misma fundación. Es el conjunto de reglas que ejecutamos, sobre ModSecurity, en el edge. El CRS agrupa sus reglas en familias con rangos numéricos —941 para cross-site scripting, 942 para inyección SQL, 930 para inclusión local de archivos, 931 para inclusión remota de archivos, 932 para ejecución remota de comandos, 933 para inyección PHP— que es por lo que una petición bloqueada se puede rastrear hasta un número de regla exacto en lugar de una vaga "política de seguridad".

Categoría por categoría: qué hace realmente el firewall

Inyección — aquí un WAF es realmente fuerte. La inyección SQL, la inyección de comandos y la inyección de plantillas dejan todas formas reconocibles en los datos de la petición. Esto es en lo que la comparación de patrones es buena, y las reglas atrapan de plano la mayoría de los intentos oportunistas. No hace que las consultas parametrizadas sean opcionales; te compra tiempo y frena a la mayoría automatizada.

Cross-site scripting — fuerte, con matices. Las cargas de script en parámetros son detectables. Un XSS almacenado que llega por una ruta que el firewall no inspecciona, o un problema basado en el DOM que nunca toca tu servidor, está fuera de su alcance.

Configuración de seguridad incorrecta — en parte. Un WAF puede ocultar el banner del servidor, bloquear el acceso a .git y a archivos de copia de seguridad, y rechazar métodos peligrosos. No puede arreglar una política CORS permisiva ni un panel de administración con una contraseña por defecto.

Componentes vulnerables y desactualizados — en parte, y temporalmente. Cuando una CVE se hace pública, las reglas genéricas a menudo atrapan la forma del exploit publicado, que es todo el valor del "parcheo virtual": te compra los días entre la divulgación y tu ventana de actualización. No sustituye a actualizar.

Pérdida de control de acceso — en su mayor parte, no. Si tu aplicación deja que el usuario A obtenga la factura del usuario B cambiando un ID en la URL, las dos peticiones le parecen idénticas a un firewall. No tiene ni idea de quién es el dueño de la factura 4711. Esta es la categoría que encabeza la lista actual y es un fallo de autorización en tu código.

Fallos de identificación y autenticación — en parte. El rate limiting en los endpoints de login suaviza el credential stuffing y la fuerza bruta, que es real y vale la pena tener. Una gestión de sesión débil o un flujo de restablecimiento de contraseña que filtra tokens no es algo que un firewall vea.

Diseño inseguro y fallos de integridad del software — no. Son cuestiones arquitectónicas. Ningún patrón de petición las expresa.

El problema de los falsos positivos, y por qué lo decide todo

Cualquier conjunto de reglas lo bastante agresivo como para atrapar la inyección a veces bloqueará a un humano. El caso clásico es un editor de contenido guardando un artículo que contiene un ejemplo de código, o un formulario de soporte donde alguien pega un mensaje de error que contiene SQL. La petición es legítima; simplemente parece un ataque.

Aquí es donde los WAF se ganan o se pierden operativamente. Si un falso positivo significa "el sitio está roto para esa persona y nadie puede explicar por qué", el WAF se apaga en menos de un mes — que es el peor resultado posible, porque la protección desaparece silenciosamente mientras todo el mundo cree que sigue activa.

Lo que lo hace sobrevivible es la trazabilidad. En nuestro edge, una petición bloqueada devuelve una página 403 de marca propia con un ID de referencia, y ese ID se corresponde con la entrada del registro de auditoría con la regla que coincidió y el campo en el que coincidió. Una conversación de soporte se convierte en "la regla 942100 coincidió con el campo content en la URL del editor" en lugar de "la web me bloquea a veces". La solución es entonces una exclusión estrecha: esa regla, ese campo, esa ruta. No la familia de reglas, y no el sitio.

Niveles de paranoia: el dial que nadie explica

El Core Rule Set viene con niveles de paranoia, del 1 al 4. El nivel 1 atrapa lo obvio y rara vez bloquea a un humano. Cada nivel adicional añade reglas más estrictas y más propensas a falsos positivos, hasta que en el nivel 4 un firewall rechazará cosas que una aplicación normal hace todos los días.

El consejo honesto no es apasionante. Empieza en el valor por defecto, vigila el registro durante una semana, y solo sube el nivel si estás protegiendo algo que justifique el coste operativo — y entonces hazlo primero en un entorno de staging. A la mayoría de los sitios les sienta mejor un nivel 1 bien ajustado que un nivel 3 que alguien desactivó silenciosamente después de la tercera queja.

Cómo evaluar la "cobertura del OWASP Top 10" de un proveedor

Cuatro preguntas atraviesan la mayor parte del marketing.

1. ¿Qué conjunto de reglas, y qué versión? "Basado en OWASP" puede significar el Core Rule Set o las reglas propias de un proveedor con nombres con sabor a OWASP. La versión también importa — los conjuntos de reglas se revisan, y ejecutar uno más antiguo es una decisión real, no un detalle. Nosotros ejecutamos el CRS y lo actualizamos de forma deliberada, probándolo contra los patrones de falsos positivos que golpean a nuestros propios clientes, en lugar de seguir el origen automáticamente.

2. ¿Qué veo cuando se bloquea una petición? Si la respuesta es una página de error genérica y un registro que no puedes buscar por regla, el ajuste será a ciegas.

3. ¿Cómo excluyo un campo en una ruta? Si la exclusión más pequeña disponible es "desactivar la familia de reglas para este sitio", el producto te está empujando a apagar la protección.

4. ¿Qué no está cubierto? Un proveedor que responde "el control de acceso y la lógica de negocio son tu código, no nuestras reglas" te está diciendo la verdad. Uno que afirma cobertura total del Top 10 está describiendo una lista de categorías, no una capacidad.