Riesgo de JavaScript de terceros: ataques a la cadena de suministro en páginas de pago

Por qué un script de terceros es tan poderoso

Los sitios web modernos se arman con muchas fuentes. Una página típica carga analítica, etiquetas de publicidad y de conversión, un widget de chat, una herramienta de opiniones de clientes, tipografías, pruebas A/B, un aviso de consentimiento y, con frecuencia, un gestor de etiquetas que carga todavía más. Cada uno de estos es JavaScript del servidor de otra empresa.

Cuando un navegador carga un script con una etiqueta <script src="..."> normal, ese script no está aislado. Se ejecuta en el contexto de su página, con los mismos permisos que el código que usted escribió. Puede leer todos los campos de un formulario de pago, añadir o quitar elementos, escuchar las pulsaciones de teclas y hacer solicitudes de red a cualquier dirección que permita la política de seguridad de la página. El navegador no sabe en qué scripts usted confía más que en otros.

Así, la seguridad de su página de pago es tan fuerte como la de la empresa más débil cuyo script carga, y como la de la más débil de las empresas que esa empresa carga a su vez.

Cómo un script de terceros se convierte en skimmer

Los atacantes no necesitan entrar en su sitio si pueden entrar en algo en lo que su sitio ya confía. Las vías documentadas incluyen:

• El proveedor sufre una intrusión. Un atacante modifica el script del proveedor en los propios servidores del proveedor, y todos los sitios que lo cargan pasan a servir el código modificado.
• El dominio o la cuenta cambia de manos. Se vende el dominio donde se aloja un script, vence y otra persona lo registra, o se toma el control de la cuenta del proveedor, y el nuevo controlador sirve código distinto desde la misma dirección.
• Un script carga otros scripts. Usted aprobó el script A, pero A carga B y B carga C. Un cambio al final de la cadena es invisible si solo se mira el primer eslabón.
• Contenido que varía según el visitante. Algunos servicios generan su script al momento, por ejemplo según el navegador o la ubicación del visitante. Una versión maliciosa puede servirse a unos visitantes y a otros no, incluidas las personas que la prueban.
• Una actualización defectuosa o maliciosa. Los proveedores publican versiones nuevas sin avisar a sus clientes, y un error o una persona interna puede introducir un comportamiento dañino.

El caso del widget de chat descrito en incidentes notables de robo de tarjetas del lado del cliente es un ejemplo de la primera vía. La siguiente sección describe un ejemplo de la segunda.

Un ejemplo reciente: el dominio polyfill.io

Polyfill.io era un servicio gratuito muy popular que servía código JavaScript de compatibilidad para navegadores antiguos, y muchos sitios web lo cargaban directamente desde la dirección cdn.polyfill.io. El 25 de junio de 2024 la empresa de seguridad Sansec informó de que el código servido desde ese dominio inyectaba un comportamiento malicioso, y estimó que más de 100.000 sitios web lo incluían. El informe de Sansec indica que el dominio y su cuenta de GitHub asociada habían sido adquiridos por una empresa china en febrero de 2024; después de eso comenzó el comportamiento malicioso. El código que analizó Sansec redirigía a algunos visitantes de móviles a sitios ajenos y estaba escrito para evitar su detección, por ejemplo omitiendo a los visitantes que parecían administradores.

Como respuesta, Cloudflare empezó a reescribir las solicitudes a ese dominio hacia su propio espejo seguro, y el registrador del dominio lo suspendió. Recuentos posteriores de otros investigadores situaron el número de sitios afectados por encima de la primera estimación, así que considere cualquier cifra como una estimación.

El comportamiento que vio Sansec fue una redirección y no un robo de tarjetas. La lección para las páginas de pago está en la posición que ocupaba el script: un script servido desde esa dirección podía hacer en cualquier página lo que hacía en esas, incluido leer un formulario de pago. Ningún sitio había sido atacado en el sentido habitual; su propio código no había cambiado.

Cómo gestionar el riesgo

Reduzca lo que carga

El paso más eficaz es cargar menos scripts de terceros en las páginas que manejan datos de tarjetas. Las páginas de pago rara vez necesitan etiquetas de publicidad, mapas de calor o widgets de redes sociales. Muchas organizaciones separan el proceso de pago del sitio de marketing precisamente por esto.

Sepa lo que carga

Mantenga un inventario de cada script de cada página de pago, quién lo aprobó y por qué es necesario, como se describe en cómo crear un inventario de scripts de la página de pago. Es también lo que pide PCI DSS 6.4.3; vea la explicación del requisito 6.4.3.

Fije y restrinja

• Para archivos estáticos de terceros, use Integridad de Subrecursos (SRI) para que el navegador rechace un archivo cuyo contenido haya cambiado.
• Cuando la licencia lo permita, considere alojar usted mismo una copia fija de una biblioteca y actualizarla deliberadamente, en lugar de cargarla en vivo desde el servidor de otra empresa.
• Use una Política de Seguridad de Contenido (CSP) para limitar qué orígenes pueden aportar scripts y adónde se pueden enviar datos.
• Cuando un widget no necesite acceso a la página, cárguelo en un iframe con el atributo sandbox.

Gobierne al proveedor

Trate a los proveedores de scripts como a cualquier otro tercero: entienda quiénes son, qué hace el script, cómo protegen su entrega y cómo le avisarán de los cambios. El requisito 12.8 de PCI DSS trata de la gestión de los proveedores de servicios de terceros.

Vigile los cambios

Como un proveedor puede cambiar un script en cualquier momento, no basta con la aprobación del día en que lo añadió. Compare periódicamente lo que sus páginas cargan realmente con la lista aprobada, y vigile el vencimiento o el cambio de titularidad de los dominios de los que provienen sus scripts. Vea cómo detectar la manipulación del lado del cliente.