# Fuzzing: las claves del método de prueba automatizado

El *fuzzing*, también conocido como *fuzz testing*, es un método automatizado ideal para descubrir puntos débiles en el *software*. Descubre en este artículo de qué trata este procedimiento y qué ventajas y desventajas presenta este método, así como las diferentes herramientas de *fuzzing* que existen.

## ¿Qué es el fuzzing?

El *fuzzing* o *fuzz testing* es un método desarrollado por el científico Barton Miller para poner a prueba de una forma sistemática los puntos débiles de los programas. En este método no se intenta interpretar el código fuente del programa; de hecho, el *software* se considera una **caja negra** y su contenido se considera dado. Se accede a todas las interfaces de la introducción de datos de forma automatizada y **se alimentan con datos aleatorios**. Este proceso puede durar, en función del tamaño del proyecto que estamos inspeccionando, horas e incluso días.

El objetivo del *fuzz testing* es determinar si se dan las reacciones necesarias en el programa para todas las variantes posibles de entrada. Las **entradas que no tengan sentido o que sean erróneas** deberían ser detectadas en la mayor medida posible por las **rutinas de solución de errores**. Si estas rutinas no están disponibles para determinadas entradas, o si no funcionan correctamente, puede producirse una caída del programa. El procedimiento técnico de comprobar todas las eventualidades del programa forma parte integral de los entornos de desarrollo desde hace ya tiempo en el campo del desarrollo web. Por ejemplo, muchas aplicaciones web se comprueban desde hace ya años mediante *[cross browser testing](https://www.ionos.es/digitalguide/hosting/cuestiones-tecnicas/un-vistazo-al-cross-browser-testing/ "Un vistazo al Cross Browser Testing")* para verificar su funcionalidad en distintos clientes web y versiones de navegadores.

## Tipos de fuzzing

A grandes rasgos, se puede distinguir entre las siguientes tres variantes de *fuzzing*:

### De aplicaciones

Mediante este enfoque de *fuzz testing*, se evalúan funciones como los **botones** y los **campos de introducción** de programas gráficos u opciones de programas basados en línea de comandos. Para ello, el objetivo es acceder a funciones con una frecuencia poco natural o rápida o se rellenan los campos de introducción con contenidos demasiado grandes.

### De protocolos

Para el intercambio de datos, se utilizan protocolos, como el protocolo de transferencia de hipertexto (HTTP) de la web. Los datos transferidos deben estar en un formato determinado. El *fuzzing* de protocolos sirve para comprobar el comportamiento en el caso de los envíos de **contenidos con un formato incorrecto**. Para ello, es especialmente importante que no se interprete de forma accidental el contenido transferido como comandos y que luego se ejecuten en un servidor.

### De formatos de archivo

Las herramientas de *fuzzing* que siguen este enfoque generan archivos defectuosos para que los procesen los programas que se van a examinar. Los archivos tienen normalmente un **formato normalizado**, como, por ejemplo, *.jpg* en el caso de los archivos de imagen, para que puedan ser intercambiados entre distintas aplicaciones. Si el archivo abierto no se corresponde con el formato esperado, puede ocasionar problemas. En una versión avanzada, también se pueden examinar funciones implementadas, como procedimientos de compresión para archivos de vídeo.

## ¿Cómo funciona el fuzzing en detalle?

Resulta muy laborioso realizar el seguimiento del modo de funcionamiento de un software. Normalmente consta de varios miles de líneas de código fuente escritas en algún lenguaje de programación. Las ramificaciones y las funciones integradas hacen que sea demasiado confuso. Además, después de la compilación, el código fuente se debe restablecer (descompilar), lo que no siempre es posible.

Por ese motivo, el *fuzzing* adopta otro enfoque: genera todos los datos aleatorios imaginables de un tipo específico. De esta forma, **se deberían cubrir la mayor cantidad de variantes de entrada posible**. Para ello, el *fuzzing* constituye la interfaz para la introducción automatizada. Esto puede realizarse a diferentes niveles. En el caso del *fuzzing* de aplicaciones, por ejemplo, se imitan distintos tipos de datos y se transmiten a un programa. También se pueden probar las posibles longitudes y los formatos de datos de las introducciones. En el *fuzzing* de protocolos, se utilizan paquetes de datos de generación propia. Otra posibilidad sería la de interceptar contenidos, manipularlos y volverlos a enviar. El *fuzzing* de formatos de archivo funciona con archivos de prueba generados de forma aleatoria. Algunos de los factores que se someten a prueba son el tamaño, la estructura o los marcadores establecidos (*flags*).

## Ámbito de aplicación del fuzz testing

El ámbito de aplicación principal del *fuzzing* es el **control de calidad** en el desarrollo de *software*. Gracias al alto grado de automatización, es posible comprobar *software* de forma periódica en un **entorno de prueba preparado**. Este entorno se puede integrar en el caso de un [desarrollo ágil de *software*](https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/agile-development/ "Agile development") en procesos ya disponibles. Sin embargo, también se puede probar *software* que ya haya sido publicado en el marco de una **auditoría de seguridad**, como, por ejemplo, para comprobar que cumple según qué fines relacionados con la seguridad.

Obviamente, el *fuzzing* puede ayudar a **detectar *exploits***, sin embargo, solo se pueden encontrar indicios sobre errores en las funciones del programa, ya que las herramientas de *fuzzing* no tienen acceso a las estructuras internas de los programas que inspeccionan.

## Ventajas e inconvenientes del fuzzing en forma de tabla

<table>
  <thead>
    <tr>
      <th>Ventajas</th>
      <th>Inconvenientes</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Posibilidad de garantizar un estándar de calidad uniforme mediante pruebas preparadas</td>
      <td>Manejo parcialmente complicado del software</td>
    </tr>
    <tr>
      <td>Refuerzo de la estabilidad del software</td>
      <td>Mayor esfuerzo de trabajo</td>
    </tr>
    <tr>
      <td>Mejora de la seguridad</td>
      <td>No se pueden limitar las causas a la hora de determinar los errores</td>
    </tr>
    <tr>
      <td>Disponibilidad de herramientas consolidadas y gratuitas</td>
      <td>Posibilidad de uso indebido por parte de desarrolladores de programas maliciosos</td>
    </tr>
  </tbody>
</table>

## Vista general de las mejores herramientas de fuzzing

Existen en el mercado una gran cantidad de herramientas de *fuzzing*, tanto gratuitas como de pago, con distintas gamas de funciones. Aquí te ofrecemos un resumen:

- **American Fuzz Lop**. Puede descompilar por sí misma el código fuente y después probarlo; por este motivo, el programa también se incluye en la categoría de “***fuzzer* de caja gris**”. Si el código fuente no está disponible, genera una emulación mediante QEMU (abreviatura de Quick Emulator).
- **Fuzzino**. Ofrece una biblioteca para la generación de datos de entrada con la que se pueden probar aplicaciones (orientadas a los protocolos).
- **LibFuzzer**. Biblioteca que forma parte de la infraestructura del compilador LLVM.
- **ClusterFuzz**. Entorno de pruebas desarrollado en su momento por Google para probar el **navegador Chrome**.
- **Sulley**. Ofrece una compilación de herramientas en el lenguaje de programación Python; es especialmente apto para casos de prueba sencillos, como la generación de datos aleatorios.
- **Peach**. Solución ampliamente automatizada para el *fuzz testing* de *hardware* y *software*.
- **Powerfuzzer**. Ofrece distintos escenarios de ataques, como inyecciones SQL; se maneja mediante una interfaz de usuario gráfica basada en la web.

<table>
  <thead>
    <tr>
      <th>Herramienta de fuzz testing</th>
      <th>Desarrollador</th>
      <th>Licencia</th>
      <th>Categoría</th>
      <th>Particularidades</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>American Fuzz Lop (AFL)</td>
      <td>Michael Zalewski</td>
      <td>Código abierto</td>
      <td>Aplicación</td>
      <td>Uso con caja gris</td>
    </tr>
    <tr>
      <td>Fuzzino</td>
      <td>Fraunhofer Institut</td>
      <td>Código abierto</td>
      <td>Protocolo</td>
      <td>Apta para casos especiales</td>
    </tr>
    <tr>
      <td>LibFuzzer</td>
      <td>LLVM Team</td>
      <td>Código abierto</td>
      <td>Aplicación</td>
      <td>Integrada en compiladores</td>
    </tr>
    <tr>
      <td>ClusterFuzz</td>
      <td>Google</td>
      <td>Código abierto</td>
      <td>Aplicación</td>
      <td>Integra herramientas como AFL</td>
    </tr>
    <tr>
      <td>Sulley</td>
      <td>OpenRCE</td>
      <td>Código abierto</td>
      <td>Protocolo</td>
      <td>Archivo, fácil de integrar</td>
    </tr>
    <tr>
      <td>Peach</td>
      <td>Peachtech</td>
      <td>Comercial</td>
      <td>Aplicación</td>
      <td>Automatización potente</td>
    </tr>
    <tr>
      <td>Powerfuzzer</td>
      <td>Marcin Kozlowski</td>
      <td>Código abierto</td>
      <td>Aplicación</td>
      <td>Integrada en KALI Linux</td>
    </tr>
  </tbody>
</table>

## Alternativas posibles al fuzz testing

En función del fin de la aplicación, existen alternativas de *fuzz testing* que siguen otros enfoques y con las que se consiguen otros resultados. A continuación, hemos resumido brevemente las más importantes para ti.

### Ingeniería inversa

Para los investigadores de seguridad, [**la ingeniería inversa**](https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/ingenieria-inversa-de-software/) es una de las herramientas estándar. Con ella, se busca la comprobación después de la descompilación (traducción al lenguaje de programación original) o después del desensamblaje (traducción al lenguaje cercano a la máquina del ensamblador). Se trata de un proceso muy laborioso y muy propenso a errores. En caso de éxito, se pueden determinar todos los detalles de la funcionalidad del programa.

### Depuración

Por depuración, o ***debugging***, se entiende el proceso de búsqueda de errores en el marco del desarrollo de *software*. Los programas se ejecutan de forma temporal antes de su finalización en el entorno de desarrollo. El desarrollador puede establecer puntos de interrupción (*breakpoints*) en los que el programa se detiene. Ahí, puede leer el contenido de las variables utilizadas y comprobar que sean correctas. La depuración también se puede llevar a cabo en el marco de la ingeniería inversa.

### Pruebas unitarias

Los programas complejos se suelen generar de forma modular. En estos casos, una práctica consolidada es la comprobación de componentes individuales ya en el marco de las denominadas [pruebas unitarias](https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/el-papel-del-unit-test-en-el-desarrollo-de-software/) en los correspondientes entornos de prueba.

## En resumen:

Los errores y los fallos de seguridad en el *software* vienen acompañados la mayor parte de las veces de una **pérdida de prestigio y de confianza** en los desarrolladores. La carencia absoluta de errores es una utopía, algo que deberían saber también la mayoría de los usuarios de los programas. Sin embargo, el *fuzzing* es una potente solución con la que cuenta el desarrollador para encontrar errores antes de que otros lo hagan. En cualquier caso, el método proporciona más **estabilidad y seguridad** en el software. Un buen motivo para integrar el *fuzzing* en los controles de calidad.


This is a markdown version of: [https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/que-es-el-fuzzing/](https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/que-es-el-fuzzing/) for AI/LLM consumption.