Leer código manualmente es un proceso que requiere mucho tiempo. También es propenso a errores, ya que es fácil pasar por alto detalles importantes. Como desarrolladores y evaluadores de penetración, debemos encontrar una manera de automatizar este proceso. SAST es una técnica que puede ayudarnos en esta tarea.
SAST no es una solución milagrosa. Solo se puede utilizar en casos de uso con acceso al código fuente para proyectos de código abierto o pruebas de penetración de caja blanca. Sin embargo, puede ayudarle a encontrar algunas frutas al alcance de la mano y ahorrar tiempo.
Las pruebas de seguridad de aplicaciones estáticas (SAST) son un subconjunto del análisis de código estático que se utiliza para aumentar la seguridad y confiabilidad del código. SAST detecta dependencias antiguas, detección de secretos, errores lógicos que generan vulnerabilidades y más. SAST incluye pruebas que afectan la ciberseguridad de manera secundaria, como la complejidad del código visual, la ambigüedad del código y prácticas no intuitivas que pueden generar vulnerabilidades.
Las herramientas SAST suelen ser comparadores de patrones de expresiones regulares con esteroides que buscan vulnerabilidades conocidas en el código. Por ejemplo, una herramienta SAST podría buscar el uso de eval
, exec
o pickle
en código Python; estas funciones se pueden usar para ejecutar código arbitrario.
Dividiría mi enfoque de SAST en tres categorías:
Detección de vulnerabilidades : utilizo herramientas como Semgrep , Bandit , Nodejsscan para encontrar vectores de ataque en el código. Por lo general, puede encontrar frutos al alcance de la mano, como entradas no desinfectadas, criptografía deficiente o bibliotecas vulnerables. Por cierto, la versión Semgrep PRO tiene más reglas; es gratis si no hay más de 10 desarrolladores en el proyecto.
Detección de secretos : Gitleaks , Trufflehog o Grep pueden ayudarte a encontrar secretos en el código. Esto es importante porque los secretos se pueden utilizar para escalar privilegios o acceder a datos confidenciales. Por lo general, las cadenas de conexión de la base de datos, las claves API o las contraseñas se almacenan en el código.
Configuraciones erróneas : herramientas como Checkov o Trivy pueden ayudarle a encontrar configuraciones erróneas. Las configuraciones erróneas suelen estar en archivos de "infraestructura como código" (IaC), pero también pueden estar en el código mismo. Un ejemplo sería un archivo Docker-Compose mal configurado que expone una base de datos a Internet. Para escanear Dockerfiles, recomiendo una combinación de hadolint y grype
Más información: https://dkb-zh.gitlab-pages.ics.muni.cz/vulnerability-management/web-guides-external/docs/guide_iac_sast/#docker
Las herramientas SAST no son perfectas. Te darán falsos positivos y falsos negativos. **Sin embargo, ahorra mucho tiempo en comparación con la explotación aleatoria de algunas aplicaciones. Utilicé herramientas SAST en mis compromisos y competencias de pruebas de penetración. Me ayudó a comenzar con el código base y me dio algunos consejos sobre dónde buscar vulnerabilidades.
Te recomiendo que empieces con Hack The Box . Esta plataforma ofrece desafíos, como obtener el código fuente y encontrar vulnerabilidades. Luego, explótalos en una máquina real. Esta es una excelente manera de aprender a utilizar las herramientas SAST en la práctica.
O, si es desarrollador, puede utilizar herramientas SAST en su proceso de CI/CD. De esta manera, podrá acostumbrarse a las herramientas y su rendimiento. Al mismo tiempo, mejorarás la seguridad de tu aplicación.
He preparado una lista de guías para ayudarle a comenzar con SAST y la detección de secretos. Estas guías están escritas como parte de mi tesis y son un excelente punto de partida para cualquier persona interesada en las herramientas SAST.
Al detectar secretos, recuerde: no es un secreto si los piratas informáticos lo saben. Incluso los desarrolladores experimentados pueden introducir accidentalmente contraseñas o cadenas de conexión en el control de fuente remoto. Utilizando varias herramientas, esta guía ofrece métodos rápidos y sencillos para mitigar este riesgo.
Esta guía se centra en comprender la detección de secretos mediante enlaces de confirmación previa y canalizaciones de CI/CD. Si bien el código se centra principalmente en GitLab, la última sección también cubrirá GitHub.
Esta guía describe de manera eficiente los pasos para iniciar las pruebas de seguridad de aplicaciones estáticas (SAST) en GitLab. SAST es un proceso que utiliza análisis de código estático para identificar posibles vulnerabilidades.
Esta hoja de referencia presenta herramientas útiles para escanear artefactos de infraestructura como código (IaC) y proporciona ejemplos sobre cómo integrarlos en su proceso de CI/CD.
He creado una herramienta personalizada en Golang que me ayuda a hacer coincidir rápidamente expresiones regulares con bases de código enormes.
Existe un equilibrio infinito entre precisión y varianza.
Suponga que necesita más variación y no le importa realizar más revisiones manuales. En ese caso, puede probar RegFinder , que es como grep
pero más adecuado para la detección de secretos (más rápido en repositorios más grandes, salida clara, ignorando algunas extensiones de archivos). O puedes usar grep directamente. Las más valiosas son las expresiones regulares del repositorio, no la herramienta que utilizará.
grep -n -r your_app/ -Ef regex_dir/general.txt
O
./regfinder.elf -d your_app/ -f regex_dir/general.txt
Es sencillo ampliar los patrones de expresiones regulares existentes. Esta herramienta no es factible para canalizaciones automatizadas. Sin embargo, resulta útil si necesita encontrar un secreto no estándar o en otras evaluaciones, como revisiones de seguridad, donde se espera más trabajo manual.
Comenta si tienes gran experiencia con otras herramientas . Gracias por leer.