Nuestra página de comparación muestra una excelente descripción general de los diferentes enfoques para lograr 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 muchos competidores en este espacio utilizan. Los beneficios y las muchas deficiencias que vienen con esta solución.
En este artículo nos enfocaremos en la sección 6.4.3 y 11.6.1 de PCI DSS 4.0.1. Visita nuestra página de comparación para obtener los beneficios completos y las 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 justificación comercial o técnica por escrito de por qué cada uno es necesario.
El requisito PCI 6.4.3 requiere 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 GRC, es un desafío asignar esfuerzos de ingeniería a los requisitos de cumplimiento. Comprender cómo los requisitos de PCI de seguridad del lado del cliente se traducen en implementación práctica es a menudo donde los equipos se atascan. Algunas soluciones pueden llevarte a creer que puedes cumplir con los requisitos sin implementar ningún código o hacer ningún ajuste. Sin embargo, eso no es correcto.
Este requisito se puede lograr de varias maneras. Un comerciante puede implementar una Política de Seguridad de Contenido. Sin embargo, se sabe que CSP es difícil de gestionar y mantener, pero es una solución válida para cumplir con este requisito.
Un comerciante puede optar por usar un agente del lado del cliente que bloquee algunos comportamientos de JS. Sin embargo, eso no es una solución mágica. Ha habido varios ejemplos de ataques del lado del cliente que esencialmente detuvieron el funcionamiento del agente de seguridad y deshabilitaron total o parcialmente su funcionalidad, incluida la capacidad de bloqueo. Por lo tanto, siempre prueba la solución que adquieres con un script del lado del cliente escrito por ti mismo. Desafortunadamente, la mayoría de los ingenieros de JavaScript de nivel medio no encontrarán esto como un desafío importante.
O puedes usar un servicio de proxy como cside para detener un script malicioso desde que se sirva en primer lugar.
Esta línea específica de los requisitos de PCI DSS se pasa por alto fácilmente, pero se remonta a la naturaleza del requisito: implementar estándares de seguridad de tarjetas de pago para evitar que las tarjetas de crédito sean robadas al momento de ingresarlas.
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 simples, siendo uno de ellos provenir de la dirección IP de un proveedor de nube. Este es un defecto de diseño fundamental, porque la entrega de JavaScript es dinámica por diseño. Está construido para servir diferentes versiones de scripts basadas en tiempo, user-agent, ubicación, 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 lo tanto, la inteligencia de amenazas debe provenir de otras fuentes. Aquí es donde la mayoría de las soluciones compran inteligencia de feeds de amenazas de proveedores. Sin embargo, estos proveedores tienden a llegar tarde al espectáculo. Cuando ocurrió el ataque de Polyfill, tomó más de 30 horas para que cualquier proveedor de amenazas lo marcara, a pesar de que tuvo una amplia cobertura de prensa. El dominio solo se marcó cuando Namecheap ya había eliminado el dominio. Los proveedores de feeds de amenazas tampoco están específicamente buscando ataques del lado del cliente, a veces los capturan pero igualmente los actores maliciosos saben cómo evitar a sus investigadores. La mayor parte de su inteligencia de ataques del lado del cliente se origina en las redes sociales.
Hemos establecido que un crawler no puede garantizar que la carga útil que obtiene sea la que recibió el usuario, pero imaginemos por un segundo que lo es. La mayoría de los scripts maliciosos se cargan como sub-solicitudes basadas en activadores del usuario: el usuario hace clic, se desplaza, inicia sesión o agrega algo a un carrito.
Si un script malicioso se inyecta debido a una interacción del usuario, el crawler no verá el script malicioso a menos que realice esa interacción del usuario. Esto es bastante imposible de hacer ya que cada página puede tener infinitas capacidades de interacción. Ejemplo: solo hacer la solicitud al script malicioso si se presiona una serie de botones 5 veces, se desplaza una ventana completa hacia abajo, el navegador no tiene las herramientas de desarrollo abiertas... El "rastreo sintético" afirma abordar esto, pero realmente no puede por razones técnicas obvias.
Si aplicas un enfoque de análisis de seguridad estático a un problema dinámico, no abordas la preocupación 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 útil maliciosa de primera mano a través del crawler pero puede marcar el script padre a través de otros métodos de detección activa fuera del 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 de scripts maliciosos recibida a través de los sitios web proxy de otros clientes de cside. Como resultado, las cargas útiles maliciosas se detectan en otros sitios y los objetos padre que inyectaron esos scripts maliciosos se marcan, si el crawler recibió la carga útil limpia pero sabe que ese script está comprometido a través de otros sitios, eso generará una alerta.
"Espera, ¿pero veo todos estos datos interesantes en su panel?"
Esto es definitivamente un valor agregado. Los crawlers pueden darte una comprensión de algunos de los comportamientos de algunos de los scripts en tu sitio poblando el panel, proporcionando información interesante. Pero cualquier script malicioso sabrá cómo no aparecer en esos paneles. Generalmente, las personas tienen un sesgo por los objetos brillantes. Un panel brillante con mucha información interesante lleva a las personas a pensar que la misma información estará disponible en un mal día. Sin embargo, ese no es el caso.
¿Por qué considerar un crawler en absoluto?
La seguridad se trata de capas. Agregar más soluciones para monitorear los mismos problemas suele ser algo bueno.
Son relativamente ligeros de implementar (generalmente) 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 verificaciones periódicas o auditorías que no son susceptibles a PCI DSS, eso es útil.
También proporcionan visibilidad de los cambios estáticos. Digamos que si una nueva URL de script aparece repentinamente o una existente desaparece. En ese aspecto, es un paso adelante de CSP que no proporciona ninguna visibilidad de carga útil. Lee sobre las limitaciones de los CSP aquí. Un crawler puede ayudarte a mantener un inventario de scripts (parte de 6.4.3) y ver encabezados de seguridad cuando rastrea (PCI 11.6.1), pero no puede evitar que se carguen scripts no autorizados. Al menos aún necesitarías agregar CSP o un agente. Así que solo compra un crawler si también te da un endpoint de CSP o un agente.
Un crawler por sí solo no puede proporcionarte cumplimiento de PCI DSS.
