¿Qué es la prueba fuzzing?

La prueba fuzz, o fuzzing de aplicaciones, es una técnica de prueba de software que permite a los equipos descubrir vulnerabilidades de seguridad o errores en el código fuente de las aplicaciones de software. A diferencia de las metodologías tradicionales de pruebas de software (SAST, DAST o IAST), el fuzzing consiste esencialmente en «hacer ping» al código con entradas aleatorias con el objetivo de hacer que falle e identificar así fallas que de otro modo no serían evidentes. Esas fallas de código (o problemas con la lógica de negocio) representan áreas que potencialmente están en alto riesgo de amenazas de seguridad.

Cuando se encuentra una falla o vulnerabilidad, se puede utilizar un fuzzer (una herramienta que identifica las posibles causas del fallo) para localizar vulnerabilidades específicas en el código fuente. Los fuzzers son más efectivos para descubrir vulnerabilidades que pueden ser explotadas por ataques como la inyección de SQL y las secuencias de comandos en sitios cruzados, donde los hackers deshabilitan la seguridad para robar información o derribar un sistema. Los fuzzers son menos efectivos para identificar vulnerabilidades que no están relacionadas con fallas del sistema, como spyware o troyanos.

Los partidarios de las pruebas fuzzing las elogian por ser totalmente automatizadas y capaces de encontrar puntos débiles ocultos, mientras que sus detractores se quejan de que pueden ser difíciles de configurar y propensas a ofrecer resultados poco fiables.

Las pruebas fuzzing también destacan por otro aspecto: existe una historia sobre cómo se descubrió el concepto. En 1988, el profesor Barton Miller de la Universidad de Wisconsin-Madison estaba tratando de acceder a código de forma remota utilizando un sistema de acceso telefónico, pero la interferencia de una tormenta eléctrica hacía que el programa se bloqueara continuamente. La idea de que el código no podía tolerar el «ruido» externo se convirtió en la inspiración para el trabajo de Miller y su estudiante. Descubrieron que los programas Unix, Mac y Windows se bloqueaban sistemáticamente cuando recibían entradas aleatorias inesperadas. Miller es uno de los autores de Fuzzing for Software Security Testing and Quality Assurance.

Hay dos tipos principales de fuzzing: guiado por cobertura y basado en comportamiento.

El fuzzing guiado por cobertura se centra en el código fuente mientras la aplicación se está ejecutando, sondeándolo con entradas aleatorias en un esfuerzo por descubrir errores. Constantemente se generan nuevas pruebas y el objetivo es hacer que la aplicación se bloquee. Un bloqueo significa un problema potencial, y los datos del proceso de fuzzing guiado por cobertura permitirán que un probador reproduzca el bloqueo, lo que es útil cuando se trata de identificar el código en riesgo.

El fuzzing basado comportamiento funciona de manera diferente. Mediante el uso de especificaciones para mostrar cómo debería funcionar una aplicación, utiliza entradas aleatorias para juzgar cómo realmente funciona la aplicación; la diferencia entre lo esperado y la realidad, por lo general, es donde se pueden encontrar errores u otros riesgos potenciales de seguridad.

¿Por qué son importantes las pruebas fuzzing para DevSecOps? Debido a la naturaleza aleatoria de las pruebas fuzzing, los expertos dicen que es la metodología con más probabilidades de encontrar errores que otras pruebas no detectan. También se considera una metodología de pruebas de muy bajo esfuerzo, o lo que a algunos les gusta llamar «configurarlo y olvidarlo». Una vez que se crea el arnés de pruebas, las pruebas fuzzing se automatizan por completo y se ejecutarán indefinidamente. Se puede escalar fácilmente agregando más máquinas y es una buena opción para pruebas de regresión. El fuzzing también acelera el proceso de desarrollo al maximizar la cobertura del código (la cantidad de código que ha sido ejecutado por el fuzzer) sin introducir falsos positivos. Una mayor cobertura de código significa pruebas más exhaustivas.

Las pruebas fuzzing también son ideales para trabajar junto a un equipo de pruebas manuales, ya que ambos conjuntos de entradas educarán al otro.

Dos desafíos principales a los que se enfrentan los profesionales que buscan implementar pruebas fuzzing: la configuración y el análisis de datos. Las pruebas fuzzing no son necesariamente fáciles de configurar; requieren «arneses» de pruebas complejos que pueden ser aún más difíciles de crear si las pruebas fuzzing no se encuentran realmente dentro de una cadena de herramientas existente. Además, las pruebas fuzzing pueden generar muchos datos, incluidos potencialmente falsos positivos. Por lo tanto, es fundamental asegurarse de que un equipo de pruebas esté preparado para hacer frente a la avalancha de información.

Además, aunque menos fáciles de documentar, las actitudes negativas hacia la naturaleza «vaga» de las pruebas fuzzing persisten en la comunidad de control de calidad.