> For the complete documentation index, see [llms.txt](https://4lec4st.gitbook.io/4lec4st/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://4lec4st.gitbook.io/4lec4st/pt1-tryhackme/redaccion-de-informes.md).

# Redacción de Informes

Para que tus *write-ups* (informes técnicos) sean claros y accionables, es fundamental seguir una estructura coherente en cada uno. A continuación, se muestra un formato que funciona muy bien:

***

### 🧩 Título

Un encabezado corto y descriptivo.\
Ejemplo: **"SQL Injection no autenticada en el formulario de login"**

***

### ⚖️ Clasificación de Riesgo

Una valoración del riesgo de la vulnerabilidad descubierta.\
La vulnerabilidad debe ser evaluada **de forma aislada**, como si no existieran otras fallas en el sistema.\
Puedes usar la **matriz de riesgos del cliente** o una **pública como CVSS** (Common Vulnerability Scoring System).

***

### 🧠 Resumen

Una explicación breve de la vulnerabilidad y su impacto potencial, en lenguaje sencillo y accesible.

***

### 📚 Contexto

Proporciona información adicional que ayude a comprender la vulnerabilidad y por qué es importante.\
Esto es clave si el lector **no es experto en seguridad**, como los desarrolladores encargados de corregirla.

Explicar claramente la **causa raíz** les ayudará a aplicar una solución más precisa y efectiva.

***

### 🔍 Detalles Técnicos y Evidencia

Indica **dónde** y **cómo** se detectó la vulnerabilidad.

Incluye:

* Peticiones y respuestas HTTP
* Cargas útiles (*payloads*)
* Capturas de pantalla
* Fragmentos de código relevantes

***

### 💥 Impacto

Explica lo que **un atacante podría hacer realmente** con esta vulnerabilidad en el sistema evaluado.

Es importante **contextualizar el impacto** en el entorno específico.\
Por ejemplo:

> Con XSS, comúnmente se dice que se puede robar la cookie para secuestrar una sesión.\
> Pero si la aplicación usa *tokens* en lugar de cookies, ¿el impacto sigue siendo el mismo?

Analiza el impacto **real y concreto** dentro de la aplicación o sistema donde encontraste el fallo.

***

### 🛠️ Recomendación de Remediación

Proporciona pasos claros y prácticos para solucionar el problema.

🔑 Tu **primera recomendación debe resolver la causa raíz**, no solo mitigar el impacto.

Ejemplo:\
Para una SQL Injection:

* ✅ Lo correcto: usar **consultas parametrizadas**
* ⚠️ No suficiente por sí solo: sanitización o validación de entrada

Estas medidas adicionales ayudan, pero **no eliminan** la vulnerabilidad por sí solas.

Puedes incluir controles adicionales (*defensa en profundidad*), pero aclara que **no deben implementarse de forma aislada**.

***

### 📎 Referencias (Opcional)

Incluye enlaces útiles, como:

* Documentación del proveedor
* Guías oficiales
* Artículos técnicos de soporte a la solución