Auditoría con SonarQube

Auditoría con SonarQube

SonarQube es una herramienta muy interesante para auditar código súper robusto, con soporte para multitud de lenguajes de programación, que además ofrece un ‘Dashboard’ con mucha información que se pueda utilizar desde clientes, creando un sistema de auditoría continua de código.

Por Fernando Manrique

A continuación, voy a realizar una implantación utilizando un proyecto de código abierto para la administración de la práctica.

El proyecto se llama Open EMR. Es una aplicación de gestión de prácticas médicas y registros de salud electrónicos de código abierto y gratuito. Cuenta con registros de salud electrónicos totalmente integrados, gestión de prácticas, programación, facturación electrónica, internacionalización, soporte gratuito y una gran comunidad detrás.

Auditoría con SonarQube

Analizaremos algunas de las vulnerabilidades. Utilizaremos las recomendaciones a OWASP, CWE así como otras listas que proponga SonarQube.

Acceso a la maquina virtual: owaspbwa
➔ user: root
➔ passwd: owaspbwa

Obtenemos la ip de la máquina virtual:

➔ Ip route: 192.168.1.141

Desde un navegador usamos la ip como url para dirigirnos a la web que se aloja en dicha máquina.

Auditoría con SonarQube

Descargamos sonarqube comunity edition: https://www.sonarqube.org/success-download-community-edition/


Auditoría con SonarQube

En cmd de windows nos vamos al directorio de windows-x86-64 del directorio de Sonarqube:

Auditoría con SonarQube

Montamos el servidor Web Ejecutando StartSonar.bat – obligatorio java 11:

Auditoría con SonarQube

Accedemos al sonar localhost:9000 -(U:admin/P:admin):

Auditoría con SonarQube

Descargamos el proyecto de la carpeta, vamos al código fuente en “veotek”, creamos un proyecto y le marcamos de forma manual, ejemplo veotek030322, elegimos la herramienta de integración continua donde tendríamos nuestro código.
Como este caso lo tenemos en local, lo marcaremos de forma local, se generará un token y damos a continuar, seleccionamos la tecnología php y el sistema windows.
Obtenemos la línea de scanner para poder ejecutar el análisis del proyecto y el mismo, se debe ejecutar dentro de la carpeta del código fuente.

Auditoría con SonarQube

Auditoría con SonarQube

Debemos descargar sonarScanner:

Nota: debemos de copiar la descarga en un lugar concreto que sepamos donde está para poder ejecutarlo sin problemas, pues es necesario decirle donde se encuentra.: ej.- c:\sonar\sonar-scanner46\ bin\sonar-scanner.bat

Sobre la carpeta del proyecto, ejecutamos la siguiente línea anteriormente y empezaría a ejecutarse el análisis del proyecto:

Auditoría con SonarQube

Auditoría con SonarQube

Al finalizar el mismo, nos mostrará un execution successfully y la url donde podremos ver el informe.

Auditoría con SonarQube

Vamos a la Url indicada y vemos el reporte generado:

NOTA: recomendable en el Ide a usar integrar el plugin sonarlint para que mientras generemos código, obtengamos los reportes. Esto nos facilita clean code sobre las vulnerabilidades mientras se escribe el código.

Diferentes tipos de Hostpot:

Auditoría con SonarQube

¿Cuál es el riesgo?:

Auditoría con SonarQube

¿Estás en riesgo?:

Auditoría con SonarQube

¿Cómo se puede solucionar?:

Auditoría con SonarQube

Vulnerabilidades encontradas:

Auditoría con SonarQube

Auditoría con SonarQube

Code:

Auditoría con SonarQube

Algunas de las vulnerabilidades encontradas:

Url owasp: https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

A02:2021 – Fallas criptográficas

Descripción

Lo primero es determinar las necesidades de protección de los datos en tránsito y en reposo. Por ejemplo, las contraseñas, los números de tarjetas de crédito, los registros médicos, …

Ejemplos

  • Escenario 1: una aplicación cifra los números de tarjetas de crédito en una base de datos mediante el cifrado automático de la base de datos. Sin embargo, estos datos se descifran automáticamente cuando se recuperan, lo que permite que una falla de inyección SQL recupere números de tarjetas de crédito en texto claro.
  • Escenario 2: un sitio no usa ni impone TLS para todas las páginas o admite un cifrado débil. Un atacante supervisa el tráfico de la red (por ejemplo, en una red inalámbrica insegura), degrada las conexiones de HTTPS a HTTP, intercepta solicitudes y roba la cookie de sesión del usuario. Luego, el atacante reproduce esta cookie y secuestra la sesión del usuario (autenticado), accediendo o modificando los datos privados del usuario. En lugar de lo anterior, podrían alterar todos los datos transportados, por ejemplo, el destinatario de una transferencia de dinero.
  • Escenario 3: la base de datos de contraseñas utiliza hashes simples o sin sal para almacenar las contraseñas de todos. Una falla en la carga de archivos permite que un atacante recupere la base de datos de contraseñas. Todos los hashes sin sal se pueden exponer con una tabla de arcoíris de hashes precalculados. Los hashes generados por funciones hash simples o rápidas pueden ser descifrados por GPU, incluso si estuvieran salados.

Algunas formas de Prevenir:

  • Clasificar los datos procesados, almacenados o transmitidos por una aplicación. Identifique qué datos son confidenciales de acuerdo con las leyes de privacidad, los requisitos reglamentarios o las necesidades comerciales.
  • No almacene datos confidenciales innecesariamente. Deséchelo lo antes posible o use tokenización compatible con PCI DSS o incluso truncamiento. Los datos que no se retienen, no se pueden robar.
    Asegúrese de cifrar todos los datos confidenciales en reposo.
  • Asegúrese de que se implementen algoritmos, protocolos y claves estándar sólidos y actualizados; utilizar una gestión de claves adecuada.
  • Cifre todos los datos en tránsito con protocolos seguros como TLS con cifrado de confidencialidad directa (FS), priorización de cifrado por parte del servidor y parámetros seguros. Aplique el cifrado mediante directivas como HTTP Strict Transport Security (HSTS).

Url owasp: https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/

A07:2021 – Fallas de identificación y autenticación

Descripción:

La confirmación de la identidad del usuario, la autenticación y la administración de la sesión son fundamentales para protegerse contra los ataques relacionados con la autenticación.

Permite ataques automatizados como el relleno de credenciales, donde el atacante tiene una lista de nombres de usuario y contraseñas válidos.

Permite la fuerza bruta u otros ataques automatizados.

Permite contraseñas predeterminadas, débiles o conocidas, como “Password1” o “admin/admin”.

Algunas formas de Prevenir:

  • Siempre que sea posible, implemente la autenticación multifactor para evitar el relleno automatizado de credenciales, la fuerza bruta y los ataques de reutilización de credenciales robadas.
  • No envíe ni implemente con ninguna credencial predeterminada, especialmente para los usuarios administradores.
  • Implemente comprobaciones de contraseñas débiles, como probar contraseñas nuevas o modificadas en la lista de las 10000 peores contraseñas.

Ejemplos:

  • Escenario 1: el relleno de credenciales, el uso de listas de contraseñas conocidas es un ataque común. Supongamos que una aplicación no implementa la protección contra amenazas automatizadas o el relleno de credenciales. En ese caso, la aplicación se puede utilizar como un oráculo de contraseñas para determinar si las credenciales son válidas.
  • Escenario 2: La mayoría de los ataques de autenticación ocurren debido al uso continuo de contraseñas como único factor. Una vez consideradas, las mejores prácticas, la rotación de contraseñas y los requisitos de complejidad alientan a los usuarios a usar y reutilizar contraseñas débiles. Se recomienda a las organizaciones que detengan estas prácticas según NIST 800-63 y utilicen la autenticación multifactor.
  • Escenario 3: los tiempos de espera de la sesión de la aplicación no están configurados correctamente. Un usuario utiliza una computadora pública para acceder a una aplicación. En lugar de seleccionar “cerrar sesión”, el usuario simplemente cierra la pestaña del navegador y se marcha. Un atacante usa el mismo navegador una hora más tarde y el usuario aún está autenticado.

Conclusión:

Espero que este artículo os haya resultado de interés y os sirva de forma práctica porque mi propósito es ofrecer una visión completa de mi experiencia con SonarQuBe.

La calidad del código es vital pues puede suponer el éxito del proyecto de software o convertirse en auténtico problema.

Es muy importante conocer herramientas tan interesantes como esta.

Y como siempre, I Love Chamaleon, un #camaleondigital de Trentia