Cómo entender las técnicas de pruebas de caja gris

Las pruebas de software permiten descubrir brechas, vulnerabilidades, riesgos y amenazas que podrían aprovechar atacantes maliciosos y comprometer el software. Entre los distintos métodos de pruebas de seguridad de aplicaciones, las pruebas de caja gris —también conocidas como pruebas de caja translúcida— son una de las más populares.

Qué son las pruebas de caja gris

En las pruebas de caja blanca, quienes realizan las pruebas conocen el código fuente y el funcionamiento interno del software. Por lo tanto, pueden probar la aplicación desde la perspectiva de quien la desarrolla y modificar su estructura interna o su código para corregir fallas. En cambio, en las pruebas de caja negra, el usuario o la herramienta no tiene conocimiento previo de la estructura interna de la aplicación. Este método se centra en las capas externas de la aplicación (a las que generalmente tendría acceso un atacante externo). En las pruebas de caja gris, quien realiza las pruebas tiene conocimientos parciales de la aplicación evaluada.

Como las pruebas de caja gris ofrecen un buen equilibrio entre la eficiencia de las pruebas de caja negra y la profundidad de las pruebas de caja blanca, suelen ser el método elegido.

Ejemplo de pruebas de caja gris

Para entender mejor las pruebas de caja gris, considera una aplicación web que muestra una lista de publicaciones. Cuando alguien hace clic en una publicación, se le redirige a una página con más información. Por ejemplo, la URL de una página con los detalles de una publicación podría tener esta estructura: www.example.com/post/title-of-the-post/12345, donde 12345 corresponde al ID único de la publicación en la base de datos.

Con un enfoque de pruebas de caja gris, podrías seguir estos pasos:

• Haz clic en la publicación para comprobar si se abre una página nueva.

• Verifica que el parámetro de ID en la URL de la página coincida con el ID de la publicación obtenida de la base de datos.

• Verifica que los usuarios sin privilegios no puedan manipular los parámetros de la URL para acceder a datos no autorizados de la publicación.

• Verifica que no se haya comprometido la integridad de los datos proporcionados.

En cambio, un enfoque de pruebas de caja negra consistiría en:

• Haz clic en el enlace para comprobar que se abra una página nueva con más información sobre el artículo.

Sin embargo, en este caso, como quien realiza las pruebas no tiene acceso al funcionamiento interno de la aplicación, es imposible saber si se mostró la publicación correcta más allá de lo que el usuario puede inspeccionar desde la interfaz.

La principal diferencia entre las pruebas de caja blanca y de caja negra es la profundidad de las pruebas. Las técnicas de caja blanca, en las que quien realiza las pruebas tiene acceso al código fuente, permiten verificar aspectos más profundos: puedes consultar los datos del código real de la aplicación para validar elementos como la lógica, la integridad de los datos y mucho más.

Las pruebas de caja gris combinan la perspectiva de un atacante con el conocimiento de la aplicación para descubrir vulnerabilidades.

Cada tecnología y framework tiene sus fortalezas y debilidades. Con las pruebas de caja gris, puedes aprovechar este conocimiento para realizar pruebas de penetración en una aplicación y diseñar ataques sofisticados que apunten a esas debilidades. Por ejemplo, si sabes que la aplicación está escrita en Java y usa el framework de registro de Java, puedes buscar vulnerabilidades de Log4J.

Caja gris vs. caja blanca vs. caja negra: métodos de prueba

A continuación, veamos las principales diferencias entre las tres técnicas de prueba: caja blanca, caja negra y caja gris.

Nivel de pruebas

La técnica de pruebas de caja blanca permite que quien realiza las pruebas de seguridad evalúe una aplicación con el mayor nivel de conocimiento sobre ella. En cambio, la técnica de caja negra la evalúa desde el punto de vista de un atacante externo, sin proporcionarle información. Por su parte, las pruebas de caja gris se realizan con conocimientos parciales de la aplicación.

Rol de quien realiza las pruebas

Las pruebas de caja blanca suelen estar a cargo de desarrolladores y profesionales de pruebas que escriben o entienden el código; las pruebas de caja negra pueden estar a cargo de profesionales que desconocen la estructura interna o el código de la aplicación; y las pruebas de caja gris pueden estar a cargo tanto de desarrolladores como de profesionales de seguridad.

Habilidades necesarias

Las pruebas de caja negra no requieren necesariamente conocimientos del lenguaje de programación utilizado y toman menos tiempo. En cambio, las pruebas de caja blanca pueden requerir conocimientos profundos del lenguaje de programación y la tecnología utilizados, y toman más tiempo. Las pruebas de caja gris requieren conocimientos parciales del lenguaje y la tecnología utilizados. Por eso, las pruebas de caja blanca son más difíciles que las de caja gris o caja negra.

Costo

En cuanto al costo, las pruebas de caja negra son las más económicas, pero por lo general revelan menos vulnerabilidades. Las pruebas de caja blanca son las más costosas y suelen descubrir más vulnerabilidades. Las pruebas de caja gris quedan en un punto intermedio, tanto en costo como en cantidad de vulnerabilidades descubiertas.

Tipos de pruebas de caja gris

A continuación, veamos los distintos tipos de pruebas de caja gris.

Pruebas de matriz

Las pruebas de matriz permiten que desarrolladores y profesionales de pruebas determinen qué variables utiliza una aplicación. Esta técnica también ayuda a identificar variables redundantes y sin uso.

Pruebas de regresión

Las pruebas de regresión son un tipo de prueba de desarrollo de software que se realiza después de hacer cambios en el producto para garantizar que el software siga funcionando según lo previsto. El software se actualiza con regularidad; las pruebas de regresión garantizan que estas actualizaciones y cambios no generen problemas en otras partes de la aplicación.

Pruebas de patrones

Esta prueba consiste en examinar la versión anterior del software para identificar patrones que provoquen defectos o fallas. Estos pueden ayudar a detectar y prevenir problemas similares en la nueva versión de tu aplicación.

Pruebas de arreglos ortogonales

Este método estadístico de pruebas de rendimiento ofrece la máxima cobertura de código con la menor cantidad de casos de prueba al evaluar aplicaciones complejas.

Qué evaluar en las pruebas de caja gris

Hay varios aspectos importantes que se deben evaluar en las pruebas de caja gris:

• Fallos de seguridad internos: Busca brechas de seguridad internas en una aplicación. Por ejemplo, puedes probar ciertas acciones restringidas que solo puede realizar una persona que inició sesión y tiene privilegios de empleado o miembro.

• Flujo de entrada: Prueba y comprende cómo fluyen entradas específicas por la aplicación.

• Validación de salida: Detecta y prueba si se devuelve el resultado esperado.

• Ruta del código: Busca rutas de código defectuosas o con una estructura deficiente.

• Bucle condicional: Prueba el comportamiento de un bucle condicional.

• Validación de acceso: Verifica que solo los usuarios con los permisos adecuados puedan realizar una acción. Por ejemplo, puedes probar un endpoint que permita únicamente a los usuarios administradores eliminar artículos del inventario.

Técnicas de pruebas de caja gris

A medida que las herramientas y los procesos de pruebas automatizadas han madurado, el proceso de ejecutar y probar aplicaciones se ha simplificado. Herramientas como SAST, DAST e IAST te permiten mejorar automáticamente la calidad y la integridad del código con poco esfuerzo.

Además de contar con las herramientas adecuadas, para realizar pruebas de caja gris se necesitan conocimientos parciales y acceso al código fuente. Sin acceso al código de la aplicación, solo podrás realizar pruebas de caja negra.

Estos son los pasos para realizar pruebas de caja gris:

1. Selección de entradas: Identifica y elige entradas para los métodos de pruebas de caja blanca y caja negra.

2. Identificación de resultados: Identifica los resultados previstos para las entradas seleccionadas.

3. Identificación de rutas: Determina las rutas principales o todas las rutas clave para la etapa de pruebas. Ten en cuenta las funciones adicionales (subfunciones) de la ruta, ya que forman parte de las funciones principales que se probarán en profundidad.

4. Entrada de subfunciones: Identifica las entradas de las subfunciones elegidas.

5. Salida de subfunciones: Identifica nuevamente los resultados esperados de las subfunciones seleccionadas.

6. Ejecución de casos de prueba: Verifica la precisión de los resultados ejecutando un caso de prueba para las subfunciones.

7. Repetición: Repite los pasos 4 a 6 para las subfunciones y funciones restantes.

Ventajas y desventajas de las pruebas de caja gris

Las pruebas de caja gris son importantes para las pruebas de penetración de aplicaciones, ya que aprovechan las fortalezas de las pruebas de caja negra y caja blanca. A continuación, presentamos sus principales beneficios y desventajas.

Ventajas:

• Ofrecen las ventajas de las pruebas de caja blanca y caja negra, y mejoran la calidad de tu aplicación.

• No es necesario que quienes realizan las pruebas tengan un dominio avanzado de la programación, aunque sí deben conocer el código.

• Mejoran la colaboración entre quienes realizan las pruebas y los desarrolladores.

• Son muy efectivas y no requieren demasiado tiempo.

Desventajas:

• Es posible que quienes realizan las pruebas no tengan acceso a todas las rutas del código.

• Diseñar casos de prueba puede ser complicado.

• No se pueden implementar pruebas de caja blanca completas, ya que quien realiza las pruebas solo conoce una parte limitada de la estructura interna.

Conclusión

Las pruebas de caja gris combinan técnicas de caja blanca, como SAST, y métodos de caja negra, como DAST. Las pruebas de caja negra buscan vulnerabilidades y defectos en el código (como lo haría un atacante externo), mientras que el enfoque de caja blanca analiza el código fuente en busca de vulnerabilidades que podrían aprovecharse.