XSS: un script ajeno en tu página en JavaScript

Problema

Una búsqueda que roba

La tienda tiene un buscador. La página de resultados muestra lo que escribió el comprador: «Resultados para: zapatillas para correr». El servidor pega el texto de la búsqueda en HTML:

function searchPage(query) {
  return "<p>Resultados para: <b>" + query + "</b></p>";
}

console.log(searchPage("zapatillas"));
console.log(searchPage("<img src=x onerror=\"steal(shopSession)\">"));

<p>Resultados para: <b>zapatillas</b></p>
<p>Resultados para: <b><img src=x onerror="steal(shopSession)"></b></p>

La primera línea es una página normal. En la segunda, la búsqueda es <img src=x onerror="steal(shopSession)">, y ha llegado al HTML entera. El navegador ve una etiqueta de imagen, la imagen x no carga, y ejecuta el código de onerror. Aquí steal es una función inventada; en un ataque real el código envía las cookies o la sesión al servidor del atacante.

El atacante no escribe en su propio buscador. Les envía a los compradores un enlace a una búsqueda en la tienda con este texto en la dirección. Quien lo abre ejecuta el código ajeno en la tienda, con su propia sesión. Eso es XSS (cross-site scripting): un script ajeno en tu página.

La idea

HTML es un lenguaje más

Esta es la inyección de la lección anterior, en un lenguaje más. En HTML, < empieza una etiqueta y " cierra el valor de un atributo. El código pegó el texto del comprador en el lenguaje del navegador, y los caracteres del texto pasaron a ser parte de la página.

Dos tipos son los más frecuentes:

Reflejado (reflected): el texto viene de la dirección y vuelve en la respuesta, como la búsqueda de arriba. El atacante tiene que conseguir que alguien abra el enlace.
Almacenado (stored): el texto se guarda en la base de datos, por ejemplo una reseña, y se muestra a todo el que abre el producto. El atacante escribe una vez, y el script se ejecuta en todos.

El servidor no ejecutó nada. El código se ejecuta en el navegador del comprador, con su sesión, como si fuera parte de la tienda.

Míralo

Pruébalo tú mismo

Escribe un texto en el buscador de la tienda, elige una defensa y mira qué pasa. La página está en un iframe aislado, sin red, y no ve nada de este sitio.

Sandbox: entrada hostil en una página de la tienda

Lo que el comprador escribe en el buscador

Defensa sin defensa escapar la salida CSP

La página (en un iframe aislado, sin red)

Qué pasó

Lo que llega al navegador

La sandbox está aislada: no tiene red y no ve nada del sitio. Aquí steal() es el servidor falso del atacante; un ataque real envía los datos con fetch.

La sandbox necesita JavaScript. Entradas para probar:

zapatillas para correr

<script>alert(1)</script>

<img src=x onerror="steal(shopSession)">

Prueba las tres entradas listas sin defensa, luego con escape, luego con CSP. Mira en «Lo que llega al navegador» cómo es el HTML en los tres casos.

La idea

Escapar la salida

El arreglo es el escape: antes de poner un texto en HTML, cambias los cinco caracteres que HTML interpreta por sus entidades. El navegador muestra la entidad como un carácter, pero no la lee como parte de la página:

Carácter	Se convierte en	Por qué
`&`	`&`	empieza una entidad; se cambia el primero
`<`	`<`	empieza una etiqueta
`>`	`>`	cierra una etiqueta
`"`	`"`	cierra el valor de un atributo
`'`	`'`	cierra un valor entre comillas simples

Node.js no tiene una función así, por eso la escribimos:

function escapeHtml(text) {
  return text
    .replaceAll("&", "&amp;")
    .replaceAll("<", "&lt;")
    .replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;")
    .replaceAll("'", "&#39;");
}

function searchPage(query) {
  return "<p>Resultados para: <b>" + escapeHtml(query) + "</b></p>";
}

console.log(searchPage("zapatillas"));
console.log(searchPage("<img src=x onerror=\"steal(shopSession)\">"));

<p>Resultados para: <b>zapatillas</b></p>
<p>Resultados para: <b>&lt;img src=x onerror=&quot;steal(shopSession)&quot;&gt;</b></p>

Ahora la búsqueda llegó al navegador como texto. El comprador ve exactamente lo que escribió, pero no hay ninguna etiqueta.

La regla es escapar la salida: al mostrar, en el lugar donde el texto entra en HTML. No al recibir: entonces no sabes adónde irá el texto (a HTML, a JSON, a un correo), y en la base de datos queda < en lugar de lo que escribió el comprador.

Más precisamente, para curiosos

En un proyecto real el HTML se genera con plantillas o con React, y ellos escapan por sí solos: {text} en JSX es seguro. dangerouslySetInnerHTML desactiva el escape, y su nombre dice por qué. En el navegador, element.textContent = text es seguro, mientras que element.innerHTML = text lee el texto como HTML.
El escape depende del sitio. Los cinco caracteres bastan para el texto entre etiquetas y para el valor de un atributo entre comillas. Un atributo sin comillas, el texto dentro de <script>, los estilos y una dirección en href tienen otras reglas. Lo más sencillo: pon texto de fuera solo entre etiquetas y en atributos con comillas.
La dirección en href. javascript:steal(shopSession) no tiene ninguno de los cinco caracteres y aun así ejecuta código al hacer clic. Para las direcciones de los usuarios hace falta una lista de permitidos, como en la lección «Entrada no confiable»: la dirección empieza por https:// o http://, y si no, no se convierte en enlace.

Pruébalo

Encuentra el campo

La página de reseñas muestra un título, un autor y un texto. ¿Qué campo llega en bruto al navegador?

Elige la línea con el error.

Pruébalo

Qué imprimirá

¿Qué imprime el escape para Tom & Jerry <3?

console.log(escapeHtml("Tom & Jerry <3"));

Respuesta

Tom &amp; Jerry &lt;3

Tom & Jerry &lt;3

Tom &amp; Jerry &amp;lt;3

La idea

CSP: la segunda línea

En un sitio grande hay cientos de lugares donde el texto entra en HTML. Basta con pasar uno por alto. Por eso hay una segunda defensa: Content-Security-Policy (CSP). Es una cabecera de la respuesta que le dice al navegador qué scripts pueden ejecutarse:

Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'none'

script-src 'self' significa: solo scripts de archivos del mismo sitio. Un script escrito dentro de la página (<script>…</script> o onerror="…") no se ejecuta, y el navegador anota la infracción. Por eso también el JavaScript propio del sitio tiene que estar en archivos. Si aun así necesitas un script en la página, CSP acepta uno con un nonce: un valor aleatorio, nuevo en cada respuesta, que el atacante no conoce. Así funciona la defensa «CSP» de la sandbox.

CSP no sustituye al escape. Detiene el script, pero no el HTML ajeno: un formulario falso «Inicia sesión de nuevo» o un precio cambiado no son un script. El escape es la primera línea, CSP es la red de debajo.

Más precisamente, para curiosos

Pruébalo sin romper nada. Content-Security-Policy-Report-Only solo informa de lo que la política bloquearía. Así se introduce CSP en un sitio antiguo: primero se miran las infracciones, luego se activa.
La cookie de la sesión. Aunque el script se ejecute, una cookie con la marca HttpOnly no es visible para JavaScript. Eso viene en la lección sobre las sesiones.

Ejercicio

La reseña

Resuelve la tarea en tu editor.

Una reseña con autor. Escribe renderReview(author, text). Devuelve <article><h3>autor</h3><p>texto</p></article>, con el autor y el texto escapados. Prueba con una reseña normal y con un autor que se llama <script>steal(shopSession)</script>:

<article><h3>Ana</h3><p>Muy buenas &lt;3</p></article>
<article><h3>&lt;script&gt;steal(shopSession)&lt;/script&gt;</h3><p>Genial</p></article>

Más tareas

Un enlace en la reseña. Añade a la reseña un campo «sitio web del autor». Muéstralo como <a href="…"> solo si la dirección empieza por https:// o http://; si no, muéstralo como texto normal. Prueba con javascript:steal(shopSession).
Doble escape. ¿Qué verá el comprador si la reseña se escapa una vez al guardarla en la base de datos y otra vez al mostrarla? Prueba con <3.

Test

Ponte a prueba

1. El buscador solo muestra lo que escribió el comprador. ¿Por qué <img src=x onerror="…"> en la búsqueda ejecuta código?Solo si el comprador ha iniciado sesión en su perfilEl texto está pegado en HTML, y el navegador lo lee como una etiqueta: la imagen no carga y ejecuta el código de onerrorPorque el servidor ejecuta el texto de la búsqueda

2. El escape convierte < en <. ¿Qué hace el navegador con <?Lo quitaMuestra el carácter < como texto: no empieza ninguna etiquetaLo ejecuta como una etiqueta, pero más tarde

3. ¿Por qué el escape cambia & primero, antes que < y >?El orden no importaPorque & es el carácter más peligrosoSi lo cambiara después, cambiaría también el & de <, que acaba de poner, y el comprador vería < en lugar de <

4. Una reseña tiene un enlace <a href="…"> con una dirección del comprador, que pasó por el escape. El comprador escribe javascript:steal(shopSession). ¿Lo detiene el escape?Sí: el escape detiene cualquier scriptNo: en la dirección no hay < ni comillas. Para las direcciones hace falta una lista de permitidos: solo http:// y https://Sí, si la dirección está entre comillas

5. La página tiene CSP: script-src 'self'. ¿Sigue haciendo falta el escape?No: CSP escapa por tiSí: CSP es la segunda línea. Detiene el script si en algún sitio se te pasó el escape, pero no detiene el HTML ajeno que sustituye el contenido de la páginaNo: CSP lo detiene todo

XSS: un script ajeno en tu página

Cookies