Portada ====== Título: Análisis de Seguridad (Threat Modeling) del diseño conceptual de la API de facturación Autor: Equipo de Seguridad — Investigador Automatizado Afiliación: Servicio de Investigación en Seguridad Fecha: 2026-08-03 Resumen ====== Resumen (Abstract) Este informe presenta un análisis de seguridad (Threat Modeling) exhaustivo del diseño conceptual de una API de facturación cuyo alcance incluye: JWT (autenticación/autorización), Endpoints REST, Subida de PDFs, Webhooks de pago y Panel de Administración. Debido a restricciones temporales en el acceso a fuentes externas (límites de búsqueda de la herramienta), el informe se entrega como un borrador técnico y operativo que contiene: mapeo de amenazas STRIDE, priorización de cinco riesgos críticos, controles técnicos concretos para cada riesgo (validaciones, cabeceras HTTP requeridas, políticas de rate limiting, requisitos de auditoría) y un Plan de Pruebas de Seguridad (Security Test Plan). Las recomendaciones se basan en prácticas de seguridad ampliamente aceptadas; las referencias formales (OWASP, RFCs, guías de proveedores de pagos) están listadas como pendientes de verificación externa debido a limitaciones de acceso sede. Todas las afirmaciones importantes señaladas en el texto que requieran evidencia externa están marcadas como [POR VERIFICAR]. Introducción ====== Contexto y alcance La API de facturación gestiona datos financieros sensibles (facturas, montos, identificadores de clientes, estados de pago) y se compone de los siguientes componentes conceptuales: autenticación basada en JSON Web Tokens (JWT), endpoints REST públicos/privados para gestión de facturas, mecanismo para subir documentos PDF (p. ej., facturas escaneadas), webhooks para notificaciones de pago desde procesadores externos y un panel de administración para operaciones y soporte. La seguridad es prioritaria. Objetivos del informe 1. Realizar un Threat Modeling basado en STRIDE para identificar amenazas relevantes según cada componente. 2. Priorizar exactamente cinco riesgos críticos y proponer controles técnicos concretos para mitigarlos. 3. Entregar un borrador de Plan de Pruebas de Seguridad (Security Test Plan) aplicable al ciclo de desarrollo. 4. Documentar vacíos de información y pasos pendientes para verificación externa. Metodología ====== Enfoque Se empleó un enfoque de revisión técnica y de diseño: examen conceptual de componentes, identificación de superficies de ataque, mapeo STRIDE, priorización por impacto/probabilidad, y definición de controles técnicos y pruebas. Por limitaciones técnicas al ejecutar búsquedas web automatizadas en tiempo real (rate-limits en el servicio de búsqueda), este documento se elabora como un borrador técnico basado en prácticas profesionales y en conocimiento consolidado en la comunidad de seguridad. Todas las afirmaciones que requieren fuentes externas están marcadas como [POR VERIFICAR] o [NO VERIFICADO]. Limitaciones - Acceso a recursos en línea (OWASP, RFCs, guías de proveedores de pago) temporalmente bloqueado; referencias formales están pendientes de verificación. - No se realizaron pruebas dinámicas ni análisis de código (no se disponen artefactos ejecutables o repositorio). Plan aprobado — Aclaraciones previas y Plan de Investigación ====== Antes de proseguir con la fase completa de investigación y verificación externa, y conforme al protocolo aprobado, se presentan (A) preguntas aclaratorias críticas que requieren respuesta por el patrocinador/propietario del sistema y (B) un Plan de Investigación operacional, secuencial y asignado por roles. A) Preguntas aclaratorias imprescindibles (responder o indicar "usar supuestos estándar") 1. Alcance funcional y datos exactos - ¿La API maneja datos de tarjetas (PAN), tokens de pago, o solo estados/IDs de pago? (PCI scope) 2. Proveedores de pago y entorno - ¿Qué proveedor(es) de pago están o estarán integrados (Stripe, Adyen, PayU, otro) y si existe modo sandbox? 3. Implementación de autenticación actual - ¿Se usa JWT ya en producción? ¿Qué algoritmos y dónde se almacenan las claves (KMS/HSM)? 4. Flujos de tokens - ¿Se usan access tokens + refresh tokens? ¿Hay mecanismo de revocación actual? 5. Subida y procesamiento de PDFs - ¿Qué componentes procesan PDFs (microservicio propio, third-party, Lambda)? ¿Se generan previews en servidor? 6. Infraestructura y despliegue - ¿Panel de admin está en la misma red/host que la API pública? ¿Existe WAF, CDN o balanceador con offload TLS? 7. Requisitos regulatorios - ¿Aplica PCI DSS en el alcance? ¿GDPR/LOPD? ¿Régimen de retención legal para facturas? 8. Logs y SIEM - ¿Dónde se almacenan logs y quién tiene acceso? ¿Existe SIEM y políticas de retención? 9. Equipo y recursos - Plazo para remediaciones críticas (SLA), equipo responsable (devs, ops, seguridad) y presupuesto para pruebas (pentest pago, tools). 10. Entregables y formato - ¿Se requiere el informe final en APA (sí), incluir anexos de PoC, o solo hallazgos y plan de corrección? Si no se responden en 72 horas, se procederá con "supuestos estándar" documentados en la sección de alcance y el plan de pruebas se adaptará en consecuencia. B) Plan de Investigación — estratégico, modular y accionable Objetivo general (plantilla) - Determinar y verificar la seguridad de la API de facturación (componentes JWT, REST, File Upload, Webhooks, Admin) y validar controles mediante pruebas técnicas en ambiente de staging. Alcance y exclusiones - Incluye: revisión de diseño, validación de configuración JWT, pruebas dinámicas en endpoints (autenticación/autorización), pruebas de subida de archivos, verificación de webhooks, pruebas del panel admin. - Excluye: auditoría de infraestructura de terceros fuera del alcance contractual (p. ej., responsabilidad de proveedor de pagos), revisión de código de librerías externas. Cronograma maestro (resumen por fases) - Fase 0 — Aclaración y aprobación de alcance: 1 semana - Fase 1 — Recolección de artefactos y acceso (credenciales, keys de staging, endpoints): 1 semana - Fase 2 — Revisión documental y SCA: 1 semana - Fase 3 — Pruebas de seguridad (SAST/SCA/Dynamic pentest API + uploads + webhooks + admin): 2 semanas - Fase 4 — Análisis, priorización y plan de remediación: 1 semana - Fase 5 — Verificación de correcciones y cierre: 1 semana Pasos secuenciales con responsabilidades y entregables Fase 0 — Aclaración y aprobación - Acciones: obtener respuestas sección A; validar alcance con sponsor - Responsable: Investigador Senior - Entregable: Documento "Objetivo & Alcance" aprobado Fase 1 — Acceso y coleccion de artefactos - Acciones: solicitud de credenciales de staging, endpoints, claves públicas de proveedores, acceso al bucket de uploads (solo lectura), politicas de IAM. - Responsable: Seguridad (coordina) + DevOps (provee accesos) - Entregable: Accesos validados, checklist de artefactos Fase 2 — Revisión estática y SCA - Acciones: revisar configuración JWT, encabezados HTTP aplicados, SCA para dependencias - Responsable: INVESTIGADOR + REDACTOR/REVISOR (documenta hallazgos) - Entregable: Informe SCA y checklist de configuración Fase 3 — Pruebas dinámicas y pentest controlado - Acciones: ejecutar Security Test Plan (TCs listados en este informe), fuzzing, pruebas de uploads en sandbox, webhooks falsos, pruebas RBAC en admin - Responsable: Seguridad (ejecución), INVESTIGADOR (recolección de evidencias) - Entregable: Informe técnico de hallazgos (con PoC en ambiente controlado) y prioridad CVSS-like Fase 4 — Remediación y re-evaluación - Acciones: trabajar con devs para aplicar mitigaciones; re-test de fallos críticos - Responsable: Devs (remediación) + Seguridad (verificación) - Entregable: Plan de corrección y evidencia de fixes Fase 5 — Informe final y cierre - Acciones: redactar informe final APA 7a edicion, incluir referencias verificadas, anexos de pruebas y recomendaciones operativas - Responsable: REDACTOR/REVISOR + INVESTIGADOR - Entregable: Informe final publicado y firmado por sponsor Roles y responsabilidades (resumen) - INVESTIGADOR: diseño del protocolo, ejecución parcial de pruebas, documentación de hallazgos - REDACTOR/REVISOR: edición del informe en APA, control de referencias y calidad - Seguridad / Compliance: ejecución del Security Test Plan, control de accesos y pruebas técnicas - DevOps/Infra: proveer accesos y aplicar cambios en staging - Coordinador de proyecto: seguimiento de cronograma y comunicación con stakeholders Gestión de riesgos (breve) - Falta de accesos: trigger 5 días → escalado al sponsor - Entorno de pruebas inestable: priorizar pruebas offline (SAST/SCA) - Descubrimiento de vulnerabilidades críticas: política de divulgación interna y SLA 48 horas para mitigación urgente Plan de Pruebas de Seguridad (resumen operativo) - Verificar: firma JWT, revocación, alg none; validación de claims - Pentest API: autorización, inyección, rate limiting - Uploads: magic number, escaneo AV, sandboxing - Webhooks: firma+timestamp+dedupe - Admin: MFA, RBAC, session management, XSS/CSRF Criterios de calidad y aceptación - Protocolo aprobado por sponsor - 0 hallazgos críticos abiertos al cierre - Todos los hallazgos con PoC documentado y plan de corrección Resultados ====== 1. Mapeo STRIDE por componente - JWT (Autenticación/Autorización) - Spoofing: tokens robados o fabricados que permiten suplantación. - Tampering: modificación de tokens si firma/validación incorrecta. - Repudiation: falta de trazabilidad si no hay registro de sesión/token. - Information disclosure: tokens con claims sensibles expuestos. - Endpoints REST - Spoofing: credenciales comprometidas o faltas de validación de origen. - Tampering: inyección de parámetros que alteren lógica (SQL/NoSQL/OS). - Repudiation: ausencia de registro de cambios y transacciones. - Denial of Service: endpoints sin limitación adecuados. - Subida de PDFs - Tampering: archivos maliciosos que contienen scripts o payloads, manipulación de metadatos. - Information disclosure: PDF con metadatos sensibles. - Elevation (part of Spoofing/Tampering): ejecución de procesos de conversión que permitieran ejecución no deseada. - Webhooks de pago - Spoofing: peticiones de webhook falsificadas. - Repudiation: falta de registro de eventos autenticados. - Tampering: modificación de payload en tránsito. - Panel de Administración - Spoofing/Elevation of Privilege: credenciales débiles, ausencia de MFA o RBAC granular. - Tampering: acciones administrativas que modifiquen datos críticos. - Information disclosure: vista de datos sensibles sin necesidad. 2. Priorización exacta: CINCO riesgos críticos (ordenados por gravedad y factibilidad) Riesgo 1 — Compromiso de JWT (tokens robados o válidos indebidamente) - STRIDE: Spoofing, Tampering, Information disclosure - Descripción: Tokens de acceso con duración excesiva, sin rotación o revocación, o firmados con algoritmos inseguros permitirían acceso no autorizado a operaciones de facturación. Riesgo 2 — Control de acceso insuficiente en Endpoints REST (privilege escalation / insegura autorización) - STRIDE: Elevation of privilege (parte de Tampering) y Spoofing - Descripción: Endpoints que confían solo en la presencia de un JWT sin comprobar claims (scopes, roles, owner) o que aceptan IDs arbitrarios pueden permitir a usuarios acceder/editar facturas de otros. Riesgo 3 — Subida de PDFs maliciosos / procesamiento inseguro (malware, XXE, PDF exploits) - STRIDE: Tampering, Information disclosure - Descripción: Archivos PDF que contengan payloads maliciosos, scripts incrustados o que desencadenen vulnerabilidades en parsers/convertidores pueden comprometer la plataforma o exponer datos. Riesgo 4 — Webhook forgery y replay (proveedor de pago o actor malicioso emula notificaciones) - STRIDE: Spoofing, Repudiation - Descripción: Webhooks sin verificación de firma/timestamp permiten a atacantes forjar eventos de pago o reintentar eventos antiguos para manipular estados de facturas. Riesgo 5 — Compromiso del Panel de Administración - STRIDE: Elevation of privilege, Tampering, Information disclosure - Descripción: Acceso no autorizado o privilegios excesivos en el panel administrativo pueden permitir la manipulación masiva de datos financieros y anular controles. 3. Controles técnicos concretos por riesgo (detalles aplicables a despliegue) Riesgo 1 — Controles para Compromiso de JWT - Diseño de tokens - Uso de JWT firmados con algoritmo asimétrico (RS256) o con HMAC de alta entropía (HS512) según modelo de claves. [POR VERIFICAR] - No confiar en el campo "alg" enviado por el cliente; forzar validación de algoritmo esperado. - Incluir claims mínimos: iss (issuer), aud (audience), sub (subject), iat (issued at), exp (expiration), jti (JWT ID) para trazabilidad. - Duración y rotación - Tokens de acceso (access tokens) con corta vida (ej., 5–15 minutos) y refresh tokens con caducidad mayor y controlados estrictamente. (Valores exactos deben definirse por política de riesgo). - Implementar rotación de claves de firma (key rotation) con soporte para periodo de transición (clave en uso y clave previa) y uso de KMS/HSM para almacenar claves privadas. - Revocación y control de sesión - Mantener lista de revocación o un sistema de token versioning (p. ej., token_version por usuario) en el backend para invalidar tokens antes del exp. - Registrar jti en un store de sesiones con TTL igual a exp; verificar que jti esté activo al validar JWT. - Almacenamiento y transmisión - No almacenar tokens de larga vida en localStorage del navegador; usar cookies seguras (Secure, HttpOnly, SameSite=strict) para aplicaciones web que requieren protección contra XSS. - Transportar siempre sobre TLS 1.2+; HSTS en el dominio. - Validaciones en servidor - Verificar firma, issuer, audience, exp, nbf, iat y jti en cada petición. - Implementar controles anti-replay si aplica (por ejemplo, limitar uso de jti a una sola validación cuando el flujo lo permita). - Auditoría - Registrar eventos de emisión, uso y revocación del token con: timestamp UTC, actor (sub), jti, endpoint solicitado, origen IP y user-agent. Guardar logs en almacén inmutable/encriptado con retención definida. Riesgo 2 — Controles para control de acceso en Endpoints REST - Validación de Input y Schema - Definir y aplicar JSON Schema para cada endpoint (incluyendo tipos, longitudes, formatos), rechazar payloads que no cumplan. - Validar estrictamente parámetros de path y query; normalizar y sanear IDs antes de usarlos en consultas. - Autorización basada en claims - Implementar autorización por claims: validar que el token sea del resource owner o que el rol permita la acción; usar checks "is_owner(resource_id, sub)" y revisar scopes/roles. - Principio "deny by default" en routes: todas las rutas requieren comprobación explícita de autorización. - Principio de mínimo privilegio y separación de funciones - Roles con permisos mínimos y separación de tareas administrativas (p. ej., crear factura vs. aprobar pago). - Cabeceras y protección HTTP - Requerir TLS y añadir cabeceras: Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Content-Security-Policy (estricta para el panel web), Referrer-Policy. - Rate limiting y protección contra abuso - Endpoints públicos: aplicar rate limiting por IP (ej., 60 req/min) y por cuenta/usuario (ej., 30 req/min); para endpoints de autenticación y cambio de credenciales aplicar límites más estrictos (ej., 10 req/10min) y usar CAPTCHA/step-up auth para intentos repetidos. - Implementar circuit breakers y backoff exponencial en caso de picos. - Validación de backend - Evitar concatenación en consultas a DB; usar queries parametrizadas/prepared statements; sanear entradas para prevenir inyección. - Auditoría y trazabilidad - Loggear intentos de acceso, cambios críticos y respuestas de autorización con datos suficientes para reconstruir la cadena de eventos. Riesgo 3 — Controles para Subida y Procesamiento de PDFs - Rechazo/validación inicial - Validar tamaño máximo (ej., 10 MB o política corporativa), extensión y content-type suministrado por cliente. - Verificar magic numbers (encabezado del archivo) para confirmar que sea un PDF válido (no confiar en Content-Type/extension). - Escaneo y sandboxing - Pasar cada archivo por un escáner antimalware (ClamAV o solución comercial) en un pipeline automatizado antes de almacenarlo accesible. - Procesamiento en un entorno aislado (sandbox o contenedor efímero) cuando se haga parsing o conversión (por ejemplo, extraer texto, convertir a imágenes, extraer metadatos). - Desactivar features peligrosas - Almacenar PDFs sin ejecutar capacidades de scripting o rendering activo; al generar previews, convertir a imágenes rasterizadas o usar un renderer seguro. - Eliminar o sanitizar metadatos incrustados (XMP, metadatos de autor, info GPS) antes de exponer el archivo. - Control de acceso al almacenamiento - Guardar archivos en almacenamiento separado (bucket S3 privado con URLs pre-firmadas de corta duración para descargas), con políticas de acceso limitadas. - Registro y detección - Registrar upload_id, uploader_id, hash (SHA-256), tamaño, resultado de escaneo y destino de almacenamiento. Alertar si el escaneo detecta anomalías. Riesgo 4 — Controles para Webhooks de pago - Firma y verificación - Requerir que el proveedor firme el payload y verificar la firma en el servidor (p. ej., HMAC con shared secret o firma asimétrica). - No confiar en IPs fuente fijas únicamente (pueden cambiar); preferir verificación criptográfica. - Timestamp y tolerancia - Verificar timestamp incluido en el header/payload y aceptar solo dentro de una ventana segura (ej., 5 minutos) para prevenir replay. - Nonce/ID único y deduplicación - Mantener store de eventos recibidos (event_id) con TTL para detectar y rechazar replays o duplicados. - Seguridad del endpoint - Endpoint de webhook debe estar protegido (TLS) y no exponer información sensible en la respuesta. - Manejo de errores y reintentos - Diseñar lógica idempotente: procesar eventos de forma idempotente para soportar reintentos legítimos desde el proveedor. - Auditoría - Registrar raw payloads (encriptados si contienen datos sensibles), headers, firma verificada, origen IP y acción tomada. Riesgo 5 — Controles para Panel de Administración - Acceso y autenticación - MFA obligatorio para todos los usuarios con privilegios administrativos (preferir TOTP + hardware tokens para mayor seguridad). - Reforzar contraseñas: longitud mínima, complejidad, bloqueo tras múltiples fallos y políticas de rotación si requiere cumplimiento. - Reducción de la superficie - Panel en subdominio separado (p. ej., admin.example.com) con controles adicionales (VPN o allowlist de IPs corporativas si aplica), y WAF con reglas específicas. - RBAC y principio de menor privilegio - Implementar RBAC con permisos granulares y separación de funciones; revisar permisos periódicamente. - Sesiones y tiempo de vida - Sesiones administrativas con timeout corto (ej., 15 min de inactividad), y reautenticación para acciones sensibles. - Monitoreo, alertas y alertas de anomalías - Alertas en SIEM para: inicio sesión desde ubicaciones nuevas, cambios masivos, creación/elim. de usuarios, elevación de privilegios. - Auditoría - Registrar todas las acciones administrativas con: actor, timestamp, conjunto de cambios (before/after), IP, user agent. Asegurar integridad de logs. 4. Requisitos de cabeceras HTTP recomendadas (sintético) - Siempre: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload - X-Content-Type-Options: nosniff - X-Frame-Options: DENY - Referrer-Policy: no-referrer-when-downgrade (o más restrictiva según necesidad) - Content-Security-Policy: política mínima para paneles web (evitar inline scripts, use nonce/sha256 cuando necesario) - Expect-CT / Public-Key-Pins debe evaluarse según política (HPKP generalmente desaconsejado) 5. Políticas de Rate Limiting (ejemplos aplicables) - Endpoints públicos sin autenticación: 60 req/min por IP (burst 120), con bloqueos progresivos. - Endpoints autenticados (por usuario): 120 req/min por usuario con fair-share entre sesiones. - Endpoints de autenticación y cambio de credenciales: 10 intentos/10 minutos por IP y por cuenta, con registro/alerta para intentos sobre umbral. - Webhooks: verificar firma; limitar conexiones concurrentes por proveedor; proteger contra flood con token bucket y prioridad para procesado asíncrono. - Panel de administración: restricciones por IP y por usuario; sesiones simultáneas limitadas. 6. Requisitos de Auditoría (mínimos) - Logs de acceso: timestamp UTC (ISO8601), user_id/sub, jti/token_id, endpoint, method, resource_id, response_code, latency, source IP, user-agent, correlacion_id. - Logs de seguridad: eventos de emisión/revocación de token, detecciones de malware en uploads, fallos de validación de webhook, errores de autorización. - Almacenamiento: logs en repositorio inmutable (append-only) preferentemente en sistema WORM o usando firma HMAC por lote; cifrado en reposo (AES-256). - Retención: definir política (ej., logs operativos 90 días, logs de auditoría y seguridad 1 año o por requerimiento legal/regulatorio). [POR VERIFICAR con requisitos locales/PCI] 7. Plan de pruebas de seguridad (Security Test Plan) — Borrador Objetivo: Validar controles técnicos y detectar vulnerabilidades en JWT handling, Endpoints REST, File Upload, Webhooks y Panel de Admin. Componentes y pruebas específicas A. JWT - TC-JWT-01: Validación de firma — enviar token con firma inválida y verificar rechazo. - TC-JWT-02: Algorithim confusion — token con "alg":"none" o alterado; verificar rechazo. - TC-JWT-03: Expiry/revocation — usar token revocado/jti listado y verificar rechazo. - TC-JWT-04: Token replay — test de reuso de jti si se aplica. - Herramientas: Postman, scripts custom; revisar logs. B. Endpoints REST - TC-REST-01: JSON Schema validation — enviar payloads malformados y ver respuesta (400 esperado). - TC-REST-02: Authorization bypass — intentar acceso a recursos de otros usuarios cambiando ID en path. - TC-REST-03: Injection testing — SQL/NoSQL injection fuzzing (specially in query params). - TC-REST-04: Rate limiting — generar carga para validar límites, backoff y throttling. - Herramientas: OWASP ZAP, Burp Intruder, API fuzzers, custom scripts. C. File Upload (PDF) - TC-UP-01: Malware payload — subir PDF con payload conocido (en ambiente controlado) y verificar detección y rechazo. - TC-UP-02: Magic number mismatch — subir .pdf renombrado con contenido que no sea PDF y verificar rechazo. - TC-UP-03: Size and concurrency — test de límites de tamaño y upload simultáneo para DoS. - TC-UP-04: Metadata leakage — revisar que metadatos sean sanitizados al descargar/visualizar. - Herramientas: ClamAV, YARA rules, pdf-fuzzer tools, mutool, qpdf. D. Webhooks - TC-WH-01: Signature verification — enviar webhook falsificado sin firma o con firma errónea; verificar rechazo. - TC-WH-02: Replay — reenvío de webhook antiguo dentro y fuera de la ventana de tolerancia. - TC-WH-03: Idempotency — enviar duplicados y comprobar que el backend procesa idempotentemente. - Herramientas: scripts curl, ngrok para pruebas locales, repro de Stripe/Proveedor en sandbox mode. E. Panel de Administración - TC-ADM-01: MFA bypass — comprobar resistencia ante intentos de MFA bypass (simulación controlada). - TC-ADM-02: RBAC checks — intentar acciones administrativas con rol insuficiente. - TC-ADM-03: Session management — test de fijación/robo de sesión, tiempo de expiración. - TC-ADM-04: UI-level XSS/CSRF — pruebas de inyección en formularios administrativos. - Herramientas: Burp, manual pentesting, SAST for front-end libs. F. Infraestructura y Dependencias - TC-DEP-01: SCA (Software Composition Analysis) — escaneo de dependencias para vulnerabilidades conocidas. - TC-DEP-02: TLS config — revisar con SSL Labs o testssl.sh, requerir TLS1.2+ y cipher suite segura. Plan de ejecución y criterios de aceptación - Entregables por sprint: informes de hallazgos con severidad, PoC (si aplica en ambiente controlado) y recomendaciones. - Criterio de aceptación: 0 hallazgos críticos abiertos; mitigaciones de alto riesgo con plan de corrección implementado y verificado. 8. Vacíos de información (Información requerida para completar verificación) - Implementación concreta del esquema de tokens (algoritmo exacto y almacenamiento de claves). - Políticas de retención de logs y requisitos regulatorios locales (PCI, GDPR) aplicables. - Flow exacto de procesamiento de PDFs (motores/servicios usados) para validar vectores de explotación. - Proveedor(es) de pago (Stripe, PayU, etc.) y sus mecanismos de firma de webhook (ej., HMAC vs. firma asimétrica). - Diseño del panel administrativo (¿subdominio separado?, ¿IP allowlist?). Discusión ====== Interpretación técnica Las amenazas identificadas y las mitigaciones propuestas corresponden a controles de defensa en profundidad: endurecimiento de tokens, comprobaciones de autorización a nivel de negocio, control y saneamiento de uploads, autenticación fuerte para administradores y verificación criptográfica para webhooks. La ausencia de verificación criptográfica y de rotación/revocación de tokens son vectores de impacto muy alto en entornos financieros. Recomendaciones de priorización inmediata 1. Implementar validación estricta de JWT (firma, issuer, audience, revocación) y clave en KMS — mitigación de riesgo 1. 2. Añadir controles de autorización por claims en endpoints críticos y avanzar RBAC — mitigación de riesgo 2. 3. Pipeline de escaneo y sandboxing para uploads y convertir previews a imágenes — mitigación de riesgo 3. 4. Verificación de firmas y ventana temporal en webhooks, y registro de event_id — mitigación de riesgo 4. 5. MFA obligatorio, revisión de roles y aislamiento de panel admin (red) — mitigación de riesgo 5. Control de calidad y revisión ====== Antes de entregar la versión final se debe verificar lo siguiente: - Todas las afirmaciones críticas deben contar con al menos una referencia verificable (OWASP, RFC 7519, guías del proveedor de pagos). Actualmente varias entradas están marcadas como [POR VERIFICAR]. - Cada caso de prueba en el Plan de Pruebas debe estar asociado a un entorno de staging con credenciales y una checklist de seguridad para evitar generar efectos en producción. - Los logs y evidencias de las pruebas deben archivarse en repositorio seguro con control de accesos y correlación_id para trazabilidad. Visualizaciones (Mermaid) ====== 📌 Diagramas conceptuales del sistema (arquitectura y cronograma). Los diagramas son conceptuales y sirven para facilitar la lectura del threat model; no contienen datos sensibles ni métricas inventadas. Arquitectura — Flujo de componentes ```mermaid %%{init: {'theme': 'base'}}%% flowchart LR subgraph C1[Usuarios y Sistemas Externos] U[Usuario / Aplicación Cliente] PAY[Proveedor de Pago (Webhook)] end subgraph C2[API Layer] API[API REST de Facturación] AUTH[Auth Service (JWT)] UP[Upload Service (PDF)] WH[Webhook Receiver] ADMIN[Panel de Administración] end subgraph C3[Storage & Infra] DB[(Base de Datos — Facturas)] BUCK[(Object Storage — PDFs)] LOGS[(SIEM / Logs Inmutables)] KMS[(KMS / HSM)] end U -->|HTTPS (TLS)| API API -->|Auth checks / token validation| AUTH API -->|Store / Read| DB U -->|Upload PDF| UP UP -->|Store object + scan| BUCK UP -->|scan results| LOGS PAY -->|POST webhook (signed)| WH WH -->|verify signature + dedupe| API ADMIN -->|MFA + RBAC| API AUTH -->|sign/verify keys| KMS API -->|audit events| LOGS DB -->|backup / retention| LOGS ``` Interpretación: El diagrama muestra las interacciones principales: clientes usan la API protegida por Auth Service que valida JWT con claves en KMS; uploads van al servicio de archivos que escanea y almacena en bucket privado; webhooks llegan al receptor y son verificados antes de afectar el estado de facturas; el panel admin realiza acciones con MFA/RBAC; logs centralizados capturan eventos para auditoría. Cronograma — Plan maestro (Gantt simplificado) ```mermaid %%{init: {'theme': 'base'}}%% gantt title Cronograma maestro — Plan de Investigación (resumen) dateFormat YYYY-MM-DD section Aclaracif3n Aclaracif3n y alcance :a1, 2026-08-03, 7d section Preparacif3n Recoleccif3n de artefactos :a2, after a1, 7d Revisiones este1ticas y SCA :a3, after a2, 7d section Ejecucif3n Pruebas dine1micas / Pentest :a4, after a3, 14d Analisis y plan de remediacif3n :a5, after a4, 7d Verificacif3n final y cierre :a6, after a5, 7d ``` Interpretacif3n: Gantt muestra la secuencia de Fases 0–5 definidas en el Plan de Investigacif3n. Fechas y duraciones son orientativas y deben ajustarse tras la aprobacif3n del sponsor. Siguientes pasos inmediatos ====== 1. Responder el bloque de preguntas A) aclaratorias o indicar "usar supuestos estándar" dentro de 72 horas. 2. Proveer accesos de staging (credenciales en vault, claves pfablicas de proveedor de pago, endpoint de webhook de sandbox) para iniciar Fase 1. 3. Ejecutar SCA/SAST en paralelo mientras se obtienen accesos para acelerar el cronograma. Referencias (a completar) ====== NOTA: El acceso a búsquedas web automatizadas estuvo temporalmente limitado durante la generación de este borrador. Se listan a continuación las referencias y documentos que se deben consultar y citar formalmente en la versión final del informe: - OWASP API Security Top 10 (documento oficial) — para validación de amenazas y controles. [POR VERIFICAR] - RFC 7519 — JSON Web Token (JWT) specification. [POR VERIFICAR] - Guías del proveedor de pago (Stripe, Adyen, PayU, etc.) sobre verificación de webhooks y manejo seguro de pagos. [POR VERIFICAR] - PCI DSS (Payment Card Industry Data Security Standard) — requisitos aplicables si se maneja data de pago. [POR VERIFICAR] - NIST SP 800-series relevantes (por ejemplo, SP 800-63 para autenticación digital) — para políticas de autenticación. [POR VERIFICAR] - Herramientas y guías para protección de file upload (ClamAV, YARA, mutool, qpdf) y prácticas de sandboxing. [POR VERIFICAR] Anexos ====== A. Checklist resumido de acciones inmediatas (prioridad 30 días) - Forzar validación de JWT en todos los endpoints; desplegar mecanismo de revocación. - Implementar verificación de firma para webhooks y deduplicación por event_id. - Activar escaneo antimalware para uploads y sandbox de procesamiento. - Habilitar MFA para todos los usuarios con privilegios administrativos. - Definir y aplicar políticas de rate limiting para endpoints críticos. B. Plantilla mínima de log para auditoría (ejemplo JSON) { "timestamp": "2026-08-03T12:00:00Z", "event": "auth_token_used", "user_id": "", "jti": "", "endpoint": "", "method": "", "resource_id": "", "ip": "", "user_agent": "", "outcome": "success|failure", "correlation_id": "" }