Skip to main content

Reporte Análisis de Seguridad #Sprint 3

Logo FisioFind

REPORTE ANÁLISIS DE SEGURIDAD S3

ÍNDICE

Ficha del documento

  • Nombre del Proyecto: FISIO FIND

  • Número de Grupo: Grupo 6

  • Entregable: #SPRINT 3

  • Miembros del grupo: Alberto Carmona Sicre, Antonio Macías Ferrera, Benjamín Ignacio Maureira Flores, Francisco Capote García, Daniel Alors Romero, Daniel Fernández Caballero, Daniel Ruiz López, Daniel Tortorici Bartús, Daniel Vela Camacho, Delfín Santana Rubio, Guadalupe Ridruejo Pineda, Julen Redondo Pacheco, Miguel Encina Martínez, Francisco Mateos Villarejo, Pablo Fernández Pérez, Ramón Gavira Sánchez, Rafael Pulido Cifuentes.

  • Contribuidores: Delfín Santana Rubio (autor), Alberto Carmona Sicre (revisor)

  • Fecha de Creación: 09/04/2025

  • Versión: v1.1

Histórico de Modificaciones

FechaVersiónRealizada porDescripción de los cambios
09/04/2025v1.0Delfín Santana RubioPrimera versión del documento
09/04/2025v1.1Alberto Carmona SicreRevisión y corrección del contenido

1. INTRODUCCIÓN

El presente informe tiene como objetivo mostrar los resultados de utilizar una herramienta automática de análisis de seguridad. Este análisis es fundamental para evaluar la seguridad del proyecto, detectar posibles vulnerabilidades y garantizar la privacidad, autenticidad e integridad de nuestra aplicación y de los datos que manejamos.

2. HERRAMIENTA UTILIZADA

La herramienta utilizada es la herramienta ZAP. Esta herramienta es ampliamente utilizada en el sector, y permite hacer análisis automáticos de seguridad a aplicaciones web. El análisis lo hace descubriendo las rutas de la página web (mediante scrapping y otras técnicas) y buscando de forma pasiva y activa patrones o evidencias de problemas de seguridad conocidos.

Para el análisis hemos usado la configuración por defecto de la herramienta para facilitar la reproducibilidad del análisis.

3. RESULTADOS DEL ANÁLISIS

Los resultados del análisis se pueden ver en el archivo generado por ZAP. En este sprint hemos decidido hacer 2 análisis: uno al backend y al frontend antes de implementar medidas para solucionar algunos de los avisos que se reportaron en el S2, y otro después de implementarlas. Puede ver esos análisis en:

ZAP categoriza los avisos en informativo, bajo, medio y alto en función del riesgo que suponen. A continuación, hacemos un resumen de lo más importante de los resultados.

En el análisis del 07/04/25 del frontend se ha podido ver una evolución de los avisos que nos devuelve ZAP. Se ha pasado de 0 high, 2 medium, 4 low, 3 informational, a 0 high, 2 medium, 4 low y 10 informational. Si se analizan los avisos medium y low que nos da ZAP se ve que no ha habido variación en estos avisos. Como no la ha habido y la tabla es igual a la del S2, no la repito. Sin embargo, respecto a los avisos informational sí que se han econtrado nuevos. En este caso, todos avisan de que ZAP puede detectar las tecnologías que utilizamos y que no tenemos un header que controla la caché.

Un nuevo análisis que hemos implementado en este sprint es el análisis al backend. Estos son los resultados:

NombreNivel de riesgoNúmero de evidencias
Content Security Policy (CSP) Header Not SetMedio3
Server Leaks Version Information via "Server" HTTP Response Header FieldBajo3
Strict-Transport-Security Header Not SetBajo3
Re-examine Cache-control DirectivesInformational1
Tech Detected - NginxInformational1
Tech Detected - UbuntuInformational1

Como se puede ver, son avisos parecidos a los del frontend.

En el segundo análisis que hemos hecho hemos podido paliar uno de los avisos. Hemos pasado de 4 avisos low a 3 avisos low. Hemos solucionado el aviso "Server Leaks Information via "X-Powered-By" HTTP Response Header Field(s)". También, intentamos paliar uno de los avisos medium, el de "Missing Anti-clickjacking Header", pero no lo hemos conseguido y decidimos no dedicarle más recursos a solucionarlo porque no es una amenaza crítica. Por otro lado, el aviso medium "Content Security Policy (CSP) Header Not Set" y el aviso low "Strict-Transport-Security Header Not Set" no hemos querido solucionarlo porque la solución podría romper parte del sistema y desarrollo, y no son avisos críticos.

Respecto al backend, no ha habido cambios en el segundo análisis.

Hemos conseguido reducir el número de avisos low que tenemos y hemos fallado al intentar solucionar un aviso medium. Sin embargo, el nuevo código que se ha implementado en este sprint no parece que haya tenido impacto en la seguridad de la aplicación. Actualmente, ningún aviso necesita atención inmediata.

4. MEDIDAS DE SEGURIDAD IMPLEMENTADAS EN ESTE SPRINT

4.1 CONTROL DE LA INFRAESTRUCTURA

Se ha mejorado el control de la infraestructura de Fisio Find. Ahora, los servidores intermedios necesarios para las funcionalidades de videollamadas y correo están en un subdominio de Fisio Find.

4.2 CIFRADO

Se han implementado medidas de cifrado en las funcionalidades de Fisio Find. Por ejemplo, la funcionalidad de correo implementa cifrado.

También, hemos conseguido implementar cifrado en uno de los datos más sensibles que tratamos: el DNI. Según hemos analizado, si un atacante consigue acceso a la base de datos, este no podría recuperar los DNIs.

4.2.1 MIGRACIÓN A CRIPTOGRAFÍA POSTCUÁNTICA

Es sabido que los ordenadores cuánticos pueden romper la criptografía que llevamos utilizando años. Esto quiere decir que, en un futuro, todas las medidas de seguridad basadas en criptografía que utiliza Fisio Find (y muchas otras empresas) podrán romperse. En este contexto, lo que tiene sentido es encontrar algoritmos criptográficos que no puedan romper los ordenadores cuánticos (y tampoco los actuales) e implementarlos.

El pasado agosto de 2024, el NIST publicó los primeros estándares postcuánticos. Actualmente, existe la necesidad de migrar de los algoritmos criptográficos clásicos a algoritmos postcuánticos para evitar ataques como "harvest now, decrypt later". Sin embargo, debido a que muchas de las implementaciones de estos nuevos algoritmos son nuevas (por ejemplo, OpenSSL acaba de implementar importantes cambios respecto a la criptografía postcuántica y los esquemas híbridos en su nueva versión3.5.0) y podrían tener vulnerabilidades, y actualmente no existen ordenadores cuánticos, desde Fisio Find preferimos aplazar esta migración y no dedicar recursos a ello, sobre todo porque es probable que nuestros proveedores de hosting acaben implementando criptografía postcuántica en el HTTPS pronto.

4.3 ANÁLISIS DE CÓDIGO Y DEPENDENCIAS

Fisio Find desde antes del S3 implementa workflows que comprueban la seguridad del código y de las dependencias que utilizamos. En este sprint, nos han ido avisando de actualizaciones de dependencias y de malas prácticas de seguridad y vulnerabilidades en el código. Estos avisos han ido siendo resueltos y actualizados durante el sprint tras ser analizados. Github ya nos los clasifican por urgencia/riesgo, pero los avisos que han sido resueltos han sido porque lo ha decidido un miembro del equipo tras analizar riesgos y consecuencias del aviso.

Por otro lado, hemos decidido que no vamos a utilizar los avisos de seguridad que nos ofrece sonarqube, ya que tiene demasiados falsos positivos. Se seguirá monitorizando, pero no será una prioridad atender a esos avisos.

4.4 POLÍTICA DE SEGURIDAD

Fisio Find en su repositorio ha incluido una política de seguridad de GitHub que ofrece instrucciones detalladas para los usuarios de la aplicación sobre como reportar una vulnerabilidad. El término de política de seguridad es el nombre que le da GitHub al espacio especial que ofrece dentro de los repositorios para este tipo de avisos. Hemos implementado también un mecanismo para que se puedan reportar avisos anónimamente. Se puede ver desde este enlace: https://github.com/Proyecto-ISPP/FISIOFIND/security.

5. CONCLUSIONES

Después de este sprint, Fisio Find sigue sin presentar vulnerabilidades críticas que puedan ser encontradas con herramientas automáticas de análisis de seguridad. De hecho, realmente no tenemos vulnerabilidades, solo tenemos avisos, y los avisos que nos devuelve ZAP son genéricos (muchas otras webs lo tienen y no hay consecuencias inmediatas) y no necesitan de acciones inminentes. Sin embargo, se deben seguir tomando medidas correctivas para la siguiente entrega porque se aspira a tener el mínimo número de avisos. En esta entrega se ha intentado reducir este número y se ha conseguido parcialmente, pero se desea seguir mejorando en este aspecto.

Por otro lado, el equipo de Fisio Find está implementando medidas de seguridad (además de las correctivas de los análisis de ZAP) que hacen de Fisio Find una aplicación más segura.