> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/es/web/race-conditions/exploitation-of-time-sensitive-vulnerabilities.md).
# Explotación de vulnerabilidades sensibles al tiempo
Notas sobre Explotación de vulnerabilidades sensibles al tiempo para los laboratorios de PortSwigger Web Security Academy, incluyendo flujo de explotación, pruebas de payload, validación con Burp Suite y contexto de remediación.
### Explotación de vulnerabilidades sensibles al tiempo
### Contexto del laboratorio
El sitio ofrece una función de **Restablecimiento de contraseña** a través de un enlace enviado por correo electrónico. / No existe una condición de carrera real en el lado lógico de la aplicación, pero la generación de **tokens** es **basado**: depende de un **valor predecible** (tiempo), lo que permite falsificar un token válido para otro usuario enviando solicitudes \*\* al mismo tiempo\*\*.
### Observaciones iniciales
1. Usamos **Olvidé mi contraseña** con el usuario `wiener`.
* Un correo electrónico que contiene un enlace del tipo:
* `/forgot-password?user=wiener&token=`
{% code overflow="wrap" %}
```bash
¡Hola!
Por favor, sigue el enlace de abajo para restablecer tu contraseña.
https://0a1300c9040343bf810b7f2a00e60085.web-security-academy.net/forgot-password?user=wiener&token=3930dc6d3d076151204ad4147326f81a5e1609a8
```
{% endcode %}
* El token parece un **SHA1** (40 caracteres hexadecimales).
`forgot-password?user=wiener&token=3930dc6d3d076151204ad4147326f81a5e1609a8`
* El token parece un **SHA1** (40 caracteres hexadecimales).
```bash
hashid '3930dc6d3d076151204ad4147326f81a5e1609a8'
```
1. Al generar varios tokens
Suposición: el token se deriva principalmente de un **marca de tiempo** (o un valor basado en el tiempo), en lugar de un secreto robusto.
### Idea clave: forzar dos solicitudes en el mismo milisegundo
Si podemos activar **dos restablecimientos** al mismo tiempo, y el token depende solo del momento, entonces **los dos tokens serán idénticos**.
Problema: el servidor (PHP) a veces evita colisiones con la misma sesión / CSRF. / Solución: obtener **dos sesiones separadas**.
### Preparación: obtener dos pares de sesión + CSRF
Se realizan dos solicitudes separadas a:
* `GET /forgot-password`
```http
GET /forgot-password HTTP/2
Host: 0a1300c9040343bf810b7f2a00e60085.web-security-academy.net
Cookie:
```
Cada respuesta proporciona un nuevo par:
* `PHPSESSID=<...>`
* un nuevo token CSRF (valor oculto en el formulario)
Hay **dos solicitudes listas**, cada una con:
* su `PHPSESSID` cookie
* su campo CSRF asociado
### Disparador: envío en paralelo
Luego enviamos **en paralelo** dos POST de restablecimiento (mismo endpoint), en Burp (agrupar + enviar en paralelo), para que lleguen **en la misma ventana temporal**.
Resultado observado: Los dos correos electrónicos recibidos contienen \*\*exactamente el mismo token\*\*:
```bash
933ccbd314dc37df95887cd914b07e330517f7bb
933ccbd314dc37df95887cd914b07e330517f7bb
```
Conclusión: el token depende esencialmente de **marca de tiempo**, y no de un único secreto por usuario.
### Operación: restablecimiento de Carlos con el token de Wiener
Objetivo: token válido para `carlos`.
Método:
1. Lanza en paralelo dos restablecimientos:
* uno para `wiener`
* uno para `carlos`
```bash
forgot-password?user=wiener&token=da1d6e3ed67bef3efa9fe74fcfbf7603120ea744
forgot-password?user=carlos&token=da1d6e3ed67bef3efa9fe74fcfbf7603120ea744
```
Como los tokens son idénticos, el token recibido (por ejemplo, vía `wiener` correo electrónico) también será válido para `carlos`.
Si el sitio acepta esta URL, puedes **establecer una nueva contraseña** para `carlos`.
### Finalización del laboratorio
1. Inicia sesión como `carlos` con la nueva contraseña.
2. Accede al \*\*inicio de sesión de administrador\*\*.
3. Elimina el `carlos` usuario para validar el laboratorio.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hacking-notes.jord4n.pro/es/web/race-conditions/exploitation-of-time-sensitive-vulnerabilities.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
