Parece como si existiese un mantra aceptado universalmente en el Hacking Web, el cual versa sobre uno de los primeros elementos en la lista de tareas a realizar, lo cual implica instalar y configurar un proxy para ejecutarlo al unísono con un navegador web. De hecho esto es muy importante, pero lo más importante es entender las razones por las cuales se debe utilizar un proxy a través del cual el navegador interactúe con la aplicación web.Para empezar se debe definir las acciones realizadas millones de veces al día por el navegador web (cliente) y la aplicación web (servidor).

El éxito de los Fuzzers de mutación depende de dos factores:

• Los datos a utilizar como plantillas y mutados
• Los algoritmos utilizados para realizar la mutación

Los Fuzzers de generación también son denominados como pruebas basados en gramática o de caja blanca. Esta perspectiva se basa sobre la premisa de las pruebas eficientes requieren entender el funcionamiento interno del objetivo siendo evaluado. Los Fuzzers de generación no necesitan muestras de entradas válidas de datos, o capturas de protocolos como los basados en mutación. Estos son capaces de generar casos de prueba basados en modelos de datos describiendo la estructura de un dato o protocolo.

Los fuzzers basados en mutación, también denominados como fuzzers “tontos”, son la variante más simple y cercana hacia la idea original de aleatorizar los datos de entrada. Este nombre proviene de cambiar (mutar) los datos de entrada, usualmente hecho de una manera aleatoria. Los datos mutados son luego utilizados como entrada para el software en evaluación, con el propósito de intentar o generar una caída en el software.

Los fuzzers de mutación usualmente tienen dos parámetros los cuales pueden se ajustados:

na manera común de juzgar el potencial “Fuzzing” del software es determinar su complejidad. Por ejemplo, un servio Echo es menos complejo y potencialmente factible de Fuzzing, comparado con un servicio HTTP. El protocolo HTTP es en magnitud más complejo, lo cual también implica más código y funcionalidad. Esta complejidad usualmente introduce áreas grises, los cuales son más difíciles de comprender para los ingenieros, en cuyo caso las vulnerabilidades de seguridad pueden ser pasadas por alto.

La automatización para el proceso de pruebas puede ser muy simple o muy duro, dependiendo esto de la aplicación a evaluar. Algunas aplicaciones proporcionan diversos mecanismos, como funciones API exportadas, y capacidades de “scripting”, lo cual facilita la automatización. En casos donde tales capacidades no están disponibles, es posible utilizar herramientas dedicadas y especializadas en automatización de software. En diferentes escenarios, las herramientas específicas para automatización pueden simplificar el proceso de “Fuzzing”, haciéndolo más fácil de realizar.

Una distinción importante entre los objetivos de evaluación, es la capacidad en lo referente a su interfaz, lo cual dicta la facilidad de automatización para el proceso de Fuzzing. Las interfaces simples, como pasar comandos sobre una línea de comandos, son más fáciles de utilizar y automatizar, comparado con aplicaciones las cuales únicamente aceptan comandos desde su interfaz gráfica de usuario.

El primer paso relacionado con un proyecto para realizar un “Fuzzing”, implica decidir cual será el objetivo de evaluación. En aquellos escenarios donde el objetivo puede ser elegido de manera arbitraria, es una buena idea el tratar de maximizar las probabilidades de encontrar una funcionalidad en donde sea factible realizar el procedimiento de “Fuzzing”.

Algo heurístico puede ser utilizado para realizar la evaluación de los objetivos basados en función de potencial “Fuzzing”. A continuación se detalla una lista de algunos temas heurísticos interesantes.

Una de las maneras más rápidas de entrar en la investigación de vulnerabilidades, es a través de las pruebas de software. Las pruebas tradicionales de software de tipo caja negra, son interesantes desde la perspectiva de investigación de vulnerabilidades, porque no requieren una comprensión de los mecanismos internos del software. El único requerimiento para empezar a buscar por vulnerabilidades, es conocer cuales interfaces permiten la interacción con el software, y generar los datos pasados a través de estas interfaces.

Para auditar automáticamente un binario por potenciales vulnerabilidades, cualquier herramienta debe primero comprender el formato del archivo ejecutable utilizado por el binario, ser capaz de interpretar las instrucciones en lenguaje máquina contenidas dentro del binario, y finalmente determinar si el binario realiza algunas acciones probablemente explotables. Tales herramientas son mucho más especializadas comparadas con las herramientas para auditar el código fuente.