El fuzzing del lado del cliente es una técnica de prueba que introduce datos aleatorios, malformados o inesperados en las aplicaciones basadas en el navegador para identificar vulnerabilidades de seguridad y errores. Ayuda a descubrir problemas en el manejo de entradas, la manipulación del DOM y la ejecución de JavaScript. Las herramientas de fuzzing modernas suelen combinar la generación de entradas aleatorias con algoritmos guiados por la cobertura para maximizar la eficacia de las pruebas.
El fuzzing es una técnica de prueba automatizada que alimenta a un programa con grandes volúmenes de entradas aleatorias, malformadas o deliberadamente inesperadas para ver qué se rompe. Aplicado al lado del cliente, apunta al navegador y a las aplicaciones basadas en el navegador: los analizadores de HTML y CSS, el motor de JavaScript, las APIs del DOM, los decodificadores de imágenes y fuentes, y el código de manejo de entradas de las aplicaciones web. Un fuzzer genera o muta casos de prueba, los ejecuta y vigila fallos, cuelgues, errores de memoria o fallos de aserción que delatan un error. Los fuzzers modernos se guían por cobertura: instrumentan el código y favorecen las entradas que alcanzan nuevas rutas de ejecución, explorando de forma constante más partes del programa de lo que lograría una prueba aleatoria a ciegas.
El fuzzing es una de las formas más productivas de encontrar errores graves antes que los atacantes. Los proveedores de navegadores ejecutan fuzzing continuo a gran escala para descubrir fallos de corrupción de memoria en motores y analizadores, y las mismas técnicas son las que atacantes e investigadores usan para descubrir días cero explotables. Para quienes desarrollan aplicaciones web, hacer fuzzing sobre los manejadores de entrada y los analizadores del lado del cliente saca a la luz casos límite, como datos malformados que disparan un XSS basado en el DOM o provocan fallos, que las pruebas basadas en ejemplos pasan por alto. Como explora entradas que una persona nunca pensaría en escribir, el fuzzing encuentra defectos una y otra vez en código maduro y bien revisado, por lo que es una parte estándar del desarrollo seguro y de la investigación de vulnerabilidades.
Trata el fuzzing como parte de un ciclo de vida de desarrollo seguro, no como algo puntual. Elige herramientas guiadas por cobertura, dales un buen corpus de entradas semilla y un objetivo que falle de forma ruidosa (aserciones más saneadores como ASan para código nativo), y ejecútalas de forma continua para que el código nuevo se siga ejercitando. Combina el fuzzing con saneadores para atrapar errores de memoria silenciosos, y clasifica y corrige cada fallo reproducible, ya que un fallo suele señalar una condición explotable. Para las aplicaciones web, haz fuzzing sobre cualquier código que analice entradas no confiables y acompáñalo con análisis estático y revisión de código. El fuzzing complementa, pero no reemplaza, la vigilancia de lo que el código de terceros realmente hace en producción.
Ambos usan la misma técnica. Quienes defienden hacen fuzzing sobre su propio software para encontrar y corregir errores antes del lanzamiento, mientras que atacantes e investigadores hacen fuzzing sobre software ampliamente utilizado para descubrir vulnerabilidades que puedan explotar o reportar. El método es neutral; el resultado depende de quién lo ejecute y de qué haga con los fallos que encuentre.
Es un fuzzing que instrumenta el objetivo para medir qué rutas de código alcanza cada entrada, y luego prioriza y muta las entradas que desbloquean nuevas rutas. Este bucle de retroalimentación explora mucho más del programa que la entrada aleatoria por sí sola, encontrando errores más profundos con mayor rapidez. AFL y libFuzzer son ejemplos muy conocidos.
We answer client-side security questions every day. Bring yours.