🧠 Qué significa “mantener la URL original” (clave
conceptual)
Cuando TryHackMe dice eso NO significa que el navegador vaya a hacer dos requests.
Significa esto:
El navegador sigue usando:
[Link]
El backend, al concatenar mal la URL, termina haciendo otra request interna
a:
[Link]
👉 Exactamente como en tu imagen:
El frontend “cree” que pidió stock/item
El backend termina pidiendo otra cosa
🧩 Cómo se arma internamente la URL (modelo
mental)
El backend hace algo como:
[Link]
Tu control está solo en {server}.
🎯 Objetivo técnico exacto
Lograr que el backend interprete:
[Link]
y que lo que viene después (.[Link]/api/item?id=2)
quede neutralizado como parámetro, igual que en la imagen de referencia.
🔓 Payload correcto (el que el laboratorio espera)
Usa este exactamente:
[Link]
🔬 Qué pasa internamente (paso a paso)
1️⃣ El backend concatena
[Link]
2️⃣ El parser HTTP interpreta eso como:
Host: [Link]
Path: /flag
Query real: id=9
El resto queda como:
x=.[Link]/api/item?id=2
(basura controlada, no afecta)
📌 Esto es exactamente lo que muestra tu imagen teórica.
✅ Qué debes ver abajo en TryHackMe
En la línea Server Requesting debe aparecer algo como:
[Link]
Y el laboratorio devuelve el flag.
🧠 Por qué funciona (en una sola frase)
Porque & convierte todo lo que el backend agrega después en un parámetro de query,
evitando que siga siendo parte de la ruta.
🧪 Si no te funciona a la primera
Prueba estas variantes equivalentes (depende del parser):
server=server/flag?id=9&
server=server/flag?id=9?x=
server=server/flag?id=9%26x=
Pero el principal y más común en TryHackMe es:
&x=
📝 Cómo explicarlo como profesional (pentest /
entrevista)
Se explotó una vulnerabilidad SSRF mediante concatenación insegura de subdominios.
El parámetro server permitía inyección de rutas, y usando separación de query (&) se
logró truncar la ruta backend, forzando al servidor a consultar un endpoint interno
(/flag).
Si quieres, en el próximo mensaje puedo:
dibujarte el flujo SSRF paso a paso
ayudarte a documentarlo como hallazgo CVSS
mostrar cómo mitigarlo correctamente en código
o relacionarlo con SSRF reales (AWS metadata, GCP, Azure)
Tú dime 👌
correcto, se lo resolvio de forma exitosa, pero no me queda muy claro, revisa la imagen y
explicame
Excelente 👌, ahora sí vamos a cerrar el círculo mental y que esto te quede clarísimo,
porque lo que acabas de hacer es SSRF real, no solo “meter un payload”.
Voy a explicarlo exactamente usando TU imagen final, sin saltos.
1️⃣ Qué escribió el usuario (lo visible)
En el navegador aparece algo como:
[Link]
📌 Esto es lo ÚNICO que controla el atacante
📌 El navegador solo habla con [Link]
2️⃣ Qué hace el backend vulnerable (el error clave)
El backend tiene una lógica similar a esta (conceptual):
URL_final =
"[Link] +
server +
".[Link]/api/item?id=2"
⚠️Error grave:
No valida
No parsea correctamente
No restringe server
3️⃣ Qué concatena realmente el backend (línea crítica)
Con tu payload, el backend construye literalmente esto (lo que ves abajo):
[Link]
🔴 Esto ES EXACTAMENTE lo que muestra la imagen:
Server Requesting:
[Link]
4️⃣ Ahora viene la parte MÁS IMPORTANTE
👉 cómo el servidor HTTP interpreta esa URL
Un parser HTTP NO lee la URL como texto plano, la divide así:
🔹 Host
[Link]
✔️válido
✔️interno
✔️permitido
🔹 Path
/flag
🎯 ESTE es el endpoint sensible
🔹 Query string
id=9&x=.[Link]/api/item?id=2
Aquí pasa la magia:
id=9 → lo que realmente interesa
x=... → basura absorbente
/api/item?id=2 → ya NO es ruta, solo texto
📌 Todo lo que el backend quiso agregar quedó neutralizado
5️⃣ Por qué &x= es la clave del ataque
Antes del &:
/flag?id=9
Después del &:
x=lo_que_sea
💡 En HTTP:
&separa parámetros
NO separa rutas
NO cambia el path
👉 Por eso el backend cree que agregó /api/item?id=2,
pero el servidor web ya no lo trata como ruta.
6️⃣ Por qué el flag aparece aunque la URL sea “larga”
Porque solo importa esto:
Host: [Link]
Path: /flag
Query: id=9
Todo lo demás:
x=.[Link]/api/item?id=2
es ignorado por la lógica del endpoint /flag.
7️⃣ Relación exacta con la imagen teórica
Tu imagen teórica decía:
“&x= se usa para evitar que el resto del path sea añadido y convertirlo en parámetro”
👉 Eso es EXACTAMENTE lo que ocurrió, sin variaciones.
8️⃣ Resumen mental (para que no se te olvide)
Guárdate esta frase:
“No rompí la URL, rompí la concatenación del backend.”
Y esta regla de oro SSRF:
Si controlo una parte del host y el backend concatena rutas, & convierte rutas en
basura.
9️⃣ Cómo lo explicarías como Analista / Pentester
Texto corto y profesional:
Se identificó una vulnerabilidad SSRF causada por la concatenación insegura de
subdominios. Mediante inyección de parámetros de query (&), se truncó la ruta
backend, forzando al servidor a realizar una solicitud interna a un endpoint no
expuesto (/flag).
Si quieres, en el próximo mensaje puedo:
dibujarte el flujo HTTP paso a paso
mostrar el código vulnerable y su fix correcto
explicarte cómo detectar esto en logs reales
relacionarlo con SSRF en AWS / metadata / Kubernetes