01 · Contenido web no confiable#

En una frase, para cualquiera: cuando tu programa muestra un texto que escribió un desconocido, ese texto puede pedirle cosas a tu computador. Este caso pone a quien lee ese texto en una habitación sin puertas.

Estado real: 🟡 building · Carpeta: cases/01-untrusted-render/ · Puerto: 8801

Por qué se realiza este caso#

Imagina que recibes una carta y, para leerla, tienes que hacer todo lo que la carta diga mientras la lees. Eso es lo que hace un programa cuando interpreta contenido ajeno: leerlo es ejecutar las instrucciones de quien lo escribió.

La parte que sorprende es que no hace falta que la carta traiga un programa. Basta con que quien la lee tenga acceso a algo. Tres ejemplos, los tres reales:

Ninguno de los tres ejecuta JavaScript. Los tres funcionan solo porque el lector tenía permiso para abrir ficheros o para conectarse a algún sitio.

De ahí la respuesta de este caso: quitarle esos permisos al lector. No vigilarlos, no filtrarlos: quitarlos.

La idea que enseña, y que ningún otro caso enseña#

Separar por proceso. Hay dos programas, no uno:

• El coordinador conoce el disco, habla por la red y decide qué se permite.
• El intérprete no conoce nada. Recibe texto por su entrada, devuelve un

informe por su salida, y no tiene ninguna otra forma de comunicarse con el mundo.

La diferencia con «filtrar el contenido» es la que hay entre cerrar una puerta y poner un cartel de prohibido el paso. Cuando el contenido pide leer un fichero, aquí no ocurre un «permiso denegado»: es que no existe la función que abriría el fichero. El intento se anota y se sigue.

Y hay un segundo efecto, menos obvio y igual de importante: si el intérprete falla —porque un contenido raro lo hace reventar—, el que revienta es el intérprete, no el servicio. El coordinador recoge el fallo y responde.

Casos de uso reales#

• Un gestor de correo que muestra el HTML de un mensaje recibido.
• Un lector de noticias que consume fuentes RSS de terceros.
• Un foro o comentarios donde la gente escribe en Markdown.
• Una herramienta que previsualiza el README de un repositorio ajeno.
• Un sistema de tickets que muestra lo que pegó el cliente en el formulario.

Todos comparten la misma forma: texto que llega de fuera, y un programa tuyo que lo interpreta.

Cómo funciona#

flowchart LR
  U["👤 Alguien pega<br/>contenido ajeno"] --> C
  subgraph J["🔒 Jaula (bubblewrap · sin red)"]
    C["🧭 Coordinador<br/>app.py<br/>conoce el disco"]
    I["🧪 Intérprete<br/>interpreter.py<br/>SIN disco · SIN red"]
    C -- "texto por stdin" --> I
    I -- "JSON por stdout" --> C
  end
  C --> R["📄 Vista segura"]
  C --> L["🚫 Lista de lo que<br/>el contenido intentó hacer"]

El paso que importa es la flecha del medio. Entre el coordinador y el intérprete solo pasan dos tuberías de texto. No hay memoria compartida, no hay ficheros comunes, no hay sockets. Esa estrechez es el control.

Qué hace el intérprete con lo que recibe#

flowchart TB
  A["Contenido"] --> B{"¿Trae una<br/>entidad externa?"}
  B -- sí --> B1["🚫 XXE anotado<br/>y el DOCTYPE se retira entero"]
  B -- no --> C{"¿La etiqueta está<br/>en la lista de permitidas?"}
  C -- no --> C1["🚫 Se descarta"]
  C -- sí --> D{"¿El atributo está<br/>permitido para ella?"}
  D -- no --> D1["🚫 Se descarta<br/>(aquí caen los on*)"]
  D -- sí --> E{"¿Es una URL?"}
  E -- no --> F["✅ Se conserva"]
  E -- sí --> G{"¿Esquema y destino<br/>aceptables?"}
  G -- no --> G1["🚫 javascript: · data: · file: · metadatos"]
  G -- sí --> F

Es una lista de permitidos, no de prohibidos. La diferencia importa: una lista de prohibidos hay que actualizarla cada vez que alguien inventa una etiqueta nueva; una lista de permitidos deja fuera lo que se invente mañana sin tocar nada.

Esquemas#

Entrada — POST /api/render#

{ "content": "<p>el HTML o Markdown que llegó de fuera</p>" }

Salida#

{
  "ok": true,
  "elapsedMs": 41,
  "capabilities": {
    "filesystem": false, "network": false, "subprocess": false,
    "clock": false, "environment": false
  },
  "safeHtml": "<p>Hola </p><a>mira</a>",
  "rejections": [
    {
      "kind": "entidad-externa",
      "detail": "<!ENTITY x SYSTEM \"file:///etc/passwd\">",
      "why": "XXE: una entidad externa haría que el parser leyese un fichero por ti"
    }
  ],
  "rejectionsByKind": { "entidad-externa": 1, "ssrf": 1 },
  "stats": { "inputBytes": 335, "nodes": 19, "maxDepth": 2, "inputTruncated": false, "outputTruncated": false }
}

Los tipos de rechazo#

Software necesario#

El intérprete por sí solo funciona en cualquier sistema con Python, incluido Windows: no necesita jaula porque no usa nada que haya que enjaular.

Instalación#

git clone https://github.com/vladimiracunadev-create/sandbox-labs
cd sandbox-labs
sudo apt install bubblewrap util-linux python3
cargo build --release
cargo run -p sandboxctl -- doctor

completos, incluida la configuración de WSL2, están en Instalación.

Cómo se ejecuta#

El caso completo, como producto en su propio localhost:

cargo run -p sandboxctl -- service up untrusted-render

Solo el intérprete, sin levantar nada:

python3 cases/01-untrusted-render/interpreter.py < contenido.html

Para bajarlo:

cargo run -p sandboxctl -- service down untrusted-render

Procesos que se crean#

sandboxctl service up untrusted-render
  │
  ├─ systemd --user scope              ← cgroup: memory.max, pids.max, cpu.max
  │   └─ bwrap                         ← namespaces, montajes, seccomp, sin red
  │       └─ python3 app.py            ← el coordinador, escucha en socket Unix
  │           └─ python3 interpreter.py ← uno por petición, nace y muere con ella
  │
  └─ sandboxctl service forward        ← puente TCP :8801 ↔ socket Unix

Dos detalles que explican la forma:

• El servicio no tiene red. Escucha en un socket Unix dentro de la jaula, y

es el puente —que vive fuera— quien publica 127.0.0.1:8801. Si matas el puente, el servicio queda inalcanzable pero sigue contenido, que es el fallo correcto.

• El intérprete es de usar y tirar. Se lanza por petición y se destruye al

responder. Si tarda más de 5 segundos, se le corta.

Tiempo de carga#

Medido en WSL2 (Ubuntu 24.04, bubblewrap 0.9.0) sobre un portátil corriente:

Casi todo el tiempo de arranque es el intérprete de Python encendiéndose, no el aislamiento: la jaula cuesta milisegundos.

Cómo se comprueba que funciona#

node scripts/verify-cases.mjs

Le da al intérprete nueve entradas hostiles concretas y comprueba dos cosas por cada una: que el rechazo esperado aparece en el informe, y que el fragmento peligroso no sobrevive en la salida.

Y una décima comprobación: que el intérprete no declara ninguna capacidad concedida.

Estado real y qué falta#

Construido: el coordinador, el intérprete, la política de capacidades vacía, los quince tipos de rechazo y la prueba de comportamiento con diez comprobaciones.

Falta para llegar a functional:

• Ficha del caso en el panel de control.
• Levantar el servicio bajo bwrap dentro de CI y comprobar el flujo completo,

no solo el intérprete por separado.

Falta para llegar a verified: que cada interpretación emita evidencia firmada con los controles solicitados, aplicados y observados.

Si algo falla#

Los fallos que afectan a cualquier caso —no se puede crear el sandbox, no hay cgroups, un puerto ocupado, procesos huérfanos, la compilación en Windows— están resueltos uno a uno en Cuando algo falla.

Ver también: Catálogo completo · Estado del proyecto · Qué es un sandbox · Glosario