Cómo escribir un buen informe de pentest

#Qué es un informe de pentest

Un informe de pentest es el registro escrito de una prueba de seguridad autorizada. Dice qué se probó, qué se encontró, cómo puede confirmar un lector cada hallazgo y qué hay que cambiar. La prueba termina cuando el evaluador deja de enviar solicitudes. El informe es lo que conserva el dueño del sistema, lo que comparte con los desarrolladores y lo que usa para demostrar que el trabajo se mantuvo dentro del alcance acordado.

El NIST SP 800-115, guía técnica sobre pruebas y evaluaciones de seguridad de la información, cubre el proceso completo, incluido el análisis de los hallazgos y el desarrollo de estrategias de mitigación. La Web Security Testing Guide de OWASP tiene un capítulo de Reporting que empieza por la estructura del informe y por un esquema de nombres para los hallazgos. Lea ambos cuando pueda. Este artículo se centra en la parte que escribirá primero: un informe claro con un hallazgo que otra persona pueda reproducir.

#Por qué importa el informe

Un error real que nadie puede reproducir casi nunca se corrige. Los desarrolladores necesitan pasos que puedan ejecutar desde un estado limpio. Los gerentes necesitan saber qué significa el riesgo para el negocio. Los auditores necesitan pruebas de que el trabajo respetó la autorización. Un solo documento tiene que servir a los tres lectores.

El informe también protege a quien prueba. Un alcance escrito y un registro fechado de lo que se probó muestran que cada acción estuvo dentro de la autorización. Sin ese registro, un evaluador que encontró una falla real puede terminar discutiendo si la prueba estaba permitida.

#Las secciones de un informe

Una estructura práctica tiene seis partes:

• Resumen ejecutivo. Una o dos páginas para quien no va a leer el resto. Dice qué se probó, el riesgo general, los hallazgos más importantes en lenguaje sencillo y las primeras acciones. Escríbalo al final, aunque aparezca primero.
• Alcance y autorización. Los hosts, URL y cuentas que estaban dentro del alcance, lo que quedó excluido, las fechas de la prueba, quién autorizó el trabajo y cualquier límite, como no hacer pruebas de denegación de servicio.
• Metodología. El enfoque y las herramientas, con sus versiones, con suficiente detalle para que alguien pueda repetir el trabajo. Indique qué verificaciones fueron manuales.
• Hallazgos. Una entrada por problema, ordenada por severidad. Cada entrada usa la misma plantilla.
• Remediación. Las correcciones agrupadas por responsable o tema, con prioridades. Cada corrección incluye una forma de comprobar que funciona.
• Apéndice. Evidencia en bruto sin secretos, capturas completas de solicitudes y respuestas, y un glosario para los términos que el público puede no conocer.

#Cómo escribir un hallazgo

Cada hallazgo responde a las mismas preguntas, en el mismo orden.

• Título. Dice cuál es la falla y dónde está. "Cross-site scripting reflejado en el parámetro de búsqueda" informa más que "vulnerabilidad XSS". El artículo sobre cross-site scripting explica la clase de falla detrás de ese ejemplo.
• Activo afectado. La URL exacta, el endpoint, el parámetro, el componente o la versión.
• Pasos para reproducir. Pasos numerados que un desconocido pueda seguir desde una sesión limpia del navegador. Incluya la solicitud exacta siempre que un paso dependa de ella.
• Evidencia. La prueba de que los pasos funcionaron: una captura de pantalla o la salida de curl -i, sin secretos. Numere cada evidencia para que los pasos puedan señalarla.
• Impacto. Lo que un atacante podría hacer en las condiciones que usted verificó.
• Severidad. Un vector CVSS v4.0 y su calificación, calculados a partir de lo que verificó.
• Remediación. Una corrección específica y una comprobación que demuestre que funciona.

Un hallazgo que el lector no puede reproducir solo con la página no está terminado, por bueno que sea su título.

#Describa el impacto sin exagerar

El impacto sigue a la evidencia. Si demostró que un script se ejecutó en el navegador de una cuenta de prueba en su propio laboratorio, escriba exactamente eso. Una frase como "un atacante puede tomar todas las cuentas" sin una demostración es una exageración, y un desarrollador lo notará. Además, le quita credibilidad en el siguiente hallazgo. Cuando no verificó algo, dígalo y nombre la prueba que lo confirmaría.

#La salida de un scanner es una pista, no un hallazgo

El resultado de un scanner le dice dónde mirar. Antes de que entre al informe, reprodúzcalo a mano, registre la solicitud y la respuesta y confirme el comportamiento usted mismo. Puede citar el scanner como origen de la pista. No pegue su salida en bruto como prueba, porque puede estar equivocada y el lector no sabe qué partes alguien revisó.

#Calcule la severidad con CVSS v4.0

La especificación de CVSS v4.0 define un grupo de métricas Base con dos lados. Las métricas de explotabilidad son el vector de ataque (AV), la complejidad del ataque (AC), los requisitos de ataque (AT), los privilegios requeridos (PR) y la interacción del usuario (UI). Las métricas de impacto cubren el sistema vulnerable (VC, VI, VA) y los sistemas subsecuentes (SC, SI, SA). Una cadena de vector empieza con CVSS:4.0 y enumera todas las métricas base.

Las bandas cualitativas de severidad son None en 0.0, Low de 0.1 a 3.9, Medium de 4.0 a 6.9, High de 7.0 a 8.9 y Critical de 9.0 a 10.0.

La puntuación tiene cuatro variantes según los grupos de métricas usados: CVSS-B solo con Base, CVSS-BT con Base y Threat, CVSS-BE con Base y Environmental, CVSS-BTE con los tres. Un primer informe suele llevar solo la puntuación Base, así que etiquétela como CVSS-B y no la presente como una evaluación completa del riesgo.

Use la calculadora oficial en https://www.first.org/cvss/calculator/4.0 para construir el vector y obtener la puntuación. Incluya el vector en el informe, no solo el número, para que el lector vea qué supuestos usó. La cadena siguiente muestra solo el formato. No es la puntuación de ningún hallazgo de su laboratorio:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Puntúe lo que verificó. Si el ataque depende de una condición que no pudo reproducir, la métrica tiene que reflejarlo.

#Quite los secretos antes de compartir

La evidencia suele contener cookies de sesión, tokens bearer, contraseñas y datos personales. Elimínelos antes de que el archivo salga de su equipo. Mantenga el nombre de la cabecera y la forma del valor, para que el lector pueda seguir la solicitud:

Cookie: session=<REDACTED>
Authorization: Bearer <REDACTED>

No pegue un token activo en un chat, un ticket o un repositorio público, y no haga commit de un archivo que todavía lo contenga. Si un secreto quedó expuesto en su propio laboratorio, rótelo de todos modos y anote la rotación en el informe.

#Manos a la obra: un hallazgo de su laboratorio Juice Shop

Necesita el contenedor de OWASP Juice Shop de su laboratorio, ejecutándose en su propia máquina. Este ejercicio solo toca esa instancia local en 127.0.0.1. No ejecute ninguno de estos pasos contra un sitio que no sea suyo ni para el que no tenga permiso escrito de prueba.

#1. Confirme que el laboratorio es local

Ejecute:

docker ps

Mire la columna de puertos. El mapeo debería empezar con 127.0.0.1, lo que significa que solo su máquina puede llegar al servicio. Si ve 0.0.0.0 o ninguna dirección, detenga el contenedor y vuelva a iniciarlo con la dirección de loopback en el parámetro de publicación.

docker run -d -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Luego compruebe que el laboratorio responde:

curl -i http://127.0.0.1:3000

La línea de estado debería mostrar un código de respuesta exitoso. Guarde la salida. Va en la sección de Alcance como prueba del objetivo que probó.

#2. Elija un problema que pueda reproducir

Escoja un comportamiento que haya probado en el navegador o con una sola solicitud, y que pueda describir en unos pocos pasos. Mantenga el alcance pequeño. Un hallazgo bien respaldado es más útil que ocho sin verificar.

#3. Capture la evidencia

Repita la solicitud con curl -i para que se vean las cabeceras. Cambie la ruta por la que usa su hallazgo y guarde la salida en un archivo:

curl -i "http://127.0.0.1:3000/<ruta-probada>" > evidence-01.txt

El flag -i imprime las cabeceras de la respuesta antes del cuerpo. Lea la línea de estado, la cabecera Content-Type y cualquier cabecera de la que dependa su hallazgo. Después quite cualquier token o cookie del archivo antes de hacer commit.

#4. Complete la plantilla

Cree report.md en el repositorio de su laboratorio y use esta plantilla. Reemplace cada marcador por lo que observó de verdad:

## Scope

- Target: http://127.0.0.1:3000, my own OWASP Juice Shop container
- Authorization: I run this lab on a machine I own
- Dates: <start date> to <end date>
- Out of scope: everything else

## Finding title

<Flaw> in <exact location>

## Steps to reproduce

1. <Start from a clean browser session at http://127.0.0.1:3000>
2. <Exact action or request>
3. <What you see>

## Evidence

<Screenshot file name, or the redacted curl -i output file, matched to the steps>

## Impact

<What you verified. What you did not verify, and the test that would check it.>

## CVSS vector

<CVSS:4.0 vector from the calculator, and its rating>

## Remediation

<The specific fix, and how to check that it works>

#5. Haga commit del informe

Revise qué va a registrar Git antes de hacer commit, para que un archivo sin redactar no se cuele:

git add report.md
git status
git commit -m 'First lab finding'

Confirme el commit con git log --oneline -1. La línea debería mostrar su mensaje. Al terminar, detenga el contenedor del laboratorio con docker stop <container-name> y ejecute docker ps para confirmar que ya no aparece.

#Errores comunes

• Empezar por el impacto. Escriba primero los pasos y después decida qué prueban.
• Pasos que dependen de una sesión que el lector no tiene. Empiece desde un estado limpio y dígalo.
• Evidencia sin relación con los pasos. Numere la evidencia y cite el número en cada paso.
• Pegar la salida del scanner como prueba.
• Elegir la severidad por intuición. Use el vector y registre los supuestos detrás de él.
• Filtrar secretos en capturas, logs o commits.
• Una corrección sin forma de verificarla.
• Describir una prueba que no ejecutó. El informe dice qué pasó, en el orden en que pasó.
• Dedicar la mayor parte del informe a la metodología. La sección de hallazgos debe ser la más extensa.

#Cómo seguir avanzando

• Lea el NIST SP 800-115 completo. La publicación es gratuita en el sitio del NIST.
• Lea el capítulo de Reporting del WSTG, empezando por la estructura del informe y los esquemas de nombres.
• Lea la especificación de CVSS v4.0, métrica por métrica, antes de puntuar cualquier hallazgo importante.
• Entregue su hallazgo a alguien que no lo escribió y pídale que lo reproduzca solo con los pasos. Si no puede, el hallazgo todavía no está terminado.
• Lea las reglas de compromiso antes de probar cualquier sistema que no sea suyo. El artículo sobre reglas de compromiso en programas de bug bounty explica cómo los programas fijan esos límites.

#Fuentes

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide, Reporting
• Penetration Testing Execution Standard, Reporting
• FIRST, CVSS v4.0 Specification Document
• FIRST, CVSS v4.0 Calculator