--- type: PLAN asset_id: PLAN-EL-PlatformSecurity-ActiveTest-MPX-v01 version: v01 status: Activo confidencial: true owner: Victor Heredia sherpa_owner: Jay ratificador: Victor Heredia fecha_creacion: 2026-07-03 fecha_ultima_actualizacion: 2026-07-03 intellibank: IB-EL-EmpowerLabs subbank: PB-EL-Plataforma proyecto: Platform Intelligence (TP-EL-PlatformIntelligence-MPX-RClub-v01) proposito: > Plan de prueba activa (pentest controlado) para CONFIRMAR los hallazgos "por confirmar" de AUD-EL-PlatformSecurity-MPX-v01. Este documento define el alcance, los casos, el entorno y las reglas de ejecución. NO es la ejecución — la corre el equipo dev o un pentester autorizado, preferentemente en STAGING, nunca contra producción con datos reales de usuarios. referencia: AUD-EL-PlatformSecurity-MPX-v01 tags: [PLAN, seguridad, pentest, MPX, confidencial, platform-intelligence, staging] --- # PLAN · Prueba Activa de Seguridad — MasterPlaybooks v01 ## Test plan para confirmar hallazgos del AUD · CONFIDENCIAL > **Tripleta WORX** — Owner: Victor Heredia · Sherpa: Jay · Ratificador: Victor Heredia > **⚠️ CONFIDENCIAL.** No compartir fuera del equipo core. > **Regla de oro:** ejecutar en **entorno de staging con datos sintéticos**. Si es imposible y debe correrse en producción, hacerlo en ventana de mantenimiento, con backup previo, con consentimiento escrito, y sin exfiltrar PII real. --- ## §0 · Por qué este plan (y qué NO es) La auditoría pasiva (`AUD-EL-PlatformSecurity-MPX-v01`) dejó hallazgos **"por confirmar"** que solo se validan intentando activamente el ataque: autorización cross-canal, IDOR, validación de rol en backend. Confirmarlos requiere manipular peticiones para intentar acceder a datos que no corresponden al usuario — una prueba que **no debe hacerse a ciegas contra producción con 48 usuarios reales**. Este plan define **cómo** hacerlo de forma responsable. La ejecución es responsabilidad del equipo dev (Alex/Jesús) o de un pentester externo autorizado. El SherpaX (Jay) **no ejecuta ataques activos contra sistemas en vivo**; sí puede asistir en el análisis de resultados y en el Code Review estático (M4). --- ## §1 · Pre-requisitos (gate de arranque) - [ ] **Entorno de staging** que replique prod, poblado con **usuarios sintéticos** (mínimo: 2 canales distintos × 2 roles cada uno = usuario normal y admin, en MPX y en RClub). - [ ] **Autorización escrita** del owner (Victor) con alcance y ventana definidos. - [ ] **Backup** de la base de staging antes de iniciar. - [ ] **Bitácora** de ejecución (quién, cuándo, qué request, qué respuesta) para trazabilidad. - [ ] Acuerdo de **no exfiltración**: ningún dato real de usuario sale del entorno de prueba. --- ## §2 · Casos de prueba Cada caso indica: hipótesis (del AUD), método, resultado esperado si está seguro, y severidad si falla. ### CT-01 · Autorización cross-canal en admin (SEC-ISO-01/02) - **Hipótesis:** el endpoint `POST /api/playbook/get/companies` (y afines del admin) devuelve datos de canales que no pertenecen al solicitante. - **Método (staging):** autenticarse como **admin del canal A**, llamar los endpoints admin solicitando explícitamente el `channel_id` del **canal B**. Repetir como **usuario normal del canal A** apuntando a recursos admin. - **Seguro si:** el backend responde 403/empty para canal ajeno y para rol insuficiente. - **Falla (severidad Alta) si:** devuelve datos del canal B, o un usuario normal obtiene respuesta de endpoint admin. ### CT-02 · IDOR en recursos de usuario (SEC-AUTH-02) - **Hipótesis:** manipular un identificador (userId, playbookId, membershipId) permite leer/editar recursos de otro usuario. - **Método (staging):** como **usuario U1**, tomar una petición legítima (p.ej. ver membresía, notas, artefactos, historial de Sherpa) y sustituir el ID por el de **U2**. - **Seguro si:** responde 403/404 sin filtrar datos de U2. - **Falla (Alta) si:** devuelve o modifica recursos de U2. ### CT-03 · Control de acceso al host de imágenes / PII (SEC-PII-01/02) - **Hipótesis:** las fotos de perfil son accesibles sin autenticación y sus URLs son enumerables (nombre de archivo = email/nombre). - **Método (staging):** desde una sesión **no autenticada**, solicitar la URL de la foto de un usuario sintético; probar si el directorio `php/imagenes/` permite listado. - **Seguro si:** requiere URL firmada/token temporal y no permite listado de directorio. - **Falla (Alta) si:** la imagen carga sin auth y/o el email queda expuesto en la URL, y/o el directorio lista archivos. ### CT-04 · Validación de rol en endpoints sensibles (SEC-AUTH-02) - **Hipótesis:** las rutas admin están protegidas solo en la UI, no en el backend. - **Método (staging):** como **usuario normal**, llamar directamente los endpoints que alimentan Dashboard/Estadísticas/Panel/Canal (sin pasar por la UI). - **Seguro si:** el backend exige rol admin y responde 403. - **Falla (Alta) si:** responde con datos. ### CT-05 · Aislamiento del contexto de IA (relación con P0 del diagnóstico funcional) - **Hipótesis:** el Sherpa/KatIA puede filtrar contexto entre usuarios o canales, o ser inducido a revelar datos de otro contexto (prompt injection). - **Método (staging):** como usuario sintético, intentar que el Sherpa devuelva información de otro usuario/canal o de su prompt de sistema. - **Seguro si:** el Sherpa mantiene el contexto acotado al usuario/playbook/canal. - **Falla (Media-Alta) si:** filtra contexto ajeno. ### CT-06 · Manejo de sesión y tokens (SEC-AUTH-01/03) - **Hipótesis:** el token de sesión es robusto (expira, se invalida al logout, no es replayable). - **Método (staging):** verificar expiración, invalidación en logout, y que el token no funcione tras cierre de sesión. - **Seguro si:** expira y se invalida correctamente. - **Falla (Media) si:** el token sigue válido tras logout o no expira. --- ## §3 · Cobertura complementaria por Code Review (M4, sin riesgo) Estos puntos se confirman mejor leyendo el código que atacando — hacerlos en el Módulo 4 con acceso al repo: - Validación de `channel_id` y rol en cada controlador de API (CT-01/CT-04 en estático). - Consultas parametrizadas vs. concatenación (riesgo SQLi) en la capa `/api/` (PHP). - Generación de URLs de imágenes: dónde se decide el nombre de archivo (CT-03). - Configuración de headers en LiteSpeed (SEC-HDR-*). - Manejo de secretos del lado servidor (env vars, no en repo). --- ## §4 · Reglas de ejecución (obligatorias) 1. **Staging primero.** Producción solo con autorización escrita explícita, ventana de mantenimiento y backup. 2. **Datos sintéticos.** Nunca usar ni exfiltrar PII de usuarios reales. 3. **No destructivo.** Prohibido borrar, corromper o alterar datos de producción. 4. **Trazabilidad.** Toda petición de prueba queda en bitácora. 5. **Parar ante hallazgo crítico.** Si un caso confirma acceso a datos reales, detener, documentar y escalar a Victor antes de continuar. 6. **Ejecutor autorizado.** Equipo dev (Alex/Jesús) o pentester externo. El SherpaX asiste en análisis, no en ejecución de ataques a sistemas en vivo. --- ## §5 · Entregable esperado `OUT-EL-PlatformSecurity-ActiveTestReport-MPX-v01.md` — resultado por caso (seguro/falla), evidencia en bitácora, severidad confirmada, y recomendación de remediación. Alimenta el mismo backlog de seguridad del AUD. --- ## §6 · NEXTs - [ ] **NEXT Victor:** confirmar entorno (¿existe staging? si no, ¿se crea?) + autorización escrita + ventana. - [ ] **NEXT Alex:** preparar staging con usuarios sintéticos (2 canales × 2 roles) o, en su defecto, priorizar el Code Review (M4) que cubre CT-01/03/04 en estático. - [ ] **NEXT Jay:** integrar los casos CT-* como hipótesis del Módulo 4 (Code Review) y asistir en el análisis de resultados. --- ## CHANGELOG | Versión | Fecha | Cambio | |---|---|---| | v01 | 2026-07-03 | Test plan inicial de fase activa. 6 casos (cross-canal, IDOR, PII/host imágenes, rol en backend, aislamiento IA, sesión) + cobertura complementaria por Code Review + reglas de ejecución responsable en staging. | --- *Plan de prueba activa · Jay (SherpaX) · 2026-07-03 · Proyecto Platform Intelligence · CONFIDENCIAL · La ejecución la realiza el equipo dev / pentester autorizado, no el SherpaX*