Así es nuestro informe de evaluación
Un extracto ilustrativo y redactado del entregable que recibe al final de un proyecto. Cada hallazgo de abajo es sintético y corresponde a un objetivo ficticio: aquí no aparecen datos reales de clientes.
- Proyecto
- Test de penetración de aplicación web y API
- Objetivo
- Acme Cloud Platform (ilustrativo)
- Ventana de evaluación
- Un proyecto de dos semanas (relativo, sin fechas fijas)
- Clasificación
- Confidencial (muestra ilustrativa)
- Versión del informe
- Muestra v1.0
Resumen ejecutivo
Vexaro evaluó la aplicación web accesible desde el exterior y la API que la soporta de Acme Cloud Platform a lo largo de un proyecto grey-box de dos semanas. Las pruebas siguieron la OWASP Web Security Testing Guide y se verificaron manualmente más allá de las herramientas automatizadas.
Postura de riesgo global: elevada. La aplicación aplica correctamente la autenticación y la seguridad del transporte, pero la autorización a nivel de objeto se aplica de forma inconsistente. Dos hallazgos son explotables por separado: una referencia directa a objetos insegura (IDOR) en la API de facturación y una falsificación de peticiones del lado del servidor (SSRF) en la función de importación de documentos. Encadenados, permitirían a un usuario autenticado con pocos privilegios leer las facturas de otros inquilinos y alcanzar los metadatos internos de la nube. Reforzar la capa de control de acceso y restringir las peticiones salientes mitiga la mayor parte del riesgo residual.
8 hallazgos puntuados con CVSS 3.1
Alcance y metodología
El proyecto abarcó la aplicación web en producción, su API REST, la cuenta de nube que las aloja y el perímetro de red accesible desde el exterior. Las pruebas se realizaron en un tiempo acotado, desde una cuenta autenticada con pocos privilegios y desde una línea base no autenticada.
- Aplicación web: app.acme.example (flujos autenticados y anónimos)
- API REST: api.acme.example (endpoints v1 y v2)
- Cuenta de nube: almacenamiento de objetos, metadatos de cómputo y revisión de IAM
- Perímetro de red externo: servicios expuestos y configuración de TLS
- Denegación de servicio y pruebas de carga volumétrica
- Ingeniería social y acceso físico
- SaaS de terceros no operado por el objetivo
Metodología y referencias
Las pruebas fueron principalmente manuales y se alinearon con marcos reconocidos del sector, de modo que los hallazgos sean reproducibles y la cobertura, auditable.
Web Security Testing Guide: los casos de prueba que guían la cobertura de la aplicación.
Application Security Verification Standard: la base de verificación a nivel de controles.
Tácticas y técnicas de los adversarios para enmarcar rutas de ataque realistas.
Penetration Testing Execution Standard: el proceso general del proyecto.
Cada hallazgo se puntúa con CVSS 3.1 y se traduce en una calificación de riesgo de negocio. La severidad refleja la explotabilidad y el impacto en el contexto de este entorno, no solo la puntuación base.
Hallazgos
Ocho hallazgos representativos del proyecto, ordenados por severidad. El primero se desarrolla por completo abajo para mostrar el nivel de detalle de cada entrada del informe.
| ID | Hallazgo | Severidad | CVSS | Estado |
|---|---|---|---|---|
| ACME-2024-001 | IDOR en la API de facturación expone facturas de otros inquilinos | Alta | 8.1 | Abierto |
| ACME-2024-002 | Server-side request forgery en la importación de documentos | Alta | 7.7 | Abierto |
| ACME-2024-003 | Autorización a nivel de función rota en endpoints de administración | Media | 6.5 | Corregido y reevaluado |
| ACME-2024-004 | Stored XSS en el campo de asunto del ticket de soporte | Media | 5.4 | Abierto |
| ACME-2024-005 | Política de contraseñas débil permite credenciales triviales | Baja | 3.7 | Abierto |
| ACME-2024-006 | Errores detallados de la API filtran trazas de pila y versiones de librerías | Baja | 3.1 | Riesgo aceptado |
| ACME-2024-007 | Faltan cabeceras de seguridad (HSTS, CSP, frame-ancestors) | Info | 2.4 | Corregido y reevaluado |
| ACME-2024-008 | Cookie de sesión emitida sin el atributo Secure | Info | 2.0 | Abierto |
Hallazgo de muestra en detalle completo
Un hallazgo, desarrollado con la profundidad que recibe cada entrada en un informe real: descripción, impacto, evidencia, reproducción, remediación y referencias.
IDOR en la API de facturación expone facturas de otros inquilinos
- ID del hallazgo
- ACME-2024-001
- CVSS 3.1
- 8.1 (Alta)
- Vector
- AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
- CWE
- CWE-639: Authorization Bypass Through User-Controlled Key
Descripción
La API de facturación devuelve documentos de factura mediante un identificador numérico secuencial que se envía en la ruta de la petición. El endpoint autentica a quien llama, pero nunca comprueba que la factura solicitada pertenezca a su inquilino. Por tanto, cualquier usuario autenticado puede enumerar el identificador y recuperar facturas de otras organizaciones, incluidos nombres de contactos de facturación, importes y líneas de detalle.
Impacto
Se trata de una brecha de confidencialidad entre inquilinos. Un usuario autenticado con pocos privilegios de cualquier inquilino puede leer los registros financieros de todos los demás inquilinos incrementando un único número entero. Los datos expuestos incluyen condiciones comerciales y datos de contacto personales, lo que crea tanto una exposición de privacidad como de inteligencia competitiva. Como los identificadores son secuenciales, todo el corpus de facturas puede extraerse de forma programática en minutos.
Evidencia
Petición y respuesta ilustrativas. El host, el token y los valores son sintéticos y se han ocultado.
GET /v2/invoices/10428 HTTP/1.1
Host: api.acme.example
Authorization: Bearer eyJhbGciOi...REDACTED.SAMPLE.TOKEN
Accept: application/jsonHTTP/1.1 200 OK
Content-Type: application/json
{
"invoice_id": 10428,
"tenant_id": 3304,
"bill_to": "[REDACTED], Northwind Trading",
"amount_due": "14,920.00 USD",
"status": "unpaid"
}'Pasos para reproducir
- 1Autentíquese en la aplicación con cualquier cuenta válida de pocos privilegios y capture el token bearer.
- 2Solicite su propia factura, p. ej. GET /v2/invoices/10427, y confirme una respuesta 200.
- 3Reduzca o aumente el identificador numérico (.../10428, .../10429) y reenvíe la petición con su propio token.
- 4Observe que se devuelven facturas con otros valores de tenant_id, lo que confirma la falta de comprobación de autorización a nivel de objeto.
Remediación
Aplique autorización a nivel de objeto en cada petición: resuelva la factura y luego confirme que su tenant_id coincide con el del principal autenticado antes de devolver cualquier dato; de lo contrario, responda 404. Aplique la comprobación de forma centralizada (por ejemplo, en una capa de políticas o en el alcance de la consulta) en lugar de en cada handler, y añada una prueba de regresión que verifique que se rechaza una petición entre inquilinos. Sustituir los identificadores secuenciales por otros no adivinables reduce la enumeración, pero es defensa en profundidad, no un sustituto de la comprobación de autorización.