El skimmer de Convertr: la dependencia que no aparece en tu lockfile

El 26 de octubre, Sansec informó de un skimmer en el script analítico compartido de Convertr. El 27 confirmó su retirada. El acceso inicial sigue sin confirmarse. Investigación.

La pregunta de seguridad va más allá del paquete vulnerable. ¿Qué código llega a tu página de pago sin pasar por la revisión de dependencias de la aplicación? Un repositorio limpio no basta para responder.

Amplía el inventario al navegador

Empieza con una página crítica y un recorrido de usuario sintético. Registra los scripts del documento inicial, del gestor de etiquetas y de la navegación posterior. Repite el recorrido con las opciones de consentimiento pertinentes. No recopiles datos de clientes para elaborar ese registro.

Para cada script, conserva la URL completa, el componente iniciador, la finalidad, el responsable, el mecanismo de actualización y, cuando corresponda, el resumen criptográfico del contenido aprobado. Distingue un archivo integrado en la aplicación de una URL cuyo contenido cambia por separado. Documenta lo desconocido en lugar de considerar aprobado cualquier dominio conocido.

Modelo de control original, no una reconstrucción del despliegue de Convertr. Las etiquetas en inglés identifican responsabilidades de revisión, no volumen de ataques.

Esta vista del navegador complementa nuestro proceso de verificación de runtimes integrados. Ambos inventarios deben compartir responsables y evidencias, sin sustituirse entre sí de forma implícita.

Un host permitido no equivale a un archivo aprobado

Permitir un host indica desde dónde puede cargar código el navegador. No demuestra que el archivo actual sea el revisado. Content Security Policy y Subresource Integrity cubren controles distintos. Consulta las referencias de script-src e integridad de MDN.

Comprueba esa diferencia en un entorno controlado. Sirve un archivo inerte desde un origen de pruebas propio, aprueba el contenido esperado y después modifícalo. Observa qué bloquea realmente el navegador. No sustituyas un archivo analítico de producción para demostrarlo.

Para un recurso externo estable, considera un atributo de integridad con un resumen aprobado y la configuración entre orígenes necesaria. Define cómo se aprueba un nuevo resumen cuando hay una actualización intencionada. Un recurso que cambia continuamente o un cargador que obtiene más scripts necesita otro diseño operativo. No presupongas que un ejemplo de integridad cubre lo que se carga después.

Con CSP, parte de un inventario y revisa las infracciones con tráfico sintético. El modo de solo informe mide las restricciones propuestas; no las aplica. Prueba la política aplicada con el recorrido de pago real antes de confiar en ella. Conserva las cabeceras efectivas y la observación del navegador, no solo el archivo de configuración.

Convierte la responsabilidad en decisiones comprobables

Cada excepción debe tener alguien que explique por qué ese script pertenece a la página de pago. Pregunta qué se rompe al retirarlo, si puede ejecutarse en otra página y qué destinos necesita. Son cuestiones de diseño para tu aplicación, no afirmaciones sobre otro comercio.

La tabla propone un acuerdo de revisión. No describe los controles de Convertr ni promete que un control evite cualquier skimmer.

Separa la respuesta a incidentes de una recarga limpia

Si tus evidencias indican un incidente, conserva fechas, archivos y registros de despliegue antes de alterarlos. Tu proceso de respuesta debe decidir conservación, contención y notificaciones. Excluye los datos de pago de los registros diagnósticos ordinarios.

Tras un cambio aprobado, verifica la página que reciben los usuarios: redirecciones, cachés, iniciadores de scripts y política resultante. Ejecuta el pago legítimo con medios de prueba autorizados. Una petición de recurso satisfactoria aporta evidencia de entrega; no completa una investigación.

Nuestra guía de límites de privilegios explica por qué una operación permitida no prueba que fallen todas las prohibidas. El análisis de agentes y cadena de suministro aplica una lección relacionada a otra entrada de código en el desarrollo.

Evalúa el flujo con Plexicus y evidencias

Plexicus presenta AI Swarm Pentest como una evaluación acotada de aplicaciones y API con evidencias revisables. Su flujo de remediación ofrece cambios revisados y nuevas pruebas. Aporta el inventario de scripts, un recorrido sintético y las preguntas concretas sobre la política.

Acuerda si el comportamiento del navegador, los destinos externos y los cambios de scripts quedan dentro del alcance autorizado. Estas descripciones no prometen vigilancia continua de skimmers, cobertura automática de todos los gestores de etiquetas ni reproducción de este incidente.

El resultado útil identifica despliegue, comportamiento observado, responsable y nueva prueba. Mantén visibles las dudas sobre proveedores para que el equipo pueda explicar y verificar cada decisión.

Fuentes

• Sansec: investigación y actualización del 27 de octubre.
• MDN: Subresource Integrity.
• MDN: CSP script-src.

¿Quieres revisar un flujo de pago crítico? Contacta con Plexicus con el alcance autorizado, el inventario y un recorrido sintético.