Leer una CSP y encontrar su hueco

Una CSP llega como cabecera Content-Security-Policy y es una lista de directivas separadas por punto y coma. Cada directiva nombra un tipo de recurso y las fuentes permitidas: script-src para scripts, img-src para imágenes, connect-src para las conexiones que abre el código, object-src para complementos. default-src es el valor de respaldo para las directivas de carga que no aparecen.

Las fuentes más comunes son 'self' (el mismo origen), nombres de host, esquemas como https: y dos mecanismos para autorizar código escrito dentro de la página: un nonce, un valor aleatorio que cambia en cada respuesta y que solo los scripts legítimos llevan, o la huella del script. 'unsafe-inline' autoriza todo el código en línea, el legítimo y el inyectado.

La CSP no arregla la inyección: si la página mete texto del usuario sin escapar, el fallo sigue ahí. Lo que hace es que el navegador se niegue a ejecutar el script inyectado. Por eso se informa como defensa en profundidad, al lado del hallazgo de inyección, no en su lugar.

Existe una segunda cabecera, Content-Security-Policy-Report-Only. Con ella el navegador evalúa la política y envía un aviso por cada violación a la dirección de report-uri, pero no bloquea nada. Sirve para probar una política antes de aplicarla. El hallazgo aparece cuando una página sensible se queda en ese modo de forma indefinida: la política puede ser perfecta y no proteger en absoluto.

Abre el laboratorio y lee csp-cabeceras.txt; después mira informes-csp.txt para entender por qué está así.

En la especificación de CSP del W3C hay una regla que desconcierta a quien lee rápido: si la lista de fuentes de scripts contiene un nonce o una huella, el navegador ignora 'unsafe-inline'. Los equipos lo dejan a propósito para que navegadores muy antiguos, que no entienden los nonces, sigan funcionando. En un navegador actual, solo corre el código en línea que lleva el nonce correcto.

Mira la política de /eventos/detalle con esa regla delante.

Ahora recorre las cinco páginas con una sola pregunta: si alguien consiguiera inyectar un script en línea, sin nonce, ¿lo ejecutaría el navegador? Recuerda tres cosas: la cabecera de solo informe no bloquea, 'unsafe-inline' sin nonce ni huella deja pasar todo el código en línea, y una directiva script-src que no menciona 'unsafe-inline' lo bloquea.

Una política sin 'unsafe-inline' todavía puede tener hueco por la lista de hosts. Si permite un origen donde cualquiera puede publicar archivos, quien logre inyectar una etiqueta de script en la página solo tiene que apuntarla a un archivo publicado ahí, y el navegador lo cargará porque el host está autorizado. Por eso las guías actuales prefieren nonces o huellas a listas de hosts. También conviene mirar lo que falta: base-uri no hereda de default-src, y sin ella una inyección puede cambiar la base de las rutas relativas de la página.