Los Evaluadores de Seguridad Cualificados (QSA) de PCI DSS ya se enfrentan a la enorme tarea de ser expertos en seguridad sobre más de 397 páginas de contenido denso. Para complicar aún más las cosas, muchos comerciantes se apresuran a encontrar la solución más económica que les permita superar la evaluación, llevando al límite lo que se considera el enfoque mínimo aceptable. Aunque a primera vista estas soluciones afirman cumplir todos los requisitos, muchas de ellas dejan a los titulares de tarjetas expuestos de forma evidente a ataques del lado del cliente. En algunos casos, estas soluciones se mueven en la zona gris de una redacción ambigua, pero en realidad no cumplen los estándares de cumplimiento.
Esta guía ayuda a los QSA a identificar estas señales de alerta. La hemos redactado a partir de nuestra propia experiencia trabajando con evaluadores y de las evaluaciones de ingeniería que llevamos a cabo durante el desarrollo de una solución PCI para nuestros clientes.
Lista de verificación resumida para QSA:
Para cumplir los requisitos de 6.4.3 y 11.6.1, un comerciante debe ser capaz de demostrar (ya sea mediante una solución interna o a través de un proveedor):
- Un mecanismo para controlar los scripts de la página y la capacidad de bloquearlos. CSP, SRI o un script del lado del cliente pueden lograrlo, pero un rastreador por sí solo no puede.
- El contenido de los scripts puede verificarse en busca de indicadores de intención maliciosa. Para que esto sea posible, la solución debe tener la capacidad de mostrar el contenido del script. Sin capacidad de mostrar el contenido del script = sin capacidad de verificar la integridad del script. Sin evidencia = sin cumplimiento.
- Debe mantenerse un inventario de todos los scripts (en línea, de primera parte, de terceros y dependencias de los scripts) con justificación técnica o empresarial.
- Los encabezados de seguridad de las páginas de pago deben monitorizarse y mostrarse al menos semanalmente.
- Debe existir un mecanismo que alerte sobre la eliminación de cualquier medida de seguridad del lado del cliente.
- El contenido de los scripts debe monitorizarse activamente y generar alertas ante cualquier cambio.
La solución de un comerciante no cumpliría los requisitos si:
- No dispone de un script del lado del cliente ni de un CSP ni de un SRI que pueda bloquear la carga de scripts (incumple 6.4.3).
- Es exclusivamente un rastreador sin ningún tipo de ajuste de código en la página (incumple 6.4.3).
- Solo verifica las URL de los scripts pero no monitoriza su contenido (incumple 11.6.1).
- No envía alertas cuando se eliminan o modifican los encabezados de seguridad (incumple 11.6.1).
- No rastrea ni muestra los encabezados de seguridad al menos semanalmente (incumple 11.6.1).
Por qué existen estos requisitos:
Los requisitos 6.4.3 y 11.6.1 están relacionados con los ataques del lado del cliente: ataques que se ejecutan en el entorno de la aplicación en el dispositivo del usuario, pero que ocurren como consecuencia de las dependencias del comerciante. Este ámbito se incorporó en PCI DSS v4. Los emisores de tarjetas han señalado que una cantidad significativa de robos de Datos de Titulares de Tarjetas (CHD) ocurre del lado del cliente, fuera del campo de visión de otras medidas de seguridad. Un Firewall de Aplicaciones Web no tiene ningún impacto en las ejecuciones del lado del cliente, especialmente las provenientes de terceros. Por ello, esta ampliación del alcance fue necesaria. Muchos otros marcos de cumplimiento están siguiendo el mismo camino al ampliar los requisitos relacionados con la seguridad de la cadena de suministro para incluir las ejecuciones del lado del cliente.
¿Se aplican los requisitos de PCI a las aplicaciones de página única (SPA)?
La especificación PCI DSS no diferencia entre tecnologías de aplicaciones web de página única o aplicaciones web renderizadas en el servidor. Esto puede generar confusión, ya que algunos requisitos pueden parecer inaplicables o técnicamente inalcanzables sin monitorizar toda la aplicación de página única; sin embargo, las acciones de seguridad solicitadas sí se aplican a las aplicaciones de página única. En muchos sentidos, las SPA han contribuido significativamente a la necesidad de requisitos de seguridad más estrictos al aumentar la cantidad de código que se ejecuta del lado del cliente.
Alcance de 6.4.3 & 11.6.1:
La especificación PCI establece que "Este requisito se aplica a todos los scripts cargados desde el entorno de la entidad y a los scripts cargados desde terceros y cuartos". Por lo tanto, cualquier mención de 'script' incluye scripts del mismo origen (primera parte), terceros y las solicitudes secundarias de dichos terceros.
Muchas herramientas tradicionales no monitorizan los scripts del lado del cliente del mismo origen ni los scripts inyectados en línea. En otras palabras, estas herramientas no monitorizan los scripts de primera parte ni los fragmentos de código insertados directamente en la página (por ejemplo, etiquetas de analítica). Esto supone un problema, ya que los ataques del lado del cliente han tenido su origen con frecuencia en scripts del mismo origen.
6.4.3:
El requisito establece:
"Todos los scripts de páginas de pago que se cargan y ejecutan en el navegador del consumidor se gestionan de la siguiente manera:"
1. "Se implementa un método para confirmar que cada script está autorizado."
Esto significa que cualquier script no autorizado debe ser bloqueado antes de ser servido. Solo hay 2 formas de conseguirlo:
- Implementar CSP de scripts o SRI: Asegurarse de que las Políticas de Seguridad de Contenido (CSP) sean estrictas y estén en modo de bloqueo. Por diseño, CSP es un mecanismo para confiar en fuentes, no en los propios scripts. Son cosas fundamentalmente distintas. Si una fuente de confianza es comprometida, los scripts maliciosos pueden pasar sin que ninguna medida de seguridad los detenga.
La integridad de subrecursos (SRI) sí opera a nivel de script y valida el payload real. Sin embargo, SRI no siempre es una opción práctica para scripts dinámicos que cambian con frecuencia en el lado del cliente.
- Usar un script del lado del cliente: Un script del lado del cliente que se carga antes que todos los demás scripts puede ajustar o desmontar scripts. Puede impedir que scripts no autorizados se ejecuten parcial o totalmente.
Si un comerciante no dispone de CSP, SRI o un script del lado del cliente en una página para evitar que se carguen scripts no autorizados, el requisito 6.4.3 no se cumple.
Importante: una solución basada únicamente en rastreadores sin CSP no cumple los requisitos de PCI. Existen varios proveedores que ofrecen rastreadores que no satisfacen este requisito.
2. "Se implementa un método para garantizar la integridad de cada script."
Esto significa que cada script debe ser monitorizado. En 11.6.1 se explica con más detalle que esto incluye el contenido del script. Por lo tanto, una solución de seguridad que cumpla con 6.4.3 y 11.6.1 debe ser capaz de mostrar el contenido de los scripts que se sirvieron al usuario.
El lugar donde se ejecuta la solución importa: Las soluciones que se ejecutan de forma externa no pueden garantizar que el script que revisaron sea el que realmente se sirve a los usuarios finales. Se sabe que los actores maliciosos identifican las direcciones IP de los proveedores de nube de los rastreadores y excluyen los scripts maliciosos de ser servidos a ellos. Por lo tanto, no está claro si el requisito puede cumplirse con alguna solución que no resida en la aplicación en tiempo de ejecución. CSP por sí solo no puede verificar la integridad del script, ya que no inspecciona su contenido. SRI, en cambio, sí valida el contenido del script contra un hash.
URL de scripts + fuentes de amenazas: Algunas soluciones afirman cumplir los requisitos verificando las URL de los scripts contra fuentes de amenazas, pero eso solo verifica el nombre del archivo y no su contenido. Dado que 11.6.1 requiere específicamente la monitorización del payload real del script, estos enfoques no alcanzan el nivel de cumplimiento. Es la misma razón por la que un antivirus no se detiene en los nombres de archivo, sino que inspecciona lo que hay dentro.
Como regla general: si una solución no muestra el contenido de los scripts, no cumple los requisitos de monitorización de integridad.
Prueba de validación: Para comprobar si una solución puede verificar la integridad de los scripts, se recomienda realizar una prueba implementando un script de ejemplo 'malicioso' en un entorno de staging.
3. "Se mantiene un inventario de todos los scripts con justificación empresarial o técnica escrita sobre por qué cada uno es necesario."
Los comerciantes pueden usar hojas de cálculo o paneles de control proporcionados por proveedores para cumplir este requisito. La IA se utiliza con frecuencia para redactar las justificaciones. Algunas soluciones no ofrecen esto de forma nativa; en ese caso, se puede usar una hoja de cálculo. Sin embargo, es importante que dicha hoja de cálculo esté actualizada. Una exportación del panel de control de Google Tag Manager no es suficiente, ya que la propia aplicación puede tener scripts del lado del cliente inyectados fuera de Google Tag Manager.
Inventarios desactualizados o incompletos: Se recomienda que un QSA revise la solución en cuestión para verificar que todos los scripts están en el inventario y que este está actualizado.
Uso de un 'enfoque sin agente': La documentación de PCI DSS v4 proporciona orientación y sugiere el uso de CSP, SRI o un script propietario o sistema de gestión de etiquetas que pueda prevenir la ejecución de scripts maliciosos. No se menciona ninguna herramienta de observabilidad pasiva como un escáner, rastreador o agente. El requisito de impedir que un script malicioso se cargue no puede cumplirse sin añadir un script o un encabezado CSP a una página web.
11.6.1
Se despliega un mecanismo de detección de cambios y manipulaciones de la siguiente manera:
1. "Para alertar al personal sobre modificaciones no autorizadas (incluidos indicadores de compromiso, cambios, adiciones y eliminaciones) en los encabezados HTTP que afectan a la seguridad y en el contenido de los scripts de las páginas de pago tal como los recibe el navegador del consumidor."
Este requisito se refiere a la monitorización de todos los encabezados de seguridad del lado del servidor que pueden modificarse en el período previo a un ataque, así como al requisito de monitorizar los payloads de los scripts.
El payload del script debe analizarse y deben enviarse alertas oportunas en caso de compromiso. Por supuesto, una alerta sin indicadores de por qué se generó es inútil, por lo que para que sea accionable, el contenido de los scripts debe almacenarse y mostrarse para fines forenses.
Ejemplos de cambios que requieren alertas: "No se puede añadir código de skimming de comercio electrónico ni técnicas relacionadas a las páginas de pago tal como las recibe el navegador del consumidor sin que se genere una alerta oportuna. Las medidas anti-skimming no pueden eliminarse de las páginas de pago sin que se genere una alerta inmediata."
También es necesario disponer de un mecanismo para monitorizar cualquier manipulación de la propia solución de seguridad. Si esta es eliminada, debe generarse una alerta.
Para cumplir estos requisitos, deben monitorizarse los siguientes encabezados de seguridad:
| Encabezado de seguridad | Descripción |
|---|---|
| Content Security Policy | También conocido como encabezado CSP. |
| Content Security Policy Report Only | El encabezado CSP en modo solo de reporte, sin bloqueo. |
| Report To | Endpoint de reporte según la especificación heredada. |
| Reporting Endpoints | Endpoint de reporte alternativo según la especificación más reciente. |
| Strict Transport Security (HSTS) | Restringe el navegador para que solo se conecte mediante HTTPS. |
| X-Frame-Options | Permite definir si se permite la inyección de iframes en la página web. |
| Cross-Origin Resource Policy (CORP) | Permite a la página web definir qué recursos pueden cargarse y desde dónde. Relacionado con CORS y la Política del mismo origen. |
| Cross-Origin Opener Policy | Permite a la página web definir cómo debe interactuar el navegador con diferentes contextos, como pestañas, iframes y ventanas. |
| Cross-Origin Embedder Policy | Permite controlar qué componentes de origen cruzado puede cargar el navegador. |
| Permissions Policy | Permite definir a qué APIs de dispositivo pueden acceder las aplicaciones web y sus dependencias. |
| X-Content-Type-Options | Obliga estrictamente al navegador a verificar los tipos de contenido. De lo contrario, los navegadores podrían permitir inyecciones maliciosas a través de tipos de contenido no previstos. Es un método muy común en ejecuciones del lado del cliente y ataques de tipo MIME. |
| X-Permitted-Cross-Domain-Policies | Es un encabezado de seguridad más antiguo que define desde qué dominios podían obtener contenido Flash Player y los lectores de PDF. |
| Referrer Policy | Dato curioso: existe un error tipográfico en la especificación HTTP para 'referer'. Este encabezado permite definir cuánta información se envía junto con el referrer, la página anterior o la página padre. |
| X-XSS-Protection | Es un encabezado de seguridad heredado para habilitar o deshabilitar las funciones nativas de detección de XSS del navegador. |
2. "El mecanismo está configurado para evaluar los encabezados HTTP recibidos y las páginas de pago."
Esto refuerza los puntos mencionados anteriormente sobre la monitorización de todos los encabezados de seguridad HTTP que afectan a la seguridad en la página de pago.
3. "Las funciones del mecanismo se realizan de la siguiente manera: Al menos semanalmente O periódicamente (con la frecuencia definida en el análisis de riesgo objetivo de la entidad, que se realiza de acuerdo con todos los elementos especificados en el Requisito 12.3.1)."
Esta sección indica que estas verificaciones deben realizarse al menos semanalmente o en el plazo establecido por 12.3.1. Se puede permitir el muestreo en lo que respecta a los encabezados HTTP y el contenido de los scripts, pero al menos semanalmente deben revisarse. Una semana es mucho tiempo; se recomienda orientar a los comerciantes hacia una perspectiva de seguridad más proactiva.
AOC y ROC para proveedores
Los proveedores que ofrecen soluciones de seguridad para 6.4.3 y 11.6.1 no son TPSP en el contexto de los pagos (Proveedor de Servicios de Terceros) y no requieren ningún nivel de SAQ, AOC o ROC sobre su propio producto por parte de un QSA. Algunos proveedores más grandes sí cuentan con estas certificaciones para otras partes de su negocio y, en ocasiones, incluyen sus herramientas relacionadas con PCI dentro de esos informes. Eso no implica necesariamente que dichas herramientas hayan sido probadas o validadas. El comerciante sigue siendo el último responsable de demostrar el cumplimiento de PCI DSS. Algunos proveedores pagan a QSA para que revisen sus soluciones y publiquen documentos técnicos, pero incluso esto no garantiza por completo el cumplimiento para cada comerciante individual.
Aplicaciones web renderizadas en el servidor frente a aplicaciones de página única:
Las aplicaciones renderizadas en el servidor tradicionales cargan una nueva página desde el servidor cada vez que se hace clic en un elemento. Por ejemplo: un portal de banca en línea donde cada clic (por ejemplo, consultar saldos) recarga una página completamente nueva desde los servidores del banco.
Las aplicaciones de página única (SPA), en cambio, se cargan una sola vez y dependen de JavaScript para actualizar el contenido de forma dinámica. Por ejemplo: un proceso de pago de comercio electrónico desarrollado en React donde la página nunca se recarga completamente; en su lugar, los formularios, los detalles del producto y los campos de pago se actualizan dinámicamente en el navegador. Las aplicaciones de página única han experimentado un auge a medida que más sitios web se desarrollan con frameworks de desarrollo web como React, Angular y Vue.
