Política de Seguridad de Contenido (CSP) para páginas de pago

Qué hace una Política de Seguridad de Contenido

La Política de Seguridad de Contenido (CSP) es una función de seguridad del navegador que se activa enviando con la página una cabecera Content-Security-Policy. La política es una lista de directivas, cada una de las cuales nombra los tipos de recurso que controla y los orígenes permitidos. Si la página intenta cargar o ejecutar algo que la política no permite, el navegador lo bloquea y puede informar del intento.

Para una página de pago el valor es doble. Puede impedir que un skimmer se ejecute, al rechazar scripts de un origen que usted no aprobó, y puede impedir que un skimmer envíe datos fuera, al limitar adónde puede hacer solicitudes la página, desde dónde puede cargar imágenes y adónde puede enviar formularios. Por eso es a la vez un control de prevención y, con informes, una fuente de señales. No sustituye corregir el fallo de fondo; vea XSS y código skimmer inyectado.

Las directivas que importan en las páginas de pago

script-src: listas de hosts, nonces, hashes y strict-dynamic

Listas de hosts permitidos: fáciles pero frágiles

La política más simple enumera los hosts desde los que pueden venir los scripts. En la práctica es débil: se ejecuta cualquier script de un host permitido, de modo que un host permitido que sirva contenido aportado por usuarios, una redirección abierta o una gran colección de bibliotecas puede aprovecharse para ejecutar el código de un atacante. Además, las listas largas son difíciles de mantener exactas.

Nonces

Un nonce es un valor aleatorio que se genera para cada respuesta y se coloca tanto en la cabecera como en cada etiqueta <script> legítima. El navegador ejecuta solo los scripts que llevan el nonce. Debe ser impredecible y nuevo en cada respuesta, y según la especificación de CSP debe tener al menos 128 bits antes de codificarse. Los nonces requieren páginas generadas en cada solicitud; una página guardada en caché y servida igual a todos no puede usarlos.

Hashes

Un hash indica el contenido exacto de un script permitido, de modo que el navegador solo ejecuta un script si su hash coincide. Los hashes convienen a scripts en línea estáticos que cambian poco.

'strict-dynamic'

Con 'strict-dynamic', un script en el que se confía mediante un nonce o un hash puede cargar más scripts, y estos heredan la confianza sin figurar en la lista. En los navegadores que lo admiten, las listas de hosts se ignoran entonces. Funciona bien con los gestores de etiquetas, pero también significa que se confía en todo lo que cargue el script de confianza, así que importa la gobernanza de ese script; vea riesgo de los gestores de etiquetas.

Qué anula una política

• 'unsafe-inline' permite cualquier script en línea, incluido uno inyectado, y elimina la mayor parte de la protección. Cuando hay un nonce o un hash, los navegadores modernos lo ignoran, por lo que a veces se incluye como alternativa para navegadores antiguos.
• 'unsafe-eval' permite construir código a partir de cadenas de texto.
• Los comodines como *, https: o un patrón de dominio amplio permiten mucho más de lo previsto.
• data: como origen de scripts permite incrustar un script en un enlace.

Despliegue seguro: modo solo informe e informes

Una política nueva casi siempre bloquea algo legítimo. Envíela primero como Content-Security-Policy-Report-Only: el navegador no bloquea nada pero informa de cada infracción. Revise los informes, corrija la política o elimine el script innecesario y aplíquela cuando los informes se calmen.

Los informes se envían a una dirección que usted indica. La directiva anterior report-uri está obsoleta en favor de report-to con un punto final con nombre definido en la cabecera Reporting-Endpoints, pero el soporte de los navegadores difiere, así que muchos sitios envían ambas por ahora. Consulte MDN para el soporte actual.

Una ilustración, no una política para copiar

Content-Security-Policy:
  default-src 'none';
  script-src 'nonce-{aleatorio-por-respuesta}' 'strict-dynamic';
  connect-src 'self' https://payments.example-provider.com;
  frame-src https://payments.example-provider.com;
  img-src 'self';
  style-src 'self';
  form-action 'self';
  base-uri 'none';
  object-src 'none';
  frame-ancestors 'none'

Una política real debe construirse a partir de lo que su página de pago necesita de verdad; el evaluador de CSP de Google y la guía sobre CSP estricta de web.dev son útiles para comprobarla.

CSP y PCI DSS

Una CSP puede servir como parte del método de autorización del requisito 6.4.3, porque hace cumplir qué orígenes pueden ejecutarse, y respalda los límites a la exfiltración que hacen menos útil a un skimmer. Por sí sola no demuestra que un archivo permitido no haya sido alterado, por lo que suele combinarse con una medida de integridad como la Integridad de Subrecursos (SRI). Y como la política es en sí misma una cabecera HTTP, el requisito 11.6.1 espera que se le avise si se cambia sin autorización. Vea PCI DSS 6.4.3 explicado y cabeceras de seguridad HTTP para páginas de pago.