Resumen: qué es el formjacking
- JavaScript inyectado en un formulario para robar lo que los usuarios escriben antes del submit. Campos de tarjeta, credenciales o PII.
- Corre en el navegador después de que la página se sirve. Tu WAF y logs de origen no ven nada. El script comprometido está dentro de un dominio permitido de confianza.
- Ruta de cumplimiento: inventario de scripts 6.4.3 y detección de manipulación 11.6.1. Ruta técnica: monitoreo en sesión.
Cómo funciona el formjacking
Un ataque de formjacking sigue cuatro pasos.
El diagrama sigue una compra (shop.example[.]com/checkout) a través de cinco etapas, y muestra por qué una vista a nivel de red queda ciega mientras una vista a nivel de navegador lo detecta:
| Etapa | Qué ocurre en el navegador | Qué ve el servidor / la CSP |
|---|---|---|
| 1. Página de checkout | El comprador escribe el número de tarjeta + CVV en el formulario real | Carga de página normal |
| 2. Script de proveedor manipulado | widget.js (modified) se carga como cualquier otra etiqueta de terceros | Una URL de script permitida y ya de confianza |
| 3. Skimmer del formulario | El listener inyectado se engancha a cada campo de entrada y lee las pulsaciones en tiempo real | Nada, ninguna petición al servidor |
| 4. Endpoint de exfiltración | Copia codificada enviada a cdn-metrics[.]example mediante POST /collect?d=eyJjYyI6…, disfrazada de baliza de analítica | Parece tráfico de analítica corriente |
| 5. Atacante | Las tarjetas robadas se revenden o se usan para fraude con tarjetas; el pago real igual se completa | Sin anomalía, la transacción tiene éxito |
La capa de red queda ciega porque la petición de exfiltración sale del navegador directamente al dominio del atacante. cside observa la capa del navegador, de modo que el listener inyectado y la baliza saliente se detectan donde realmente se ejecutan.
1. Introducir código en la página. El atacante coloca JavaScript en la página objetivo, casi siempre sin que el propietario del sitio lo sepa. La ruta más habitual es comprometer un script de terceros -una etiqueta de analítica, un widget de chat, una herramienta de A/B testing o una biblioteca de pagos- de modo que el skimmer llega empaquetado dentro del código en el que el sitio ya confía y que carga en cada compra.
2. Engancharse a los campos del formulario. Una vez que el script se carga, adjunta listeners de eventos al formulario de pago o de inicio de sesión. Un listener sobre el evento input se activa en cada pulsación de tecla; uno sobre el evento submit se activa cuando el usuario hace clic en pagar. El script también puede leer directamente los valores del DOM una vez que los campos están rellenos.
3. Copiar los datos. El listener captura los valores de los campos -número de tarjeta, caducidad, CVV, dirección de facturación- exactamente tal como los ha introducido el usuario. El propio formulario no se modifica. La transacción del usuario sigue procesándose a través del procesador de pagos legítimo.
4. Exfiltrar. Los datos robados se codifican y se envían a un dominio controlado por el atacante, a menudo camuflados como un ping de analítica o una solicitud de imagen para que se confundan con el tráfico saliente normal de la página. La mayoría de las cabeceras de Content Security Policy no bloquean esto porque el atacante utiliza un dominio que la política ya permite o aprovecha un hueco existente.
Cómo consiguen los atacantes introducir código de formjacking en tu sitio
El formjacking no requiere una brecha directa en tus servidores. Las tres rutas de entrega más habituales:
Compromiso de scripts de terceros. La mayoría de las páginas de pago y comercio electrónico cargan entre 20 y 60 scripts de terceros: plataformas de analítica, herramientas de chat, gestores de etiquetas, bibliotecas de pagos, widgets de proveedores de marketing. Cualquiera de esos proveedores es una superficie de ataque. Si el atacante compromete el CDN o la infraestructura del proveedor, todos los sitios que cargan ese script reciben el skimmer. La brecha de British Airways en 2018 puso en riesgo los datos personales de 429.612 clientes tras la modificación del JavaScript en el flujo de pago de la aerolínea. Los investigadores vincularon el ataque a actores de amenaza de Magecart que utilizaron un script de proveedor externo comprometido, no una brecha directa en los propios servidores de British Airways. (Wikipedia: Violación de datos de British Airways)
Dominios caducados o secuestrados. Los sitios a veces cargan scripts desde dominios de terceros que ya han caducado o cambiado de propietario. Un atacante que registra ese dominio puede entonces servir cualquier JavaScript que desee a todos los sitios que siguen cargando la etiqueta de script antigua. Como la URL no ha cambiado y el dominio servía previamente código legítimo, ninguna comprobación automática lo señala de inmediato.
Inyección directa de código. Si el atacante explota una vulnerabilidad en el CMS, el panel de administración o un plugin del sitio, puede inyectar el script de formjacking directamente en los propios archivos del sitio. Esta vía requiere mayor acceso pero no deja ninguna dependencia externa que rastrear.
Qué tiene en el punto de mira el formjacking
Los atacantes priorizan las páginas que recopilan datos de alto valor con poca fricción:
| Tipo de página | Datos capturados habitualmente |
|---|---|
| Pago en comercio electrónico | Número de tarjeta, caducidad, CVV, dirección de facturación |
| Registro de cuenta | Correo electrónico, contraseña, nombre, dirección postal |
| Páginas de inicio de sesión | Nombre de usuario y contraseña |
| Formularios sanitarios | Número de seguro, fecha de nacimiento, información médica |
| Solicitudes de cuentas financieras | NIF/NIE, ingresos, datos de cuenta bancaria |
Las páginas de pago son el objetivo principal porque los datos de tarjetas tienen un mercado de reventa inmediato. Las credenciales de inicio de sesión son la segunda prioridad porque permiten la toma de control de cuentas en plataformas con métodos de pago almacenados.
Por qué las herramientas de seguridad tradicionales no detectan el formjacking
Los firewalls de aplicaciones web protegen el tráfico que llega a tu servidor. Los datos del formjacking salen del navegador directamente a un dominio del atacante: el WAF nunca los ve.
Los escáneres del lado del servidor inspeccionan el código en reposo en tu origen. Un script de terceros comprometido se carga desde el CDN de un proveedor en tiempo de ejecución, por lo que nunca está en tu servidor para ser analizado.
Las revisiones manuales periódicas comprueban los scripts listados en tu gestor de etiquetas o repositorio de código. Un skimmer inyectado en un script de terceros entre ciclos de revisión es invisible hasta que alguien realice la siguiente auditoría, a menudo semanas después.
La Integridad de Subrecursos (SRI) protege los scripts que se procesan con hash en el momento del despliegue. No puede proteger los scripts cargados desde CDNs controlados por proveedores donde el atacante tiene acceso de escritura, ni los scripts generados dinámicamente por solicitud.
Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 existen porque el sector reconoció esta brecha. El inventario de scripts y la monitorización continua de manipulaciones en páginas de pago se convirtieron en obligatorios el 1 de abril de 2025. (PCI Security Standards Council)
Los skimmers también eluden activamente los escáneres. La mayoría comprueban navigator.webdriver -que devuelve true en navegadores headless automatizados- y sirven código limpio a las herramientas de seguridad mientras ejecutan el skimmer completo para los usuarios reales.
Cómo detectar el formjacking
Detectar el formjacking requiere visibilidad sobre lo que JavaScript hace en tiempo de ejecución en los navegadores de los visitantes reales. Las señales específicas a monitorizar:
- Scripts nuevos o modificados en páginas sensibles. Un script que no estaba presente el día anterior, o cuyo contenido cambió fuera de una ventana de despliegue programada, es el primer indicador.
- Listeners de eventos inesperados en campos de formulario. El código legítimo adjunta listeners
submitpara procesar formularios. Un listener en los eventosinput,keydownokeyupsobre campos de pago o credenciales, añadido por un script de terceros, es una señal característica del formjacking. - Datos salientes hacia dominios no listados. Cualquier solicitud de red desde una página de pago hacia un dominio que no figure en tu lista permitida aprobada requiere investigación inmediata.
- Cargas codificadas en solicitudes salientes. Los atacantes de formjacking codifican los datos robados -a menudo en base64- antes de enviarlos. Un beacon que contiene un parámetro codificado inusualmente largo que no se corresponde con ningún evento de analítica conocido es una señal de alerta.
La restricción clave es que solo la monitorización dentro del navegador puede ver estas señales de forma real. Los escáneres que operan desde el exterior no detectan el formjacking que se oculta de los usuarios reales.
Cómo prevenir el formjacking
Ningún control único elimina todas las vías de formjacking. Combinar varios controles reduce significativamente la superficie de ataque:
-
Inventariar todos los scripts en páginas sensibles. Conocer cada script propio y de terceros que se carga en las páginas de pago e inicio de sesión, quién lo autorizó y por qué está ahí. Los scripts no reconocidos no deben cargarse.
-
Monitorizar los cambios de forma continua. Un script que cambia entre ciclos de auditoría es una brecha no detectada. La monitorización continua de manipulaciones -obligatoria bajo el requisito 11.6.1 de PCI DSS 4.0.1- detecta los cambios en minutos en lugar de semanas.
-
Aplicar SRI donde sea práctico. Para los scripts que controlas completamente y versionas tú mismo, los hashes SRI verifican que el script no ha cambiado desde el despliegue. SRI no funciona para scripts de terceros que se actualizan con frecuencia o que se generan dinámicamente por solicitud.
-
Configurar la Content Security Policy de forma restrictiva. Una CSP estricta limita a qué dominios pueden enviar datos los scripts, reduciendo los destinos de exfiltración de un skimmer. En la práctica, las páginas de pago suelen necesitar permitir muchos dominios para la analítica legítima y la funcionalidad de pago, lo que dificulta un bloqueo completo.
-
Desplegar monitorización client-side de visitantes reales. La defensa más directa es la monitorización que observa lo que hace cada script en navegadores reales, no un escáner que ejecuta solicitudes sintéticas desde el exterior. Este es el enfoque de cside.
Cómo detecta cside el formjacking en navegadores reales
cside se despliega como un único snippet de JavaScript propio que monitoriza el comportamiento de los scripts en los navegadores de visitantes reales, no un rastreador o escáner que opera desde el exterior.
Para el formjacking, cside detecta:
- Listeners de eventos adjuntados a campos de formulario por scripts de terceros, con especial atención a los listeners que se activan en pulsaciones de teclas en lugar de en el envío del formulario
- Solicitudes de datos salientes hacia dominios que no figuran en la lista permitida aprobada del sitio
- Scripts nuevos que aparecen en páginas de pago o inicio de sesión fuera de una ventana de despliegue
- Cambios en scripts existentes, incluidas modificaciones en tiempo de ejecución en la salida cargada de una etiqueta de proveedor
Como cside opera en la capa del navegador junto al ataque, detecta el skimmer cuando se produce, antes de que los datos hayan sido ya exfiltrados. Para las organizaciones sujetas a PCI DSS 4.0.1, PCI Shield mapea esta monitorización a los requisitos 6.4.3 (inventario y autorización de scripts) y 11.6.1 (detección de manipulaciones), generando informes listos para el QSA de forma continua.
Para el contexto sobre cómo el formjacking se relaciona con el ecosistema más amplio del skimming digital y los grupos de amenaza Magecart, consulta la guía complementaria: Formjacking vs Magecart vs digital skimming.
Reserva una demo para ver lo que cside encuentra ejecutándose en tus páginas de pago, o lee más sobre la prevención del e-skimming.
