Evadiendo un WAF con JSON: cómo funcionan esos ataques y por qué los filtros no los detectan

Un WAF (Web Application Firewall) a menudo se convierte en la primera línea de defensa para las aplicaciones web. Filtra solicitudes, bloquea ataques conocidos y reduce el riesgo de compromiso. Pero en cuanto se trata de JSON, surgen vectores inesperados. La cuestión es que distintos analizadores procesan los mismos datos de manera diferente. En esas diferencias se basan los ataques.

Por qué JSON y dónde está el problema

JSON se creó como un formato sencillo para el intercambio de datos. Pero la especificación deja margen de interpretación, lo que provoca distintas interpretaciones. Por ejemplo, en un objeto pueden aparecer claves idénticas. ¿Cuál elegir: la primera o la última? Un analizador tomará el primer valor, otro el último, y un tercero lanzará un error. Si el WAF comprueba una variante y la aplicación usa otra, el filtro se puede eludir.

• Diferentes bibliotecas interpretan JSON de distintas maneras.
• No existe un estándar estricto para claves duplicadas.
• Los caracteres y las codificaciones pueden procesarse de forma distinta.

Estas divergencias convierten a JSON en una herramienta útil para el atacante. La incompatibilidad entre analizadores puede conducir a fugas de datos e inyección de código.

Ejemplo de ataque mediante claves duplicadas

Un ejemplo sencillo con un campo repetido:

{ "user": "admin", "password": "123", "isAdmin": false, "isAdmin": true }

El WAF comprueba el primer valor de isAdmin y ve false. Pero la aplicación puede tomar el último y ver true. Como resultado, el atacante obtiene privilegios de administrador, mientras que el sistema de protección considera que todo está en orden.

Tácticas como esta fueron estudiadas en detalle por PortSwigger en el artículo «JSON hijacking for the modern web», donde se describen técnicas para robar datos mediante proxies JavaScript en navegadores (por ejemplo, Edge, Chrome)

Manipulaciones con espacios y codificaciones

JSON admite Unicode, y un mismo carácter puede representarse de formas distintas. Por ejemplo:

• u002e en lugar de un punto.
• espacios inusuales (U+00A0 o U+2003).
• mezcla de UTF-8 y UTF-16.

El WAF puede ignorar esas variantes, mientras que la aplicación las acepta como caracteres válidos. Estos métodos se analizaron en investigaciones; por ejemplo, cuando la coma común rompió la verificación de una protección en la nube.

Estructuras anidadas y campos ocultos

Otra táctica consiste en ocultar datos dentro de un objeto anidado. Supongamos que el filtro espera la contraseña en el nivel superior del JSON y el atacante la coloca más abajo:

{ "user": "admin", "data": { "password": "123456" } }

Algunos frameworks despliegan automáticamente esos objetos anidados y los usan como campos normales. Al final, la protección no detecta datos importantes.

JSON Smuggling

Aquí la carga útil se oculta en una cadena que a su vez es JSON. En la primera etapa el filtro verifica solo la envoltura. Pero la aplicación realiza un segundo parseo y obtiene ya un objeto listo:

{ "payload": "{"action":"delete","target":"/users"}" }

Tras un segundo análisis esto se convierte en un comando que la aplicación puede ejecutar. Esta técnica la describió Grimminck en el artículo «JSON Smuggling: A far-fetched intrusion detection evasion technique» ( Medium). Casos detallados de uso de JSON para eludir WAF los han presentado los investigadores de Team82 (Claroty), incluyendo eludir filtros de grandes proveedores ( Claroty, PortSwigger). Un resumen similar aparece en Picus Labs.

Ejemplos de escenarios

1. SQL Injection — la inyección se oculta en un objeto anidado, el WAF no la detecta y la aplicación ejecuta la consulta.
2. XSS — código malicioso codificado con secuencias de escape que se revela solo en el navegador.
3. Elusión de autorización — una clave repetida role permite al sistema tomar el valor que conviene al atacante.

Por qué el WAF es insuficiente

El filtro funciona mediante patrones. Busca construcciones conocidas y las bloquea. Pero JSON ofrece muchas vías de evasión:

• la carga útil se oculta en niveles más profundos de las estructuras anidadas;
• se emplean codificaciones que el filtro no reconoce;
• las claves duplicadas conducen a resultados diferentes.

Además, el WAF no conoce la lógica de negocio específica de la aplicación, por lo que puede pasar por alto acciones que en la práctica violan las normas.

Cómo protegerse

Hay varios pasos que ayudan a reducir los riesgos:

1. Usar el mismo analizador JSON tanto para el filtro como para la aplicación.
2. Prohibir claves duplicadas: activar el modo estricto en el analizador.
3. Validar los datos después del parseo, no solo el JSON original.
4. Definir la estructura mediante JSON Schema y rechazar todo lo sobrante.
5. Registrar anomalías como espacios exóticos o repeticiones de campos.

Herramientas para pruebas

Se puede comprobar la aplicación contra estas vulnerabilidades con:

• Burp Suite — herramienta para interceptar y modificar solicitudes JSON.
• Arjun — ayuda a buscar parámetros ocultos.
• OWASP Testing Guide — guía práctica para pruebas de seguridad.

Conclusión

Eludir un WAF mediante JSON se basa en los detalles: distintas interpretaciones de duplicados, espacios exóticos, estructuras anidadas. Todo ello genera discrepancias entre lo que el filtro "ve" y cómo la aplicación procesa los datos. Eliminar por completo el riesgo es difícil, pero la validación estricta, analizadores uniformes y la supervisión reducen significativamente la probabilidad de un ataque exitoso. Lo principal es no confiar únicamente en el WAF, sino construir una defensa en capas.