# Propuesta de PenTest con herramientas Docker

## Objetivo

Definir un plan de acción reproducible para realizar pruebas de seguridad sobre el proyecto PHP/PHPMaker, usando herramientas ejecutables en Docker y generando evidencia técnica para revisión del cliente.

Esta propuesta no ejecuta pruebas todavía. Su objetivo es ordenar alcance, herramientas, fases y entregables antes de iniciar el PenTest.

## Alcance inicial recomendado

Antes de ejecutar herramientas, se debe confirmar:

- URL local o staging a evaluar.
- Credenciales de prueba por rol:
  - usuario normal;
  - usuario administrador;
  - usuario con permisos limitados.
- Módulos críticos:
  - login y logout;
  - gestión de usuarios;
  - cargas de archivos;
  - reportes y exportaciones Excel/PDF;
  - endpoints API;
  - formularios generados por PHPMaker.
- Exclusiones:
  - ambiente productivo, salvo autorización explícita;
  - pruebas destructivas;
  - fuerza bruta real;
  - eliminación o modificación masiva de datos.

## Estructura sugerida de reportes

```text
pruebas/security/pentest/
  00-alcance.md
  01-reconocimiento/
  02-dependencias/
  03-sast/
  04-dast/
  05-auth-session/
  06-inyecciones/
  07-headers-tls/
  08-resumen-ejecutivo.md
  09-hallazgos.md
  10-evidencia-tecnica.md
  11-plan-remediacion.md
```

## Herramientas Docker recomendadas

### 1. Dependencias y supply chain

#### Composer audit

- Imagen sugerida: `composer:2`
- Uso:
  - revisar `api/composer.lock`;
  - revisar `mgmt/composer.lock`;
  - detectar CVEs en librerías PHP.

#### Trivy

- Imagen sugerida: `aquasec/trivy`
- Uso:
  - vulnerabilidades en dependencias;
  - vulnerabilidades en imágenes Docker;
  - detección básica de secretos;
  - revisión de configuraciones inseguras.

#### Grype

- Imagen sugerida: `anchore/grype`
- Uso:
  - segunda opinión sobre vulnerabilidades de dependencias e imágenes;
  - contraste contra resultados de Trivy.

#### Gitleaks

- Imagen sugerida: `zricethezav/gitleaks`
- Uso:
  - detección de contraseñas;
  - tokens;
  - secretos en `.env`;
  - credenciales hardcodeadas;
  - secretos en historial Git.

### 2. SAST para PHP

#### Semgrep

- Imagen sugerida: `semgrep/semgrep`
- Reglas recomendadas:
  - PHP;
  - OWASP Top 10;
  - JWT/session;
  - SQL injection;
  - XSS;
  - hardcoded secrets.

Nota: en código generado por PHPMaker puede producir muchos falsos positivos. Conviene acotar rutas y reglas para reducir ruido.

#### Progpilot

- Imagen: contenedor propio basado en PHP/Composer o imagen comunitaria validada antes de usar.
- Uso:
  - análisis de flujo de datos en PHP;
  - SQL injection;
  - XSS;
  - command injection;
  - path traversal;
  - manejo inseguro de archivos.

#### PHPStan / Psalm

- Imagen sugerida para PHPStan: `phpstan/phpstan`
- Uso:
  - errores de tipos;
  - llamadas inválidas;
  - código muerto;
  - fallas en código custom agregado sobre PHPMaker.

No son herramientas de PenTest puro, pero ayudan a detectar errores que pueden derivar en fallas de seguridad.

### 3. DAST contra la aplicación corriendo

#### OWASP ZAP

- Imagen sugerida: `ghcr.io/zaproxy/zaproxy:stable`
- Uso:
  - baseline scan sin autenticación;
  - full scan en staging;
  - authenticated scan con usuario de prueba;
  - revisión de headers, cookies, formularios y hallazgos web comunes.

ZAP debería ser la herramienta principal para pruebas dinámicas.

#### Nuclei

- Imagen sugerida: `projectdiscovery/nuclei`
- Uso:
  - CVEs conocidos;
  - paneles expuestos;
  - configuraciones inseguras;
  - tecnologías detectables;
  - headers;
  - exposiciones comunes.

#### Nikto

- Imagen sugerida: `sullo/nikto`
- Uso:
  - archivos peligrosos;
  - rutas comunes;
  - versiones expuestas;
  - headers;
  - configuraciones débiles de servidor web.

### 4. Pruebas específicas de ataque

#### SQLMap

- Imagen sugerida: `sqlmapproject/sqlmap`
- Uso:
  - pruebas controladas de SQL injection;
  - validación sobre endpoints autorizados;
  - pruebas solo en staging o base de datos de prueba.

Debe usarse con cuidado para evitar pruebas destructivas o carga excesiva.

#### ffuf

- Imagen sugerida: `ghcr.io/ffuf/ffuf`
- Uso:
  - discovery de rutas;
  - archivos backup;
  - endpoints API;
  - directorios expuestos.

Rutas típicas a revisar:

```text
/backup
/old
/test
/phpinfo.php
/.env
/vendor/
/uploads/
```

### 5. TLS y headers

#### testssl.sh

- Imagen sugerida: `drwetter/testssl.sh`
- Uso:
  - protocolos TLS débiles;
  - certificados;
  - ciphers inseguros;
  - HSTS;
  - configuración HTTPS.

Aplica principalmente si existe ambiente HTTPS de staging o producción autorizada.

## Flujo recomendado

### Fase 1: Inventario

Objetivo: conocer exactamente qué se va a evaluar.

Actividades:

- detectar versión PHP;
- detectar librerías Composer;
- identificar rutas públicas;
- identificar endpoints API;
- identificar formularios críticos;
- identificar cargas de archivos;
- identificar roles y permisos.

Resultado esperado:

```text
pruebas/security/pentest/01-reconocimiento/inventario.md
```

### Fase 2: Seguridad estática

Herramientas:

- Composer audit;
- Trivy;
- Grype;
- Gitleaks;
- Semgrep;
- Progpilot;
- PHPStan/Psalm opcional.

Objetivo:

- detectar vulnerabilidades en dependencias;
- encontrar secretos accidentales;
- detectar patrones inseguros en código custom;
- encontrar posibles inyecciones;
- revisar manejo de archivos y sesiones.

### Fase 3: DAST sin autenticación

Herramientas:

- OWASP ZAP baseline;
- Nuclei;
- Nikto;
- ffuf.

Objetivo:

- identificar rutas públicas;
- revisar headers;
- detectar exposición accidental;
- buscar archivos sensibles;
- obtener fingerprinting básico.

### Fase 4: DAST autenticado

Herramienta principal:

- OWASP ZAP authenticated scan.

Validaciones importantes:

- control de acceso por rol;
- IDOR;
- acceso directo a registros ajenos;
- CSRF;
- sesión y cookies;
- logout efectivo;
- formularios con parámetros manipulables;
- exportaciones Excel/PDF.

### Fase 5: Pruebas manuales dirigidas

Las herramientas automáticas no reemplazan la revisión manual. Para este proyecto se recomienda probar:

- cambio manual de IDs en URLs;
- acceso a registros de otros usuarios;
- manipulación de filtros;
- modificación de campos hidden;
- carga de archivos peligrosos;
- XSS almacenado y reflejado en campos visibles;
- impacto de datos maliciosos en exportaciones Excel/PDF;
- reset o cambio de contraseña;
- permisos en endpoints API.

## Docker Compose sugerido

Se recomienda crear un archivo dedicado:

```text
docker-compose.pentest.yml
```

Servicios sugeridos:

```text
zap
nuclei
nikto
sqlmap
ffuf
trivy
grype
gitleaks
semgrep
testssl
```

Montajes recomendados:

```text
./:/workspace:ro
./pruebas/security/pentest:/reports
```

Reglas:

- montar el código en solo lectura;
- escribir únicamente en la carpeta de reportes;
- usar una variable `TARGET_URL` para apuntar al ambiente autorizado;
- no ejecutar pruebas destructivas sin autorización explícita.

## Stack mínimo recomendado

Para una primera etapa defendible ante cliente, se recomienda iniciar con:

```text
composer:2
aquasec/trivy
zricethezav/gitleaks
semgrep/semgrep
projectdiscovery/nuclei
sullo/nikto
sqlmapproject/sqlmap
drwetter/testssl.sh
```

PHPStan, Psalm y Progpilot pueden agregarse como segunda etapa si los primeros reportes muestran mucho código custom sensible o hallazgos que requieran análisis más profundo.

## Entregables para el cliente

Documentos sugeridos:

```text
pruebas/security/pentest/00-alcance.md
pruebas/security/pentest/08-resumen-ejecutivo.md
pruebas/security/pentest/09-hallazgos.md
pruebas/security/pentest/10-evidencia-tecnica.md
pruebas/security/pentest/11-plan-remediacion.md
```

Cada hallazgo debe incluir:

- descripción;
- impacto;
- evidencia;
- endpoint o módulo afectado;
- severidad;
- recomendación;
- estado: abierto, mitigado, falso positivo o aceptado.

## Criterio de severidad

Los hallazgos deben clasificarse como:

- Crítico;
- Alto;
- Medio;
- Bajo;
- Informativo.

Se recomienda priorizar primero:

1. exposición de secretos;
2. acceso no autorizado;
3. SQL injection;
4. XSS almacenado;
5. carga insegura de archivos;
6. dependencias con CVEs críticas o altas;
7. fallas de sesión/cookies;
8. headers y hardening.

## Recomendación final

El PenTest debe comenzar con alcance y evidencia, no con ejecución indiscriminada de herramientas. Para este proyecto, el valor principal estará en combinar:

- revisión de dependencias;
- SAST acotado para PHP;
- DAST con OWASP ZAP;
- pruebas autenticadas por rol;
- revisión manual de permisos, IDs, formularios, uploads y exportaciones.

Esto permite entregar al cliente un reporte defendible, reproducible y útil para remediación, en lugar de una lista ruidosa de falsos positivos.