Evasión de WAF mediante JSON: cómo funcionan los ataques y por qué los filtros no dan abasto

el WAF (firewall de aplicaciones web) 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 cuando se trata de JSON surgen vías inesperadas. Todo se debe a que distintos analizadores procesan los mismos datos de manera diferente. Sobre esa diferencia se construyen 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, y eso implica 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, un tercero dará error. Si el WAF comprueba una versión y la aplicación utiliza otra, se puede eludir el filtrado.

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

Estas discrepancias convierten a JSON en una herramienta práctica para un atacante. Incompatibilidad entre analizadores puede provocar 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 verifica el primer valor 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 defensa considera que todo está en orden.

Técnicas como esta se estudian con detalle en PortSwigger en el artículo JSON hijacking for the modern web, donde se describen técnicas de robo de datos mediante proxies de 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 aceptará como caracteres válidos. Esos métodos de elusión se han analizado, por ejemplo, cuando una coma común rompió la comprobación de una protección en la nube.

Estructuras anidadas y campos ocultos

Otra técnica 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 expanden automáticamente esos objetos 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 en sí misma es JSON. En la primera fase el filtro solo revisa la envoltura. Pero la aplicación realiza un segundo parseo y obtiene ya un objeto:

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

Tras el segundo análisis eso 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 sobre el uso de JSON para evadir WAF presentan los investigadores de Team82 (Claroty), incluyendo eludir filtros de grandes proveedores ( Claroty, PortSwigger). Un análisis similar está en Picus Labs.

Ejemplos de escenarios

1. Inyección SQL — la inyección está oculta en un objeto anidado, el WAF no la ve y la aplicación ejecuta la consulta.
2. XSS — el código malicioso se codifica con secuencias de escape y solo se revela en el navegador.
3. Evasión de autorización — una clave repetida role permite al sistema tomar el valor que interesa al atacante.

Por qué el WAF resulta insuficiente

El filtro funciona mediante patrones. Busca construcciones conocidas y las bloquea. Pero JSON ofrece espacio para eludirlo:

• la carga útil se oculta en estructuras anidadas;
• se usan codificaciones que el filtro no reconoce;
• las claves duplicadas conducen a resultados distintos.

Además, el WAF no conoce la lógica de negocio concreta de la aplicación, por lo que puede pasar por alto acciones que en realidad violan las reglas.

Cómo protegerse

Hay varios pasos que ayudan a reducir los riesgos:

1. Usar el mismo analizador JSON para el filtro y 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 en busca de 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 «ve» el filtro y cómo procesa la aplicación los datos. Eliminar por completo el riesgo es difícil, pero una validación estricta, analizadores uniformes y monitorización reducen notablemente la probabilidad de un ataque exitoso. Lo principal es no confiar solo en el WAF, sino construir una protección en varias capas.