Investigación de vulnerabilidades en seis productos SaaS propios
Cómo evaluamos rutas críticas en APIs, aplicaciones web y móviles e infraestructura de productos que desarrollamos y operamos.
Este documento registra el enfoque de investigación de seguridad que Cloudsoft Industries aplica sobre seis productos SaaS propios: MiPOS Digital, MasiBot, VitalSync, Rekurra, AquaGestión y MiCarta Digital. El alcance comprende APIs de backend, aplicaciones web y móviles, flujos de autenticación y autorización, integraciones e infraestructura que desarrollamos y operamos.
Es importante delimitarlo con precisión: esta investigación se realiza sobre sistemas propios o dentro de pruebas expresamente autorizadas. No describe pruebas sobre sistemas de terceros ni de clientes sin autorización. También evita publicar secretos, datos personales, cargas útiles reutilizables o detalles que permitan atacar una instancia activa.
Pregunta de investigación
La pregunta que guía el trabajo no es simplemente “¿el escáner encontró algo?”. Buscamos determinar si un usuario, integración o proceso con privilegios limitados puede cruzar una frontera de confianza y afectar confidencialidad, integridad o disponibilidad. En productos SaaS multiempresa esto exige evaluar el sistema completo: interfaz, API, reglas de negocio, trabajos asíncronos, almacenamiento y configuración de despliegue.
La investigación prioriza rutas donde una falla tendría impacto material:
- Aislamiento entre organizaciones. Verificamos que identificadores manipulados, búsquedas, exportaciones y endpoints internos no permitan leer o modificar datos de otro tenant.
- Autenticación y recuperación. Revisamos sesión, rotación de tokens, restablecimiento de credenciales, invalidación y cambios de rol.
- Autorización por objeto y función. Probamos la diferencia entre poder ver una pantalla y tener permiso real para ejecutar la operación en el servidor.
- Flujos sensibles. Evaluamos pagos, webhooks, creación de usuarios, conciliaciones, notificaciones y operaciones administrativas.
- Configuración e infraestructura. Revisamos secretos, encabezados, almacenamiento público, permisos de servicio, registros y separación entre ambientes.
Portafolio y superficies cubiertas
| Producto | Superficies incluidas | Fronteras prioritarias |
|---|---|---|
| MiPOS Digital | API, backoffice y clientes web/móviles | Roles, operaciones comerciales, aislamiento por negocio e integraciones |
| MasiBot | API, automatizaciones y consola | Permisos de herramientas, datos conversacionales y acciones automatizadas |
| VitalSync | API y aplicaciones de operación | Datos sensibles, sesión, trazabilidad y privilegios |
| Rekurra | API, webhooks y panel de gestión | Integridad de eventos, idempotencia, autorización y secretos |
| AquaGestión | API y aplicación web | Separación de cuentas, operaciones administrativas y exportación de datos |
| MiCarta Digital | Aplicación web, API e infraestructura | Publicación de contenido, administración y configuración de despliegue |
La tabla define superficies de investigación, no afirma que cada producto contenga una vulnerabilidad específica. La severidad se asigna únicamente después de reproducir una condición y demostrar su impacto dentro del entorno controlado.
Método reproducible
- Inventario y modelo de confianza. Enumeramos activos, roles, entradas, salidas, integraciones y límites entre organizaciones. Una ruta que no aparece en el inventario no se puede defender de forma sistemática.
- Hipótesis de abuso. Convertimos cada frontera en preguntas comprobables: ¿puede un rol básico invocar una función administrativa?, ¿se puede reutilizar un webhook?, ¿un identificador predecible expone datos ajenos?
- Prueba manual y asistida. Combinamos revisión de código y configuración, pruebas de API, manipulación de estado y automatización acotada. Los escáneres sirven para ampliar cobertura, no para emitir el veredicto.
- Reproducción mínima. Conservamos solicitud, precondiciones, respuesta observada, impacto y controles esperados. La evidencia debe permitir que otro ingeniero reproduzca el hallazgo sin depender de una explicación oral.
- Clasificación. Usamos CVSS v4.0 de FIRST como lenguaje técnico común y añadimos contexto del producto: sensibilidad, alcance entre tenants, privilegios y posibilidad de recuperación.
- Corrección y retest. El hallazgo no se cierra al fusionar código. Se repite la reproducción original, se prueban variantes relacionadas y se verifica que el cambio no haya debilitado otra frontera.
Criterios de evaluación
La cobertura se apoya en referencias abiertas y verificables. Para APIs utilizamos las clases de riesgo de OWASP API Security Top 10 2023; para controles de aplicaciones web y servicios tomamos requisitos de OWASP ASVS 5.0.0. La planificación, el manejo de evidencia y la comunicación de resultados siguen los principios de NIST SP 800-115.
Estas referencias no sustituyen el análisis del producto. Una debilidad técnicamente común puede convertirse en una condición crítica cuando cruza organizaciones o permite operar dinero, identidad o datos sensibles; también puede tener menor impacto si existen controles compensatorios verificables.
Evidencia, divulgación y límites
Por cada condición confirmada mantenemos un registro con activo, versión, precondiciones, pasos de reproducción, evidencia, impacto, severidad, propietario de la corrección y resultado del retest. La evidencia sensible permanece en el repositorio privado correspondiente. Esta publicación hace público el método y el alcance sin convertir un informe defensivo en una guía de explotación.
No atribuimos un CVE a un hallazgo interno por defecto. Un CVE requiere que exista una vulnerabilidad divulgable en un producto relevante para terceros y que el proceso de coordinación lo justifique. Tampoco presentamos la ausencia de incidentes conocidos como prueba de seguridad. La señal útil es otra: investigación repetible, trazabilidad de la corrección y validación independiente del parche.
Resultado operativo
El resultado de este trabajo es un ciclo continuo: descubrir, reproducir, priorizar, corregir y volver a probar. Cuando prestamos pruebas de seguridad controladas a un desarrollo autorizado, aplicamos la misma disciplina con reglas de compromiso, activos permitidos, ventanas de prueba y criterios de detención definidos antes de comenzar.
La investigación sobre nuestros propios productos nos permite probar el proceso de extremo a extremo: el mismo equipo puede rastrear una condición desde la solicitud HTTP o el cambio de estado móvil hasta la regla de dominio, la infraestructura y la prueba de regresión que evita su retorno. El artículo complementario explica en detalle cómo validamos un parche antes de cerrar un hallazgo.
Validación de parches de seguridad: del hallazgo al cierre
Un parche no está validado porque el código compiló: debe eliminar la ruta de ataque, resistir variantes y dejar evidencia reproducible.
Investigación de vulnerabilidades en MiPOS Digital: primeros resultados
El primer ciclo completo de investigación sobre MiPOS Digital produjo 28 hallazgos reproducibles y un plan de remediación verificable, sin exponer evidencia sensible.