Auditoría de seguridad

La revisión encontró vulnerabilidades en el control de acceso, la autenticación, el registro interno y las librerías de terceros. Doce quedaron corregidas, dos de ellas críticas, y se verificaron una a una contra el sistema en marcha, no solo sobre el papel.

Las correcciones tampoco se dieron por buenas: se volvió a testear el código de forma independiente para confirmar y refinar cada hallazgo, y esa segunda pasada encontró tres problemas más y dos fallos dentro de los propios arreglos. Todo ello corregido y cubierto con pruebas dedicadas.

Qué hay en juego

Qué protege este trabajo

Traducido a lo que se toca desde fuera, en lugar de a categorías de norma. Cada punto corresponde a correcciones ya aplicadas.

Tu correo, tu calendario y tus documentos

El asistente actúa con tus permisos sobre tus propias cuentas. Ahora solo atiende peticiones cuyo origen puede verificar, de modo que nadie puede dirigirse a él en tu nombre.

Antes: el canal de entrada no comprobaba quién escribía.

Los datos financieros del fondo

Portfolio, pipeline, contactos y cuentas conviven en el mismo panel. El alta de usuarios exige hoy autorización explícita, con contraseña mínima real y límite de intentos.

Antes: cualquiera podía crearse una cuenta y entrar.

Las credenciales de tus integraciones

Las conexiones con Google, Notion y Outlook son llaves de acceso a tus servicios. Ante determinados errores quedaban escritas en el registro interno de la aplicación; hoy aparecen ocultas.

Antes: legibles para quien pudiera leer los registros.

Los archivos que llegan de fuera

Cada PDF que entra por WhatsApp lo abre una librería del sistema, y es la superficie más expuesta que existe: contenido que envía un tercero. Estaba treinta versiones por detrás y hoy está al día.

Antes: 37 fallos catalogados sin corregir. Hoy: 0.

Metodología

Contra qué se auditó

Una auditoría vale lo que vale su lista de comprobación. Esta no se hizo contra un criterio propio, sino contra los estándares que usan los auditores externos, los clientes corporativos y los procesos de certificación. Cada hallazgo lleva su identificador en las normas que le aplican, de forma que cualquier tercero pueda seguir el rastro.

OWASP Top 10:2025

La lista de referencia del sector con los diez riesgos más críticos de una aplicación web. Es el estándar que casi cualquier cliente o auditor pide primero. Se evaluaron las diez categorías.

NIST CSF 2.0

El marco del instituto de estándares de Estados Unidos. Ordena la seguridad en seis funciones: gobernar, identificar, proteger, detectar, responder y recuperar.

CWE y SANS Top 25

El catálogo común de tipos de debilidad de software y la lista de los 25 errores más peligrosos. Da un identificador universal a cada hallazgo. Se identificaron 10 tipos distintos.

OWASP ASVS 5.0

El estándar de verificación de seguridad en aplicaciones. Convierte los riesgos generales en requisitos concretos y comprobables, uno por uno.

PCI DSS 4.0.1

La norma del sector de tarjetas de pago. La plataforma no procesa tarjetas, pero sus exigencias de autenticación y registro de accesos son el mismo listón.

MITRE ATT&CK

El catálogo de técnicas de ataque realmente observadas en incidentes. Permite describir cada hallazgo por cómo se explotaría en la práctica, no solo por su categoría teórica.

SOC 2

El marco de controles que auditan las empresas de servicios para demostrar a sus clientes cómo protegen los datos que les confían.

ISO 27001:2022

La norma internacional de gestión de la seguridad de la información, la certificable. Se cruzaron los hallazgos con sus controles de criptografía, acceso y registro.

Pack SaaS multiusuario

Añadido sobre lo anterior: comprobaciones específicas de aislamiento entre clientes, que es el riesgo propio de una plataforma donde varios usuarios comparten infraestructura.

Hallazgos

Qué se encontró y qué se hizo

Cada hallazgo con qué pasaba, qué permitía y cómo se cerró. En términos de efecto, no de mecanismo: sin rutas, comandos ni pasos reproducibles. La columna izquierda indica la parte del sistema afectada.

Crítico Agente

El canal de mensajería aceptaba peticiones sin comprobar su origen

Problema

El punto por donde entran los mensajes al agente no comprobaba de dónde venían. Daba por bueno cualquier mensaje que dijera venir de un usuario, con solo indicar su número.

Riesgo

Quien conociera la dirección del servicio podía hacerse pasar por cualquier usuario ya registrado, y el agente lo atendía como si fuera esa persona: leer y reenviar su correo, mirar su calendario y sus documentos, actuar en su nombre. Era el punto más sensible del sistema, porque es la puerta que da acceso al agente con todos sus permisos.

Solución

La puerta exige ahora una credencial compartida que solo tienen los servicios internos, el conector de mensajería y el motor del agente. Un mensaje que no la traiga se rechaza antes de llegar al agente. Es la misma comprobación que el resto del sistema ya aplicaba; este punto era la excepción.

Corregido

Crítico Panel web

El alta de cuentas del panel estaba abierta

Problema

El panel tenía una vía de alta de usuarios que no pedía ninguna credencial. Bastaba enviar un correo y una contraseña para quedarse con una cuenta que entraba.

Riesgo

El sistema no distingue niveles de usuario, así que una cuenta creada por un desconocido veía exactamente lo mismo que la del equipo: portfolio, finanzas, pipeline, contactos y cuentas bancarias del fondo.

Solución

Esa vía exige ahora la credencial de administración que solo tiene el equipo, la misma que ya protegía las invitaciones. El panel nunca la usó, no hay ningún formulario de alta en la interfaz, así que cerrarla no afecta a ningún flujo real: las altas de verdad se hacen por otro camino.

Corregido

Alto Panel web · acceso

Contraseñas débiles y sin límite de intentos

Problema

La pantalla de acceso aceptaba cualquier contraseña, incluso vacía, y no ponía tope al número de intentos de entrada.

Riesgo

Una contraseña trivial es fácil de adivinar, y sin tope un atacante puede probar miles de combinaciones por minuto hasta acertar.

Solución

Dos medidas. La contraseña exige un mínimo de doce caracteres, y el sistema corta tras cinco intentos fallidos desde la misma dirección. Además cuenta por la dirección real del visitante, no por la del servidor intermedio, para que no se puedan repartir los intentos y esquivar el límite.

Corregido

Alto Servidor · registros

Secretos visibles en los registros internos

Problema

Cuando una petición a ciertas direcciones internas llegaba mal formada, la aplicación anotaba en su registro de diagnóstico las cabeceras de esa petición, y entre ellas la credencial de acceso, en texto legible.

Riesgo

Los registros los consulta el equipo y a veces se archivan o se envían a herramientas de terceros. Una credencial escrita ahí queda a la vista de más gente de la debida, y el error era fácil de provocar a propósito.

Solución

Esos valores aparecen ahora tapados en el registro: se conserva que la cabecera vino, pero no su contenido, junto con el resto de la información útil para diagnosticar.

Corregido

Alto Panel web y servidor

Librerías de terceros con fallos conocidos

Problema

El sistema se apoya en librerías de terceros, y varias estaban en versiones con fallos de seguridad ya publicados: quince en el panel web y cuarenta y cuatro catalogados en dos librerías del servidor.

Riesgo

Un fallo público es el más fácil de aprovechar, porque el método ya circula. Una de las afectadas es la que abre los archivos PDF que llegan por WhatsApp, es decir contenido que envía un tercero: la superficie más expuesta que hay.

Solución

Todas actualizadas a versiones sin fallos conocidos, comprobando que la actualización no rompía nada. El recuento pasó a cero en ambos lados.

Corregido

Medio Servidor · API

Comparación de claves que se filtraba por el tiempo

Problema

En varios puntos, la comprobación de una clave de acceso tardaba un poco más o un poco menos según cuántos caracteres del principio coincidían.

Riesgo

Esa mínima diferencia de tiempo, medida con paciencia, permite en teoría ir adivinando la clave carácter a carácter. Es un ataque sofisticado, pero conocido.

Solución

Se cambió por una comprobación que tarda siempre lo mismo, acierte o no, de modo que el tiempo ya no revela nada. Se aplicó en los tres puntos donde estaba, no solo en el que señaló la auditoría.

Corregido

Medio Agente

Un segundo punto de entrada tampoco verificaba el origen

Problema

Además del canal principal, había una vía interna, la que asocia el identificador técnico de WhatsApp con el número de teléfono real, que tampoco pedía credencial.

Riesgo

Alguien podía introducir asociaciones falsas y alterar a qué usuario se atribuye un mensaje, corrompiendo el enrutamiento del propio canal principal.

Solución

Esa vía exige ahora la misma credencial interna que el canal de mensajería del primer punto.

Corregido

Medio Panel web

Faltaban cabeceras de protección del navegador

Problema

El servidor no enviaba al navegador un conjunto de instrucciones estándar que endurecen cómo se muestra y se trata la página.

Riesgo

Sin ellas, el navegador es más permisivo con ciertos abusos: que la página se incruste en un sitio ajeno para engañar al usuario, o que interprete un archivo como algo distinto de lo que es.

Solución

Se añadieron las protecciones principales: impedir el incrustado en sitios ajenos, forzar la conexión cifrada y evitar la reinterpretación de archivos. Una protección adicional más estricta se dejó pendiente a propósito, para no romper las pantallas de conexión con Google y Notion sin poder probarlas antes en el entorno real.

Corregido

Medio Servidor · API

Librería de sesiones con historial de avisos

Problema

La librería que gestiona los testigos de sesión, lo que mantiene identificado a un usuario tras entrar, arrastraba avisos de seguridad y poco mantenimiento.

Riesgo

El uso concreto que hace el sistema no coincidía con el vector de esos avisos, así que no era explotable aquí, pero apoyarse en un componente con ese historial es una deuda a vigilar.

Solución

Actualizada a la versión mantenida, comprobando que la parte que el sistema usa de verdad sigue funcionando igual.

Corregido

Bajo Entorno de desarrollo

Herramientas de desarrollo desactualizadas

Problema

Varias utilidades de trabajo tenían versiones con fallos conocidos.

Riesgo

Solo se usan mientras se desarrolla y nunca forman parte del sistema que ven los usuarios, así que la exposición real es mínima.

Solución

Actualizadas igualmente, para no arrastrar deuda.

Corregido

Verificación

Cómo se comprobó que las correcciones funcionan

909 pruebas automáticas del servidor en verde tras los cambios

27 / 27 pruebas del panel web, sin regresiones

0 vulnerabilidades pendientes en dependencias

Segunda pasada independiente. El informe no se dio por bueno: se volvió a testear el código para confirmar y refinar cada hallazgo. Esa segunda pasada encontró tres problemas más que la primera no había detectado.
Revisión adversarial de las propias correcciones. Al auditar los arreglos aparecieron dos fallos dentro de ellos, corregidos también. Cada uno tiene ahora una prueba dedicada para que no pueda reaparecer sin que salte.
Sistemas reales, no simulaciones. Servidor, panel web y base de datos levantados de verdad y sometidos a peticiones reales: contraseña de 11 caracteres rechazada y de 12 aceptada, sexto intento de acceso bloqueado, la ventana de bloqueo reabriéndose sola al expirar, y las credenciales apareciendo ocultas en el registro.
Comprobación de efectos colaterales. Se verificó que el bloqueo por intentos no rompe la pantalla de acceso, y que la actualización de librerías no introduce ni un error nuevo respecto de la versión anterior.