Blind XSS Lab

This repository contains an intentionally vulnerable blind XSS lab for controlled demonstrations. Use it only in an isolated environment that you own.

Espanol

Que demuestra este laboratorio

• un formulario publico en cross.fit almacena contenido controlado por el atacante
• un panel interno en backend.cross.fit renderiza ese contenido mas tarde
• un navegador privilegiado automatizado actua como puente hacia el backend interno
• un JWT guardado en localStorage puede ser robado y reutilizado explicitamente
• mitigaciones como escaping contextual y CSP bloquean el flujo vulnerable

Topologia asumida

Este repo asume una unica maquina con Kali Linux que cumple dos roles al mismo tiempo:

• host Docker que ejecuta los contenedores
• maquina atacante desde la que se navega cross.fit y se levantan listeners HTTP

Consecuencia practica:

• cross.fit debe resolver al propio host Kali
• backend.cross.fit no debe agregarse al /etc/hosts del host
• los callbacks desde contenedores al host normalmente usan 172.28.0.1

Documentacion

• Indice documental
• Setup Kali mismo host
• Guia paso a paso en espanol
• Guia paso a paso en ingles
• Referencia de payloads
• Plan del laboratorio

Quick start

1. Instala Docker Engine y Docker Compose plugin en Kali siguiendo docs/setup-kali-same-host.md.
2. Agrega cross.fit al /etc/hosts del host. No agregues backend.cross.fit.
3. Copia el archivo de entorno:

cp .env.example .env

4. Levanta el laboratorio:

docker compose up --build -d

5. Si vas a servir helpers externos:

python3 -m http.server 8000

6. Si vas a capturar exfiltracion estructurada:

python3 tools/collector.py

Validacion minima

Entrada publica:

curl -i http://cross.fit/

Aislamiento del backend:

curl -i -H "Host: backend.cross.fit" http://container_machine_ip/

Acceso interno desde el worker:

docker compose exec -T worker wget -S -O- http://backend.cross.fit/login

Esperado:

• cross.fit responde desde el proxy publico
• el host no expone backend.cross.fit
• el worker si puede acceder al backend interno

Modo mitigado

El laboratorio arranca por defecto en modo vulnerable. Para validar mitigaciones:

LAB_MODE=mitigated docker compose up -d --build internal-app worker

En ese modo:

• el sink HTML deja de renderizar crudo
• CSP bloquea scripts y handlers inline
• el flujo de robo y exfiltracion deja de ejecutarse

Estructura del repo

.
|-- docker-compose.yml
|-- db/
|-- docs/
|-- nginx/
|-- public-app/
|-- internal-app/
|-- tools/
`-- worker/

Inseguridad intencional

Este laboratorio incluye deliberadamente:

• almacenamiento de HTML controlado por el atacante
• renderizado inseguro en la vista interna vulnerable
• credenciales estaticas de laboratorio
• un JWT accesible desde localStorage

English

What this lab demonstrates

• a public form on cross.fit stores attacker-controlled content
• an internal panel on backend.cross.fit renders that content later
• an automated privileged browser acts as the bridge into the internal backend
• a JWT stored in localStorage can be stolen and replayed explicitly
• mitigations such as contextual escaping and CSP block the vulnerable flow

Assumed topology

This repo assumes a single Kali Linux machine playing both roles at the same time:

• Docker host running the containers
• attacker machine used to browse cross.fit and run HTTP listeners

Practical consequences:

• cross.fit should resolve to the Kali host itself
• backend.cross.fit must not be added to the host /etc/hosts
• callbacks from containers back to the host will usually use 172.28.0.1

Documentation

• Documentation index
• Kali same-host setup
• Spanish step-by-step guide
• English step-by-step guide
• Payload reference
• Lab plan

Quick start

1. Install Docker Engine and the Docker Compose plugin on Kali using docs/setup-kali-same-host.md.
2. Add cross.fit to the host /etc/hosts. Do not add backend.cross.fit.
3. Copy the environment file:

cp .env.example .env

4. Start the lab:

docker compose up --build -d

5. If you plan to serve external helpers:

python3 -m http.server 8000

6. If you plan to capture structured exfiltration:

python3 tools/collector.py

Minimum validation

Public entrypoint:

curl -i http://cross.fit/

Backend isolation:

curl -i -H "Host: backend.cross.fit" http://container_machine_ip/

Internal access from the worker:

docker compose exec -T worker wget -S -O- http://backend.cross.fit/login

Expected:

• cross.fit responds from the public proxy
• the host does not expose backend.cross.fit
• the worker can access the internal backend

Mitigated mode

The lab starts in vulnerable mode by default. To validate mitigations:

LAB_MODE=mitigated docker compose up -d --build internal-app worker

In that mode:

• the HTML sink no longer renders raw attacker content
• CSP blocks inline scripts and handlers
• the theft and exfiltration flow stops executing

Repository layout

.
|-- docker-compose.yml
|-- db/
|-- docs/
|-- nginx/
|-- public-app/
|-- internal-app/
|-- tools/
`-- worker/

Intentional insecurity

This lab intentionally includes:

• attacker-controlled HTML stored through the public flow
• unsafe rendering in the vulnerable internal view
• static lab credentials
• a JWT accessible from localStorage

References

• OWASP Cross-Site Scripting: https://owasp.org/www-community/attacks/xss/
• OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
• MDN Web Storage API: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API
• Docker Compose Networking: https://docs.docker.com/compose/how-tos/networking/
• Nginx access controls: https://nginx.org/en/docs/http/ngx_http_access_module.html