Resumen: limitaciones del crawler para la integridad de scripts en PCI DSS 4.0.1
- Los crawlers no ven el JS dinámico: Los crawlers parecen grandes herramientas de cumplimiento hasta que recuerdas que JavaScript es dinámico por diseño. Un visitante sintético desde una IP de nube conocida que nunca hace clic, hace scroll ni inicia sesión es lo último que un atacante le enseñaría con la carga maliciosa.
- Demasiado lento, no bloquea: Durante el ataque a Polyfill, ningún proveedor de amenazas marcó el dominio hasta pasadas más de 30 horas, y esa marca solo llegó después de que Namecheap ya lo hubiera dado de baja. Un crawler por sí solo no puede cumplir con 6.4.3 porque no puede bloquear scripts no autorizados, y las comprobaciones estáticas de URLs contra feeds de amenazas no satisfacen el requisito de integridad de payload de 11.6.1.
- Añade bloqueo o usa cside: Si hoy solo cuentas con un crawler, añade CSP o un script del lado del cliente capaz de bloquear cargas y mostrar contenidos, para que 6.4.3 se cumpla de verdad. Si prefieres una sola solución en lugar de combinar dos, cside analiza cada script en nuestro lado e impide que los scripts maliciosos lleguen a servirse.
¿Poco tiempo? Consulta cside PCI Shield. Cubre todo lo de abajo en un solo despliegue.
Nuestra página de comparación ofrece una visión general de los distintos enfoques para lograr la seguridad del lado del cliente y cumplir con los requisitos de PCI DSS (6.4.3 y 11.6.1).
Nuestra solución (el proxy híbrido) supera a otros enfoques en varias categorías. Comparémosla con el crawler que utilizan muchos competidores en este espacio. Los beneficios y las muchas carencias que conlleva esta solución.
En este artículo nos centraremos en las secciones 6.4.3 y 11.6.1 de PCI DSS 4.0.1. Visita nuestra página de comparación para conocer todos los beneficios y desventajas en un contexto de seguridad completo.
"Se implementa un método para confirmar que cada script está autorizado"
6.4.3 Todos los scripts de la página de pago que se cargan y ejecutan en el navegador del consumidor se gestionan de la siguiente manera:
Se implementa un método para confirmar que cada script está autorizado.
Se implementa un método para asegurar la integridad de cada script.
Se mantiene un inventario de todos los scripts con una justificación comercial o técnica por escrito de por qué cada uno es necesario.
El requisito PCI 6.4.3 exige un mecanismo para evitar que se carguen scripts no autorizados.
Para eliminar cualquier confusión, la especificación PCI también establece:
El código no autorizado no puede ejecutarse en la página de pago tal como se renderiza en el navegador del consumidor.
Para muchos equipos de GRC, es un desafío destinar esfuerzos de ingeniería a los requisitos de cumplimiento. Traducir los requisitos de PCI de seguridad del lado del cliente a una implementación práctica es, a menudo, donde los equipos se atascan. Algunas soluciones pueden hacerte creer que puedes cumplir con los requisitos sin implementar ningún código ni hacer ningún ajuste. Sin embargo, eso no es correcto.
Este requisito se puede lograr de varias maneras. Un comercio puede implementar una Política de Seguridad de Contenido. Sin embargo, se sabe que CSP es difícil de gestionar y mantener, aunque es una solución válida para cumplir con este requisito.
Un comercio puede optar por usar un agente del lado del cliente que bloquee ciertos comportamientos de JS. Sin embargo, eso no lo resuelve todo. Ha habido ataques del lado del cliente que han detenido el funcionamiento de agentes de seguridad, deshabilitando su funcionalidad (incluida la capacidad de bloqueo) total o parcialmente. Por eso, prueba siempre la solución que adquieras con un script del lado del cliente escrito por ti mismo. Por desgracia, para la mayoría de los ingenieros de JavaScript de nivel medio esto no supondrá un gran reto.
O bien, puedes usar una capa de análisis de scripts como cside para impedir que un script malicioso llegue a servirse.
Esta línea concreta de los requisitos de PCI DSS se pasa por alto con facilidad, pero se remonta a la naturaleza del propio requisito: implementar estándares de seguridad de tarjetas de pago para evitar que se roben tarjetas de crédito en el punto de entrada.
Los crawlers no "ven" la carga útil real y no capturarán un ataque serio
Los crawlers funcionan visitando tu sitio e indexando qué scripts se cargan. Detalle importante: actúan como un usuario, pero claramente no son un usuario humano real. Hay varios indicadores sencillos que lo delatan, como provenir de la dirección IP de un proveedor de nube. Se trata de un fallo fundamental, porque la entrega de JavaScript es dinámica por diseño. Está construida para servir diferentes versiones de scripts según la hora, el user-agent, la ubicación, los rangos de IP…
Los actores maliciosos, por supuesto, aprovechan esa dinámica para evitar la detección. Es poco probable que un crawler detecte el ataque real de primera mano. Por eso, la inteligencia de amenazas debe provenir de otras fuentes. Aquí es donde la mayoría de las soluciones compran inteligencia de feeds de amenazas a proveedores. Sin embargo, estos proveedores suelen llegar tarde. Cuando ocurrió el ataque de Polyfill, ningún proveedor de amenazas lo marcó hasta pasadas más de 30 horas, a pesar de la amplia cobertura de prensa que tuvo. El dominio solo se marcó cuando Namecheap ya lo había dado de baja. Los proveedores de feeds de amenazas tampoco están específicamente atentos a los ataques del lado del cliente. A veces los detectan, pero los actores maliciosos también saben cómo evitar a sus investigadores. La mayor parte de su inteligencia sobre ataques del lado del cliente se origina en redes sociales.
Ya hemos establecido que un crawler no puede garantizar que la carga útil que obtiene sea la misma que recibió el usuario, pero imaginemos por un momento que sí lo es. La mayoría de los scripts maliciosos se cargan como subsolicitudes activadas por acciones del usuario: hacer clic, hacer scroll, iniciar sesión o añadir algo al carrito.
Si un script malicioso se inyecta debido a una interacción del usuario, el crawler no lo verá a menos que realice esa misma interacción. Esto es prácticamente imposible, ya que cada página puede tener infinitas posibilidades de interacción. Ejemplo: hacer la solicitud al script malicioso solo si se pulsa una serie de botones 5 veces, se hace scroll una pantalla completa hacia abajo, y el navegador no tiene las herramientas de desarrollo abiertas… El "rastreo sintético" dice abordar esto, pero en realidad no puede hacerlo por razones técnicas obvias.
Si aplicas un enfoque de análisis de seguridad estático a un problema dinámico, no resuelves el problema de seguridad.
Entonces, ¿todos los crawlers son inútiles?
No. El concepto fundamental de un crawler es defectuoso, pero si un proveedor no espera ver la carga maliciosa de primera mano a través del crawler, sino que puede marcar el script padre mediante otros métodos de detección activa ajenos al crawler, aún puede abordar las preocupaciones de seguridad a un nivel suficientemente alto (para algunos). Por ejemplo: el crawler de cside utiliza la inteligencia sobre scripts maliciosos recibida a través de los sitios web analizados de otros clientes de cside. Como resultado, cside detecta cargas maliciosas en otros sitios y marca los objetos padre que inyectaron esos scripts. Si el crawler recibió la carga limpia pero sabe, a través de otros sitios, que el script está comprometido, eso sigue generando una alerta.
"Espera, ¿pero veo todos estos datos interesantes en su panel?"
Esto es sin duda un valor añadido. Los crawlers pueden mostrarte algunos de los comportamientos de los scripts en tu sitio, poblando el panel con datos genuinamente interesantes. Pero cualquier script malicioso sabrá cómo evitar aparecer en esos paneles. Por lo general, las personas tienen un sesgo hacia lo llamativo. Un panel vistoso con mucha información interesante lleva a pensar que esa misma información estará disponible en un mal día. Sin embargo, no es el caso.
¿Por qué considerar un crawler siquiera?
La seguridad se trata de capas. Añadir más soluciones para vigilar los mismos problemas suele ser algo positivo.
Son relativamente ligeros de implementar (por lo general) y te dan un mapa básico de qué scripts están presentes en tu sitio en un momento dado. Para un equipo de cumplimiento que realiza comprobaciones periódicas o auditorías no sujetas a PCI DSS, eso resulta útil.
También aportan visibilidad sobre cambios estáticos: por ejemplo, si aparece de repente una nueva URL de script o desaparece una existente. En ese aspecto, es un paso por delante de CSP, que no ofrece ninguna visibilidad de la carga útil. Lee aquí sobre las limitaciones de los CSP. Un crawler puede ayudarte a mantener un inventario de scripts (parte de 6.4.3) y a revisar cabeceras de seguridad cuando rastrea (PCI 11.6.1), pero no puede impedir que se carguen scripts no autorizados. Aun así, necesitarías añadir CSP o un agente. Así que solo compra un crawler si además te ofrece un endpoint de CSP o un agente.
Un crawler por sí solo no puede darte cumplimiento con PCI DSS.
