AUDITORÍA DE SEGURIDAD A NIVEL DE CÓDIGO. PARTE 2

Autor: Alejandro Rueda Romero

En este artículo, se continuará profundizando en las revisiones de código, con respecto lo visto en el anterior, explicando detalladamente los análisis dinámicos de código y, su comparación, con los análisis estáticos. También se verá en qué consisten y cómo realizar las auditorías de caja gris, que consisten en una mezcla entre los análisis estáticos y dinámicos.

Análisis de código dinámico

Por un lado, el DAST (en inglés, Dynamic Application Security Testing) se denomina dinámico porque no tiene ningún acceso al código estático o binario subyacente. Las pruebas se realizan desde fuera hacia dentro. Puede pensar en ello como un hacker que intenta probar las vulnerabilidades de seguridad de su sistema.

Por otro lado y a diferencia del DAST, el SAST (en inglés, Static Application Security Testing) analiza la aplicación en ejecución sin ningún conocimiento de la tecnología utilizada para desarrollar el sistema. Una vez que detecta cualquier vulnerabilidad y riesgo potencial, registra los problemas para los desarrolladores.

El siguiente ejemplo ilustra cómo Gitlab realizó una comparación de las vulnerabilidades entre las ramas de origen y destino. La información se mostrará en cada solicitud de fusión.

Comparación de vulnerabilidades en Gitlab

Detección tardía

El DAST suele realizarse al final del ciclo de vida de desarrollo del sistema. Normalmente, tiene lugar durante la fase de pruebas, justo antes de las pruebas de aceptación del usuario. Sirve como la última puerta de entrada, para asegurar su aplicación, antes de desplegarla a sus usuarios.

La mayoría de las veces, los problemas que se detectan en el DAST no se solucionan inmediatamente, a menos que se consideren críticos. Esto se debe, principalmente, a la falta de tiempo disponible antes de la fase de UAT o de despliegue. Por lo tanto, la mayoría de los problemas se trasladan al siguiente ciclo de desarrollo.

Independiente del idioma

Dado que las pruebas se realizan directamente en las aplicaciones en ejecución, el DAST no está vinculado a ningún lenguaje informático. Es mucho más fácil de escalar y mantener en las pruebas, ya que son independientes de los lenguajes de programación utilizados en el desarrollo del sistema.

Sin embargo, la mayoría de las herramientas DAST sólo son compatibles con determinados tipos de aplicaciones, como las aplicaciones web o los servicios web. Es posible que necesite varias herramientas DAST diferentes si su proyecto consta de aplicaciones web, aplicaciones de escritorio y aplicaciones móviles. Los análisis dinámicos manuales son considerados como los pentesting web (en español, pruebas de penetración en aplicaciones web), mientras también tenemos los análisis dinámicos automáticos utilizando herramientas como Acunetix

La principal herramienta para análisis dinámicos manuales es Burp Suite Pro, pero también se tiene herramientas open source como wfuzz o whatweb.  

Por ejemplo, en la siguiente imagen podemos echar un vistazo al informe DAST elaborado por Acunetix. Destaca el análisis XSS Tokens realizado en una aplicación web. 

Cross Site Scripting detectado con Acunetix

Pruebas de caja gris

El siguiente paso de las pruebas de caja negra son las pruebas de caja gris. Si un analista de caja negra examina un sistema desde una perspectiva externa, un probador de caja gris tiene los niveles de acceso y conocimiento de un usuario, potencialmente con privilegios elevados en un sistema. Los pentesters de caja gris suelen tener cierto conocimiento de los aspectos internos de una red, incluyendo potencialmente la documentación de diseño y arquitectura y una cuenta interna de la red.

El propósito del pentesting de caja gris es proporcionar una evaluación más centrada y eficiente de la seguridad de una red que una evaluación de caja negra. Utilizando la documentación de diseño de una red, los pentesters pueden centrar sus esfuerzos de evaluación en los sistemas con mayor riesgo y valor desde el principio, en lugar de dedicar tiempo a determinar esta información por su cuenta. 

En el caso del software, las pruebas de caja gris es la mezcla de un análisis dinámico y estático. Es decir, mediante la información que obtenemos con el código de la aplicación, tratamos de explotar las vulnerabilidades con el análisis dinámico. Es el testeo de mayor profundidad que se puede realizar, debido a que se comprueban las vulnerabilidades teniendo todos los recursos posibles, y por ello también el que más tiempo se tarda. A nivel web esta clase de testeos se conocen también como IAST (en inglés, Interactive Application Security Testing).

Diferenciación entre análisis de código estáticos y dinámicos

La diferencia clave es que las pruebas estáticas son las que se realizan, incluso antes de que se ejecute el código escrito del software.  Las pruebas dinámicas tienen lugar en un entorno de ejecución, lo que significa que el código se ejecuta con un análisis de seguridad para ver cómo se ejecuta.

Las pruebas estáticas y las pruebas dinámicas son dos tipos comunes de pruebas que uno encuentra como desarrollador de software. Son las herramientas más importantes de las que dispone para asegurar el ciclo de vida del desarrollo de software. Un desarrollador debe utilizar ambas herramientas para determinar si el software desarrollado está listo para salir al mercado.

Las pruebas estáticas se realizan antes de que se ejecute el código escrito ubicado dentro del software. El desarrollador tiene la oportunidad de revisar la codificación con un peine de dientes finos para ver si hay algún error. También les permite ver si los códigos cumplen con las leyes locales, así como si revelan los defectos de diseño que permitan al desarrollador corregirlos antes de la ejecución. En algunos casos, el desarrollador también puede identificar cualquier código malicioso que pueda causar problemas durante la ejecución. Las pruebas estáticas suelen denominarse como verificación: la evaluación del proceso de desarrollo.

Las pruebas dinámicas tienen lugar en un entorno de ejecución, lo que significa que el código se acciona con un análisis de seguridad para ver cómo interactúa. Esto permite al desarrollador determinar si el software se ejecuta correctamente o identificar si reproduce los resultados esperados por el desarrollador. Esto permite a los desarrolladores analizar el comportamiento funcional de un programa informático y controlar su interacción con la memoria del sistema, el funcionamiento de la CPU y el rendimiento general del sistema. Las pruebas dinámicas suelen denominarse como validación: la evaluación de un producto acabado.

¿Qué tipo de análisis es mejor? 

A primera vista, el análisis estático y el análisis dinámico pueden parecer dos jugadores de equipos opuestos. En realidad, son dos compañeros de equipo con puntos fuertes en diferentes áreas. 

Por un lado, el análisis estático echa un vistazo completo al código y puede señalar el lugar exacto donde se encuentran los fallos. También tiene la capacidad de mirar hacia el futuro y alertar de posibles errores que puedan producirse. A parte, los análisis estáticos tienen la capacidad para poder encontrar debilidades que serían complicadas de encontrar con un dinámico.

Por otro lado, puede que el análisis estático no analice todo el código, pero encontrará vulnerabilidades más sofisticadas que el análisis estático pasará por alto. Además, puede utilizarse en un entorno de tiempo de ejecución. Esto significa que el análisis dinámico le dirá los problemas que sí ocurrieron. Y no los que potencialmente podrían tener lugar. 

Un aspecto importante a tener en cuenta es que los análisis estáticos, lo que detectan, son debilidades mientras que los dinámicos son vulnerabilidades. Una debilidad es algo que actualmente puede ser explotable o no, pero si actualmente no lo es puede llegar a convertirse en un futuro, y una vulnerabilidad es un fallo que ya es explotable.

Entonces, ¿cuál debería utilizar?. Como puede imaginar, debería integrar ambos en su flujo de trabajo. De hecho, probablemente ya lo estés haciendo. Cuando lees tu código, estás realizando un análisis estático. ¿Y cuando ejecutas la aplicación para ver si has corregido el error? Eso es análisis dinámico. Esos son ejemplos manuales. Con la abundancia de herramientas disponibles para los desarrolladores hoy en día, puedes agilizar los procesos para hacerlos mucho más eficientes. 

BIBLIOGRAFÍA

  • Ng Wai Foong, J. (2021, 21 noviembre).Static vs Dynamic in Application Security Testing – Towards Data Science. https://towardsdatascience.com/static-vs-dynamic-in-application-security-testing-36687a0c55c5
  • Akihiro Asahara. (2021, 10 noviembre). Dynamic Analysis vs. Static Analysis. Team Insights. http://www.differencebetween.info/difference-between-static-and-dynamic-tA

 

Alejandro Rueda Romero – Ingeniero en Ciberseguridad