Qué es un skimmer en PrestaShop y cómo detectarlo antes que tus clientes
ShopyPresta · Actualizado · 5 min de lectura
Un skimmer es el ataque más rentable y más silencioso que puede sufrir una tienda online: un fragmento de código que copia los datos de la tarjeta mientras el cliente los escribe en el checkout y los envía a un servidor del atacante. El pedido se procesa con normalidad, el cliente recibe su pedido y nadie nota nada hasta que, semanas después, empiezan los cargos fraudulentos. En PrestaShop es, con diferencia, la infección más grave que limpiamos. Esto es lo que hay que saber para detectarlo y evitarlo.
¿Qué es exactamente un skimmer?
El nombre viene de los dispositivos que se pegaban a los cajeros para copiar la banda magnética. El skimmer web hace lo mismo con el formulario de pago: un código JavaScript inyectado en la página del checkout que escucha lo que el cliente escribe (número de tarjeta, caducidad, código de seguridad, nombre) y lo envía a otro dominio antes de que el pago llegue a la pasarela. Como no interfiere con el pago real, la tienda sigue cobrando y enviando pedidos. Estas campañas se conocen también como Magecart, por el grupo que las popularizó.
¿Cómo entra un skimmer en una PrestaShop?
Por tres vías, casi siempre. La primera y más habitual es un módulo con una vulnerabilidad conocida que permite subir o escribir archivos; en los últimos años, varios módulos muy extendidos han tenido fallos de este tipo. La segunda es una versión de PrestaShop sin parches, sobre todo la rama 1.6. La tercera, credenciales filtradas: contraseñas reutilizadas del panel, de FTP o del hosting que aparecen en alguna filtración y se prueban en masa. Una vez dentro, el atacante modifica un archivo JavaScript del tema o de un módulo, o inyecta el código en la base de datos (en la configuración de un módulo o en un bloque de contenido), que es más difícil de ver.
¿Por qué no lo ves al revisar la tienda?
Porque está diseñado para que no lo veas. Los skimmers actuales solo se activan en la página de pago, a veces solo cuando el formulario de tarjeta recibe datos, y comprueban que no haya herramientas de desarrollador abiertas. Muchos no se activan si detectan que el visitante es administrador. El código suele estar ofuscado y a veces se carga desde un dominio parecido al de un servicio legítimo (una analítica, una fuente, una CDN), para que una revisión rápida no lo distinga.
¿Cómo detectar un skimmer en tu tienda?
- Escucha a tus clientes. Varios cargos fraudulentos tras comprar en tu tienda, en semanas cercanas, son la señal más fiable. Tómala en serio desde la primera queja.
- Revisa qué carga el checkout. Con las herramientas de desarrollador del navegador, en la pestaña de red, mira a qué dominios se conecta la página de pago. Cualquier dominio que no reconozcas es sospechoso, sobre todo si recibe peticiones al escribir en el formulario.
- Compara los archivos del tema y de los módulos con los originales. Un archivo JavaScript modificado hace poco en una tienda que no se ha tocado es un indicio claro.
- Busca código inyectado en la base de datos. Bloques de contenido, configuraciones de módulos y campos de texto largos pueden contener scripts.
- Comprueba los accesos. Administradores, cuentas FTP y usuarios de base de datos que no reconoces.
Nuestro escáner gratuito de PrestaShop detecta módulos con vulnerabilidades conocidas y versiones sin soporte, que son las puertas de entrada; el skimmer en sí solo se confirma revisando el servidor.
¿Qué hago si confirmo que hay un skimmer?
Primero, corta la fuga: desactiva el método de pago afectado o pon el checkout en mantenimiento. Es preferible perder un día de ventas que seguir entregando tarjetas. Segundo, cambia todas las contraseñas (panel, hosting, FTP, base de datos). Tercero, no restaures una copia sin saber de qué fecha es la infección: puedes volver a instalar el skimmer. Cuarto, guarda evidencias (registros, fechas de archivos) y pide una limpieza profesional: localizar todas las copias del código, encontrar el punto de entrada y cerrarlo. Quinto, valora las obligaciones legales: si se han filtrado datos de pago, hay que notificar la brecha a la autoridad de protección de datos y, según el caso, a los afectados y a tu pasarela.
¿Cómo evitar que entre?
- Mantén PrestaShop y los módulos actualizados, en un entorno de pruebas primero. La mayoría de los skimmers entran por una vulnerabilidad publicada semanas antes.
- Desinstala los módulos que no uses y evita los que llevan años sin actualizarse.
- Contraseñas únicas y doble factor en el panel; acceso al panel limitado por IP si es posible.
- Monitorización de integridad: que algo te avise cuando cambia un archivo de la tienda.
- Una política de seguridad de contenido (CSP) en el checkout que solo permita cargar scripts desde dominios conocidos. No es trivial de configurar, pero deja ciegos a muchos skimmers.
- Si tu pasarela lo permite, usa un formulario de pago alojado por la pasarela (redirección o iframe): los datos de la tarjeta nunca pasan por tu tienda.
Todo esto es parte de un mantenimiento de PrestaShop serio, y es la razón por la que lo recomendamos antes que cualquier otro servicio. Si quieres saber cómo de expuesta está tu tienda, haz el test de riesgo.
Preguntas frecuentes
¿Mi pasarela de pago no me protege de esto?
La pasarela protege la transacción, no tu página. El skimmer actúa antes, en el formulario que ve el cliente. Si la pasarela aloja el formulario fuera de tu tienda, el riesgo baja mucho.
¿Cuánto tiempo suele estar activo un skimmer antes de detectarse?
En nuestra experiencia, entre uno y tres meses. Los cargos fraudulentos tardan en aparecer y en relacionarse con la tienda.
¿Puede volver después de limpiarlo?
Si solo se borra el código y no se cierra el punto de entrada, sí, en días. Por eso una limpieza seria incluye encontrar cómo entró y una garantía.
¿Afecta también a tiendas Shopify?
Shopify aloja el checkout en su propia infraestructura y los datos de pago no pasan por el tema, así que el skimmer clásico no aplica. El riesgo en Shopify está en apps y scripts de terceros mal elegidos, no en el servidor.