En Guía de estudio de CISSP, los autores Eric Conrad, Seth Misenar y Joshua Feldman analizan la seguridad del desarrollo de aplicaciones, incluidos los métodos de prueba de software como fuzzing y pruebas de software combinatorias.
El siguiente extracto proviene del Capítulo 9: Dominio 8: seguridad de desarrollo de aplicaciones (pdf).
Métodos de prueba de software
Existe una variedad de métodos de prueba de software. Además de probar las características y la estabilidad del software, las pruebas se enfocan cada vez más en descubrir errores específicos del programador que podrían conducir a vulnerabilidades que ponen en riesgo el sistema, incluida una verificación de falta de límites.
Las pruebas estáticas prueban el código de forma pasiva: el código no se está ejecutando. Esto incluye tutoriales, verificación de sintaxis y revisiones de código. Las pruebas dinámicas prueban el código mientras lo ejecutan.
Las pruebas de software de caja blanca le dan al probador acceso al código fuente del programa, estructuras de datos, variables, etc. Las pruebas de caja negra no brindan al probador detalles internos: el software se trata como una caja negra que recibe entradas.
Se puede utilizar una Matriz de trazabilidad (a veces denominada Matriz de trazabilidad de requisitos o RTM) para mapear los requisitos de los clientes con el plan de pruebas de software: “rastrea” los “requisitos” y garantiza que se envíen.
Niveles de prueba de software
Por lo general, es útil abordar el desafío de probar el software desde múltiples ángulos, abordando varios niveles de prueba, de menor a mayor. Los niveles de prueba de software de Pruebas unitarias, Pruebas de instalación, Pruebas de integración, Pruebas de regresión y Pruebas de aceptación están diseñados para lograr ese objetivo:
- Pruebas unitarias: pruebas de bajo nivel de componentes de software, como funciones, procedimientos u objetos.
- Prueba de instalación: prueba del software tal como se instala y se abre por primera vez
- Prueba de integración: prueba de varios componentes de software a medida que se combinan en un sistema de trabajo. Se pueden probar subconjuntos, o las pruebas de integración de Big Bang prueban todos los componentes de software integrados
- Prueba de regresión: prueba de software después de actualizaciones, modificaciones o parches
- Pruebas de aceptación: pruebas para garantizar que el software cumpla con los requisitos operativos de los clientes. Cuando esta prueba la realiza directamente el cliente, se denomina Prueba de aceptación del usuario.
Fuzzing
Fuzzing (también llamado fuzz testing) es un tipo de prueba de caja negra que ingresa datos aleatorios con formato incorrecto como entradas en programas de software para determinar si fallarán. Es probable que un programa que se bloquea cuando recibe una entrada mal formada o inesperada sufra un problema de verificación de límites y puede ser vulnerable a un ataque de desbordamiento del búfer.
El fuzzing es típicamente automatizado, presenta repetidamente cadenas de entrada aleatorias como interruptores de línea de comando, variables de entorno y entradas de programa. Cualquier programa que se bloquee o se cuelgue no pasó la prueba de fuzz.
Pruebas de software combinatorias
La prueba combinatoria de software es un método de caja negra que busca identificar y probar todas las combinaciones únicas de entradas de software. Un ejemplo de prueba de software combinatoria es la prueba por pares (también llamada prueba de todos los pares).
NIST da el siguiente ejemplo de prueba por pares. “Supongamos que queremos demostrar que una nueva aplicación de software funciona correctamente en PC que utilizan el sistema operativo Windows o Linux, procesadores Intel o AMD y los protocolos IPv4 o IPv6. Esto es un total de 2 x 2 x 2 = 8 posibilidades, pero como muestra la tabla a continuación, solo se requieren cuatro pruebas para probar cada componente que interactúa con todos los demás componentes al menos una vez. En este método combinatorio más básico, conocido como prueba por pares, al menos una de las cuatro pruebas cubre todos los pares posibles (t = 2) de valores entre los tres parámetros «.
| Ejemplo de prueba por pares de NIST | |||
|
Caso de prueba |
SO |
UPC |
Protocolo |
|
1 |
Ventanas |
Intel |
IPv4 |
|
2 |
Ventanas |
AMD |
IPv6 |
|
3 |
Linux |
Intel |
IPv6 |
|
4 |
Linus |
AMD |
IPv4 |
Descarga el capítulo completo (pdf).
Reimpreso con permiso de Elsevier Inc. Copyright 2011. «Guía de estudio de CISSP» por E. Conrad, S. Misenar y J. Feldman. Para obtener más información sobre este título y libros similares, visite la página del libro en el sitio web del editor.
