blog

Un atacante malicioso pueden explotar vulnerabilidades de inyección, enviando entradas especialmente diseñadas para causar la aplicación web realice acciones como, exponer datos sensibles de la autenticación (nombres de usuario y contraseñas), o ejecutar comandos del sistema (añadir cuentas falsas de administrador). Los ataques de inyección son las explotaciones más dañinas enfrentadas por las aplicaciones web en la actualidad, por el hecho de impactar a un gran número de usuarios (clientes), además de la humillación pública cuando se exponen los ataques exitosos. Los ataques de inyección son usualmente el resultado de salvaguardas insuficientes implementados para prevenir estos ataques.

Las aplicaciones web están hechas a medida por programadores humanos, los cuales no importando cuan cuidadosos sean, son susceptibles a cometer errores, lo cual introduce vulnerabilidades. Algunos de los tipos de inyección más comunes son:

• Consultas SQL (Structured Query Languaje)
• Consultas LDAP (Lightweight Directory Access Protocol)
• Consultas XML Path Language
• Comandos del sistema operativo

Es importante apoyarse en herramientas como Zed Attack Proxy (ZAP) o Burp Suite, John The Ripper, o SQLMap, para realizar los ataques explotando las vulnerabilidades de inyección. Siendo aún más importante conocer como se explotan manualmente las inyecciones SQL e inyecciones de comandos.

No importando cual vulnerabilidad de inyección se encuentre, y cual explotación se utilice en contra de esta vulnerabilidad, todo se trata y gira sobre enviar entradas maliciosas hacia la aplicación web, para consecuentemente sea procesada. Otro factor a tener en consideración es, los ataques de inyección son realizados mientras se interactúa con la aplicación web, de la misma manera en como lo hacen los usuarios legítimos. Esto significa el tráfico y las peticiones web se verán virtualmente idénticas a otras peticiones no maliciosas.

Fuentes:

https://www.owasp.org/index.php/Top_10-2017_A1-Injection
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
https://portswigger.net/burp
https://www.openwall.com/john/
http://sqlmap.org/

Los escáneres de vulnerabilidades para aplicaciones web tienen algunas claras deficiencias, en lo referente a los tipos de vulnerabilidades capaces de encontrar. Siendo esto muy necesario e importante conocer, antes de seleccionar y utilizar cualquier herramienta. A continuación se presenta una lista de vulnerabilidades en aplicaciones web, las cuales potencialmente podrían no ser detectados por los escáneres automáticos, esto sin importar sean Open Source (Fuente Abierta), gratuitos, o sea un enorme producto maravilloso de miles de dólares.

Contraseñas Débiles: Aunque los “spiders” intentarán hacer “login” hacia la aplicación web con credenciales por defecto, esto es sólo para enviar el formulario y encontrar contenido adicional. En un raro evento, un login por defecto será exitoso, pero el escáner no reconoce la razón como una contraseña débil. Así si una cuenta de administrador es fácil de adivinar, el escáner no proporcionará ninguna indicación de esta vulnerabilidad.

Nombres de Parámetros Significativos: El escáner no es lo suficientemente inteligente para conocer cuales parámetros tienen un significado en la aplicación, y cuales valores diferentes de estos parámetros incluso son significativos para la seguridad y funcionalidad global. Esto es especialmente verdadero si el desarrollador ha utilizado nombres oscuros para los parámetros, como “a”, “c3po”, “skywalker”, “foo”, o utilizó un lenguaje diferente para definir variables.

Inyección SQL Ciega: Debido a esta vulnerabilidad raramente proporciona una respuesta directa de retorno hacia el escáner, en gran parte no se detecta y reporta. Esto es bastante opuesto a la inyección SQL tradicional, el cual proporciona información inmediata hacia el escáner, y de esta manera compararlas con las firmas integradas. Peor aún, algunas veces los escáneres reportarán una inyección SQL Ciega, lo cual termina siendo un falso positivo, generando una gran inversión de tiempo tratando de verificar los hallazgos del escáner.

Control de Acceso Inadecuado: La capacidad de un atacante para eludir los mecanismos para el control de acceso podrían no ser marcados por un escáner web, debido al escáner simplemente no se percata cuando un usuario puede acceder a los recursos de otro usuario (escalado de privilegios horizontales), o cuando un usuario puede acceder a los recursos del administrador (escalado de privilegios verticales). Incluso si la vulnerabilidad está presente, un escalado fuera del control de acceso previsto, se verá únicamente como otro recursos solicitado por el escáner. Esto se debe a los escáneres no pueden hacer decisiones lógicas, y podrían nunca conocer cuales parámetros y valores conducen la funcionalidad de una aplicación web.

XSS de Múltiples Etapas: Casi todas las vulnerabilidades requiriendo múltiples etapas podrían no ser detectadas por un escáner, porque este no tiene la capacidad de completar inteligentemente las etapas. Por ejemplo, un escáner no encontrará una vulnerabilidad de XSS almacenada en la tercera etapa de un procedimiento de cinco etapas, porque no es capaz de exitosamente completar las dos primeras etapas para llegar a la página vulnerable.

Navegación Forzada (Fuerza bruta a archivos y directorios): Esta vulnerabilidad, también conocida como navegación forzada, no será identificada por un escáner, porque involucra solicitar varios recursos similares de manera secuencial, y ser capaz de descifrar cuales son significativos para la aplicación web. Un escáner no los detectará porque no comprende el contexto de la funcionalidad de la aplicación weeb para cada recursos solicitado.

Ataques de Sesión: A falta de vulnerabilidades flagrantes de sesión, como la transmisión de identificadores de sesión a través HTTP inseguro, un escáner no reconocerá un ataque de sesión como fijación de sesión. Todas estos ataques involucran interacción humana, ya sea un atacante o la victima, estando fuera de cualquier escáner automático.

Fallas Lógicas: Debido a la naturaleza personalizada de las aplicaciones web, y la funcionalidad proporcionada, no existen firmas en el escáner para las fallas lógicas. Estas vulnerabilidades son más difíciles de detectar por los programadores, y hackers, porque tratan con la lógica de la aplicación web en lugar de su sintaxis. Un ejemplo fácil es; un escáner no es lo suficientemente inteligente para entender la diferencia entre dos valores de los parámetros indicado el rol de un usuario.

Esta vulnerabilidad nunca será encontrada por un escáner de vulnerabilidades automático, pero podría proporcionar acceso hacia la cuenta de cualquier usuario, esto se haría simplemente cambiando el parámetro con el nombre de usuario pertinente, y enviando sendas solicitudes.

Fuentes:

https://www.owasp.org/index.php/Testing_for_Weak_password_policy_(OTG-A…
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-0…
https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control
https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting…
https://www.owasp.org/index.php/Forced_browsing
https://www.owasp.org/index.php/Testing_for_Session_Management
https://www.owasp.org/index.php/Testing_for_business_logic

Existen tres tipos principales de vulnerabilidades en las aplicaciones web. Sin importar cual sea la herramienta seleccionada para realizar las pruebas, estos escáneres web deberán estar bien equipados para identificar lo siguiente:

Vulnerabilidades basadas en las entradas del lado del servidor. Como la inyección SQL e inyección de comandos del sistema operativo. Este tipo de vulnerabilidades algunas veces es difícil de identificar para los escáneres de vulnerabilidades web, porque la respuesta desde la aplicación web frecuentemente es suprimida en el lado del servidor. En los antiguos días dorados (los 2000), el código en el lado del servidor arrojaba todo tipo de mensajes muy informativos, los cuales podían ser inspeccionados por los escáneres de vulnerabilidades para detectar signos de vulnerabilidades existentes. Un ejemplo clásico es la inyección SQL, donde al ingresar una única comillas simple, podría devolver un mensaje de error desde la aplicación, lo cual era fácilmente reconocible como vulnerable. Como los desarrolladores han mejorado hacia mensajes de error genéricos, la detección de vulnerabilidades de código en el lado del servidor, se ha vuelto más difícil, pero los escáneres aún podrían encontrarlos.

Vulnerabilidades basadas en entradas del lado del cliente. Como Cross-Site Scripting (XSS). Muchos escáneres web pueden identificar este tipo de vulnerabilidades de manera muy confiable, porque el código en el lado del cliente es visible. Cuando se caza por una vulnerabilidad XSS reflejada, el escaner enviará entradas e inmediatamente inspeccionará las respuestas provenientes desde la aplicación web, en busca de la misma entrada siendo reflejada de retorno. Escáneres más refinados utilizarán esta instancia de entrada reflejada, para luego sumergirse en verificaciones más sofisticadas de XSS, y verificar la vulnerabilidad está presente.

Vulnerabilidades las cuales se identifican inspeccionando las peticiones y respuestas. Como las cookies inseguras o transmisión de contraseñas sin encriptar. Estas vulnerabilidades podrían ser utilizadas en ataques contra la aplicación web y el usuario web. Las solicitudes del navegador web y las respuestas desde la aplicación web son completamente visibles para el escaner, de tal manera únicamente se necesita interpretar y comparar los resultados hacia un conjunto conocido de reglas. No es difícil verificar por ejemplo, si los parámetros del nombre de usuario y contraseña son enviados inseguramente sobre HTTP.

Fuentes:

https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools
https://github.com/zaproxy/zap-core-help/wiki/HelpStartConceptsAscan
https://portswigger.net/vulnerability-scanner

Los escáneres para aplicaciones web proporcionan una manera automática de descubrir vulnerabilidades en la aplicación web, similar a lo hecho por herramientas como OpenVAS (Open Vulnerability Assessment System) o Nessus, en lo referente a su capacidad de encontrar malas configuraciones o parches no instalados. La mayoría de escáneres para aplicaciones web, se sitúan entre un navegador web y la aplicación web, como lo hace un proxy web, siendo generalmente parte de un conjunto de herramientas mayor como Zed Attack Proxy o Burp Suite.

Los escáneres web envían entradas especialmente elaboradas hacia la aplicación web, para luego analizar las respuestas por síntomas de vulnerabilidades conocidas. Es común para un escáner web enviar cientos de peticiones hacia un campo de entrada en la aplicación web, para verificar todos los diferentes tipos de vulnerabilidades basados en firmas.

Existen dos escáneres de vulnerabilidades sobre los cuales en primera instancia se sugiere investigar Zed Attack Proxy (ZAP) y Burp Suite. Burp Suite está constituido de tres ediciones, Empresarial y Profesional de pago, y Comunidad de libre uso. Pero esta última edición tiene restricciones, como la incapacidad de utilizar el escaner de vulnerabilidades web. Al momento de escribir el presente texto, es indudable se trata de una muy buena herramienta.

De otro lado se tiene a Zed Attack Proy (ZAP), parte del proyecto OWASP. Es una de las herramientas libres de seguridad más populares a nivel mundial, y es activamente mantenida por cientos de voluntarios a nivel internacional. Esta herramienta puede ayudar a encontrar automáticamente vulnerabilidades de seguridad en las aplicaciones web, mientras se desarrollan y prueban las aplicaciones. También es una gran herramienta para profesionales experimentados en pruebas de penetración, quienes lo utilizan para realizar pruebas manuales. ZAP no tiene ningún tipo de restricción para su utilización.

La decisión de utilizar Zed Attack Proxy o Burp Suite, o ambos, depende de diversos criterios como; funcionalidades, costo, soporte, actualizaciones, conocimientos, entrenamiento, documentación, etc. La principal decisión dependerá de los profesionales quienes utilizarán las herramientas.

Fuentes:

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
https://portswigger.net/burp/

OWASP Zed Attack Proxy (ZAP), es una de las herramientas libres de seguridad más populares a nivel mundial, y es activamente mantenida por cientos de voluntarios a nivel internacional. Esta herramienta puede ayudar a encontrar automáticamente vulnerabilidades de seguridad en las aplicaciones web, mientras se desarrollan y prueban las aplicaciones. También es una gran herramienta para profesionales experimentados en pruebas de penetración, quienes lo utilizan para realizar pruebas manuales. Zed Attack Proy está instalado por defecto en Kali Linux.

Para configurar Zed Attack Proxy, e interceptar todas las peticiones y respuestas HTTP/S, se necesita configurar al navegadora para instruirlo a utilizar ZAP. La configuración depende del navegador web utilizado. Para este caso se utiliza la versión de Firefox incluida en Kali Linux.

En Firefox hacer clic en el icono “Open Menu” o Abrir Menú. Para luego seleccionar la opción “Preferences” o Preferencias.

Hacer clic en “General”, ubicado en el lado izquierdo de Firefox. Luego bajar hasta la sección “Network Proxy” o Proxy de Red. Hacer clic en el botón “Settings...” o Configuraciones…

Activar la opción “Manual proxy configuration” o Configuración manual del proxy. Y en el campo “HTTP Proxy” o Proxy HTTP, escribir 127.0.0.1, localhost, o la dirección IP adecuada. En “Port” o Puerto, escribir el puerto en el cual está atendiendo ZAP, por defecto es en el puerto TCP 8080, aunque esto se puede también cambiar en caso sea pertinente. Se sugiere también activar la opción “Use this proxy server for all protocols” o Utilizar este servidor proxy para todos los protocolos. Igual en caso se requiera , es factible realizar ajustes puntuales a esto. Finalmente hacer clic en el botón “OK”.

Ejecutar Zed Attack Proxy

En Firefox ingresar a la página pertinente. Luego de lo cual Zed Attack Proxy interceptará todas las peticiones y respuestas.

Zed Attack Proxy incluye una gran cantidad de información, incluyendo, documentación, videos, presentaciones, etc. Se sugiero revisar el sitio web del proyecto.

Fuentes:

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
https://github.com/zaproxy/zaproxy/wiki/Introduction

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).

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 navegador web envía peticiones hacia la aplicación web, y la aplicación web envía respuestas de retorno hacia el navegador web. Este ciclo fundamentalmente dirige el uso de Internet. Un proxy permite ver como estos ciclos de peticiones y respuestas realmente funcionan, pues se sitúa entre el navegador web y la aplicación web, controlando el flujo de estas peticiones y respuestas.

Una vez configurado el proxy, se tendrá la capacidad de inspeccionar cada petición y respuesta atravesándolo, e interceptar o cambiar los valores correspondientes a los parámetros utilizados durante el proceso. Esto es una funcionalidad muy útil cuando se trata de explotar una aplicación web.

Otro gran uso de un proxy web, es mantener un historial de ejecución (catalogo), de todas las peticiones y respuestas atravesándolo. Esto no interfiere con el ciclo de petición y respuesta, pero permite el ciclo sea inspeccionado más adelante, durante el escaneo y explotación de las peticiones y respuestas, lo cual es el núcleo de la funcionalidad correspondiente a la aplicación web.

Fuentes:

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
https://en.wikipedia.org/wiki/Proxy_server

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

Cuando se habla sobre datos utilizados como plantillas de mutación, la noción de calidad debe ser discutida. La calidad puede ser medida por la cantidad o porcentaje de la funcionalidad del programa la cual es afectada o utilizada. Mientras los datos son procesados, diferentes partes del código serán afectados. El código afectado puede ser medido con dos métricas: código abarcado e importancia del código.

El código abarcado es una manera fácil de asignar una métrica hacia la calidad de la plantilla, mediante la medición de la cantidad de código la cual se ejecuta mientras se procesan los datos de la plantilla. Esta medida es usualmente un número de bloques base ejecutados o funciones en un programa.

Otra manera para determinar la métrica de la plantilla es medir la importancia del código en lugar de concentrarse únicamente en información cuantitativa, como el número de funciones ejecutadas en lo referente al código abarcado. Una plantilla se dice tiene un alto nivel de importancia, si abarca un conjunto de funciones o bloques básicos, los cuales no son abarcados por cualquier otra plantilla.

Por lo tanto se pueden utilizar dos métricas importantes para puntuar las plantillas, y determinar cual debe ser priorizada cuando se realicen mutaciones:

Medición de cobertura cuantitativa. Basado en el número de funciones o bloques base ejecutados en el software objetivo, mientras los datos de entrada son procesados. En este caso, cuanto mayor sea el número de funciones abarcados, más adecuados son los datos como plantillas de mutación.

Medición de cobertura de unicidad Basado en maximizar el área total de código abarcado para el conjunto mínimo de plantillas. En este escenario el valor de una plantilla específica es medida por cuanto mejora la cobertura del código, relativo a otras muestras. Esto resultará en una plantilla de datos de alta puntuación, la cual abarca un pequeño número de funciones, pero cuyas funciones no son abarcadas por otras plantillas.

Antes de clasificar y seleccionar la importancia de una plantilla, es necesario recolectar tantas muestras como sea posible.

Fuentes:

https://github.com/secfigo/Awesome-Fuzzing
https://www.usenix.org/conference/woot17/workshop-program/presentation/…

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. Estos modelos son usualmente escritos como archivos de configuración, cuyos formatos varían basándose en las herramientas de Fuzzing utilizadas.

Uno de los principales problemas con los Fuzzers de generación es escribir los modelos de datos. Para protocolos simples o estructuras de datos para los cuales existe disponible documentación, este no es un problema principal, pero tales casos son raros y no tan interesantes debido a su simplicidad.

En realidad, las cosas son mucho más complicadas, y la disponibilidad de especificaciones y documentación, aún requiere un esfuerzo significativo para correctamente traducirlo hacia el modelo de Fuzzing. Las cosas incluso se tornan más complicadas cuando las compañías de software no siguen las especificaciones y las modifican ligeramente, o incluso introducen nuevas características no mencionadas en la especificación. En tales casos es necesario personalizar el modelo para el software objetivo, lo cual requiere esfuerzo adicional.

La mayoría de los formatos de archivos y protocolos propietarios no tienen incluso especificaciones públicas, de tal manera se debe realizar ingeniería inversa de los formatos. Todas estas cosas incrementan significativamente la cantidad de tiempo de preparación, lo cual puede hacer muy costoso el utilizar esta perspectiva.

Fuentes:

https://en.wikipedia.org/wiki/Fuzzing
http://community.peachfuzzer.com/GenerationMutationFuzzing.html

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:

Segmentos de mutación. Estas son partes o secciones de los datos a modificar durante el Fuzzing. Puede ser la modificación completa de datos, en el cual todas las partes del archivo son tratados igualmente, y podrían ser modificados durante las pruebas. No todos los segmentos de datos son igualmente importantes, por lo cual es una buen idea saltar el Fuzzing en ciertas partes del archivo. Los formatos de archivos usualmente tienen valores mágicos los cuales distinguen el tipo de archivo. Estos valores mágicos pueden tener varios bytes de longitud y estar localizados al inicio del archivo. El Fuzzing y modificar aleatoriamente estas partes podría únicamente resultar en archivos corruptos, los cuales no podrían ser abiertos o procesados por el software. En estos casos puede ser una buena idea saltar los valores mágicos (u otras partes del archivo los cuales permanecerán inmutables) para reducir el número de casos de pruebas irrelevantes. Esto mejorará en gran medida el número de pruebas válidas e incrementará la velocidad del Fuzzing.

Existen dos tipos comunes de configuraciones para segmentos de mutación:

Completo. Todos los datos son mutados, y ninguna parte del archivo se trata especialmente.

Pros: Este tipo de cobertura asegura la mayoría de vulnerabilidades se abarcan y prueban.
Contras: La cantidad de combinaciones a probar es enorme y da como resultado tiempos de ejecución prolongados. Esto también puede resultar en muchos casos de prueba sean ignorados por el software, por las malformaciones factibles de surgir como resultados de modificar partes especiales o segmentos de datos.

Segmentado.En este caso no todos los segmentos de datos son tratados igual, y algunas partes deberán ser manejados por reglas especiales.

Pros: El proceso de Fuzing puede ser dirigido para especialmente evaluar partes interesantes del objetivo. En este caso la parte “interesante” es subjetiva, y usualmente proviene de un presentimiento o adivinación adecuada.
Contras: La cobertura del Fuzzing es limitada y depende de correctamente identificar las partes interesantes del formato de datos.

Algoritmos de Mutación. Comúnmente, existen tres diferentes maneras de mutar o modificar datos mientras se hace Fuzzing, cada uno diferente en términos de velocidad y lo abarcado:

Aleatorización: Es la manera más fácil y probablemente más común de realizar Fuzzing. Los datos son modificados mediante el reemplazo de porciones con patrones generados aleatoriamente desde un alfabeto predefinido (por ejemplo, caracteres imprimibles). En este caso la mutación está únicamente restringida por el alfabeto generador, y el tamaño deseado de los nuevos datos. Este tipo de mutación es más completo porque tiene el potencial de abarcar todas las posibles combinaciones y encontrar todas las fallas. El problema es la explosión combinatoria previene de probar todas las posibles combinaciones en una cantidad de tiempo razonable, por lo cual esta perspectiva es oportunista y puede tomar mucho tiempo. Es usualmente una buena idea combinar pruebas aleatorias con una perspectiva basada en conjuntos, así la mayoría de tipos más comunes para activar una vulnerabilidad serán realizados antes de iniciar las pruebas aleatorias más extensas.

Tiempo de implementación: Rápido (Rápido / Medio / Lento)
Cobertura de la prueba: Completo (Completo / Parcial / Mínimo)
Tiempo de ejecución: Lento (Veloz / Medio / Lento)

Basado en conjuntos. Este tipo de mutación intenta resolver el problema de un extremadamente gran número de combinaciones en las pruebas de aleatorización, lo cual posee un serio problema en la velocidad de las pruebas. El completo rango de posibles mutaciones presentes en una mutación aleatoria es reducido hacia un conjunto pequeño, el cual usualmente es seleccionado manualmente. Este conjunto representativo se selecciona de tal manera tenga propiedades para activar o probar tipos comunes de vulnerabilidades.

Tiempo de implementación: Medio (Rápido / Medio / Lento)
Cobertura de la prueba: Mínimo / Parcial (Completo / Parcial / Mínimo)
Tiempo de ejecución: Veloz (Veloz / Medio / Lento)

Basado en reglas. Este tipo de mutación es una compensación entre una búsqueda aleatoria completa y un conjunto mínimo seleccionado manualmente. En este caso un conjunto de reglas se escriben para generar patrones y rangos de números a utilizar para las pruebas. Esta perspectiva usualmente extiende el conjunto creado escribiendo reglas más generales, las cuales también podrían explorar patrones similares a aquellos determinados como “interesantes” por la perspectiva basada en conjuntos.

Tiempo de implementación: Medio (Rápido / Medio / Lento)
Cobertura de la prueba: Parcial (Completo / Parcial / Mínimo)
Tiempo de ejecución: Medio (Veloz / Medio / Lento)

Fuentes:

https://en.wikipedia.org/wiki/Fuzzing
https://www.securityevaluators.com/wp-content/uploads/2018/04/analysisf…
http://community.peachfuzzer.com/GenerationMutationFuzzing.html

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.

Una manera de juzgar la complejidad del software es verificar por cualquier recurso disponible para el programa o protocolo el cual será evaluado, como los siguientes:

• Documentación del software
• Especificaciones RFC para los protocolos soportados
• Número de tipos de archivos soportados
• Especificaciones técnicas ara los tipos de archivos soportados
• Tamaño de la aplicación

Fuentes:

https://en.wikipedia.org/wiki/Fuzzing
http://archive.hack.lu/2018/Slides_Fuzzing_Workshop_Hack.lu_v1.0.pdf