whmcs-vpsmanager/AUDIT.md

Auditoría de la primera entrega

Fecha: 2026-09-19. Base: ZIP del módulo facilitado por el titular. Se extrajo en un área de trabajo separada y se construyó este árbol sin copiar ningún historial Git.

Revisión de secretos

No se encontraron credenciales reales literales en el código aportado: las contraseñas se leían de los custom fields en ejecución. Sí se encontraron URLs de infraestructura hardcodeadas y un flujo que introducía credenciales de panel en HTML/JavaScript.

• Se eliminaron las URLs de producción del módulo y de lib/VPSManager.php.
• Se extrajeron API, Graphite y vista completa de gráficas a configuración externa.
• Los dos bloques de autologin (cliente/administración) desaparecieron.
• Se eliminaron siete bloques try/catch vacíos cuyo logModuleCall habría registrado $params, mensajes y trazas completos. No se conserva un logger de credenciales.
• Se habilitó CURLOPT_RETURNTRANSFER en las llamadas heredadas que volcaban respuestas al navegador. No se expone el cuerpo de la API a HTML.
• El ejemplo de configuración está vacío; no existe configuración real en el árbol.
• .gitignore excluye configuración, entornos, backups, logs, dumps y archivos comprimidos.

gitleaks no estaba instalado. Se utilizó tools/audit.py, revisión manual de coincidencias y comparación del módulo saneado con el original, además de inventario de archivos. El análisis cubre:

1. password, passwd, secret, token, api_key, apikey, Authorization:, cookies y marcadores BEGIN PRIVATE KEY / BEGIN RSA PRIVATE KEY.
2. Valores de credencial literales, formatos conocidos de tokens, claves privadas y credenciales embebidas en URLs.
3. IPs privadas y literales de alta entropía, revisados con contexto.
4. .env, configuración privada, claves SSH, certificados privados, SQL, logs, backups, swap, ZIP/tar y binarios no revisados.
5. Dependencias locales contrastadas por SHA-256; la descarga original Chart.js 4.4.8 se verificó contra el SHA-512 de integridad publicado en el registro NPM y se conserva su licencia MIT. El wrapper de aislamiento se genera mediante un script legible.
6. Mismo análisis antes de git init, sobre el índice y sobre los blobs de HEAD.

Las coincidencias legítimas son nombres de opciones/variables, documentación de seguridad, el token CSRF de WHMCS, patrones del propio escáner y sentinelas ficticios FAKE_ del test. Las URLs user:pass@…example.invalid son fixtures negativos que deben rechazarse. No se detectaron secretos reales en el árbol auditado. Esto describe los resultados de las comprobaciones realizadas, no una garantía matemática del escáner.

Pruebas realizadas

• PHP 8.1.2 (paquete Ubuntu con actualizaciones): php -n -l en todos los PHP, sin errores.
• php -n tests/run.php: 158 aserciones PASS, HTTP simulado, sin acceso a producción.
• node tests/frontend.cjs: 24 aserciones PASS.
• node --check assets/metrics.js: PASS.
• Revisión visual en navegador local: las tres gráficas, unidades y cortes en los huecos.
• Configuración: fichero válido, inexistente, sintaxis errónea, tipo erróneo, clave ausente y URL inválida; rechazos de esquemas inseguros y credenciales en URL.
• Graphite: HTTP 500, timeout, JSON inválido, respuesta demasiado grande, series ausentes, respuesta parcial, puntos inválidos, timestamps duplicados/desalineados y null.
• Validación: UUID válido y malicioso, tipos no LX y whitelist de cinco rangos.
• Memoria del fixture: 8589934592 bytes = 8 GiB, usada 4365361152 bytes, porcentaje 50.81949234008789 %. No se presupone una capacidad fija.
• Red: tasas mantenidas en bytes/s en PHP y multiplicadas por 8 solo al presentar.
• Autorización en el límite del módulo: GET/POST hostiles no cambian el UUID/tipo del servicio resuelto por WHMCS; los enlaces usan su serviceid, no el id solicitado.
• Regresión con dobles: reinicio/parada/arranque, firewall, lista/restauración de snapshots, suspensión/reactivación, cancelación y selectores conservan rutas/payloads esperados.

Límites y decisiones de despliegue

No se ha accedido a una instalación WHMCS ni a un servicio VPS de producción. La regresión anterior prueba contratos mediante mocks, no efectos reales de provisioning. Quedan por verificar en staging la versión/plantilla instalada, autorización efectiva entre dos clientes, campos solo de administrador, CSRF del dispatcher y política CSP.

La vista completa Graphs conserva el botón, pero requiere configuración y confirmación de que su servicio externo autentica/autoriza; no se ha validado su seguridad real. El autologin ISPConfig se sustituye por login manual. SSO seguro y licencia global siguen pendientes. Los avisos de copyright y licencia de componentes ajenos se conservan.

No se ha modificado la semántica heredada de éxito/error de suspensión/reactivación. La API heredada puede anunciar éxito sin comprobar HTTP; la mejora de ese contrato queda fuera de esta intervención para evitar una reescritura del provisioning.

Actualización: autenticación HTTP Basic de Graphite

Se añade graphite_auth (none/basic), graphite_username y graphite_password, únicamente en configuración privada. cURL envía las credenciales por HTTPS; no se añaden a URLs ni a la estructura devuelta al frontend. Configuraciones incompletas o inválidas se rechazan antes de realizar la petición. No se siguen redirecciones ni hay fallback anónimo al usar Basic. Las respuestas 401/403 conservan el error discreto del área de cliente.

Validación tras esta actualización: 192 aserciones PHP y 24 frontend, lint de todos los PHP, diff check y auditoría del árbol. Las nuevas credenciales de prueba son sentinelas FAKE_. Se incluye una guía para Apache 2.4. No se han configurado ni verificado el VirtualHost ni la autenticación del servidor Graphite real; el cambio del cliente no bloquea acceso público.