DataFirefly Skimming Guard: anti-skimming e integridad de archivos

Presentación

DataFirefly Skimming Guard vigila el código servido a los clientes de su tienda PrestaShop 8 o 9: los archivos, la base de datos, el HTML enviado en las páginas de pago y lo que hace el navegador en el checkout. Detecta los scripts inyectados que copian números de tarjeta (ataques de tipo Magecart), los archivos modificados o añadidos y los archivos del núcleo de PrestaShop que difieren de la versión oficial. Complementa DataFirefly Admin Shield, que protege el acceso al back office.

Instalación

1. En el back office, abra Módulos > Gestor de módulos > Subir un módulo y envíe dfskimguard-1.2.1.zip.
2. Abra el módulo. También está en Parámetros avanzados > Skimming Guard.
3. Pulse Analizar ahora. El primer análisis registra la referencia de sus archivos: una huella SHA-256 por archivo y una copia de los archivos del tema, las vistas de módulos y los puntos de entrada.
4. Configure la tarea programada (ver más abajo).
5. Envíe una alerta de prueba desde el resumen para comprobar la recepción.

Tarea programada

Los análisis se ejecutan en segundo plano, nunca durante la visita de un cliente. Tres opciones:

• URL cron: copie la URL del bloque Tarea programada y llámela cada 15 minutos desde el gestor cron de su alojamiento. La URL contiene un token secreto.
• Línea de comandos: con acceso SSH, ejecute php modules/dfskimguard/cli.php. La opción --full hace un análisis completo de una vez, sin límite de tiempo.
• Módulo cronjobs de PrestaShop: si lo usa, la tarea se ejecuta cada hora.

Cada ejecución inicia o continúa el análisis de archivos, analiza la base de datos una vez por hora, comprueba el núcleo de PrestaShop una vez por semana y el contenido de los scripts de terceros una vez al día.

Resumen

El banner de cada pestaña muestra una puntuación de seguridad de 0 a 100 y una frase que resume la situación, con accesos directos a lo pendiente. El resumen lista dos grupos de controles, primero los que fallan:

• Configuración de la protección: referencia reciente, tarea programada activa, destinatarios de alertas, fin del aprendizaje, bloqueo de datos de tarjeta, Content Security Policy, comprobación del núcleo, justificación de los scripts de pago.
• Refuerzo de la tienda: modo depuración, carpeta de instalación, nombre de la carpeta admin, archivos peligrosos accesibles (copias SQL o ZIP, phpinfo, adminer, .git, .env, eval-stdin.php de PHPUnit), SSL en todas las páginas, versión de PHP, permisos de los archivos de configuración.

Cada control fallido indica cómo corregirlo.

Protección del checkout

Inspección del HTML servido

En el carrito, el checkout y las páginas de pago de los módulos, el módulo lee el HTML que genera PrestaShop. Registra cada script externo, iframe, destino de formulario y dominio citado en un script en línea, y aplica firmas de código ofuscado (eval(atob(...)), new Function, cadenas fromCharCode, cargadores de scripts, detección de herramientas de desarrollo). Por defecto, cada página se inspecciona como máximo una vez cada 5 minutos. Ajuste el intervalo en los ajustes o vigile todas las páginas de la tienda.

Centinela del navegador

Un script de 5,5 KB se inyecta primero en el <head> de las páginas vigiladas. Señala los dominios desconocidos que contacta la página y, en las páginas de pago, detecta un número de tarjeta válido enviado a un dominio no aprobado, incluso codificado en base64. El número nunca se transmite al servidor. Para filtrar las extensiones del navegador, un dominio desconocido solo alerta tras 3 visitantes distintos (ajustable); un intento de envío de tarjeta alerta desde la primera vez.

Bloqueo de datos de tarjeta

Opción Bloquear los datos de tarjeta enviados a dominios desconocidos: la petición se cancela cuando contiene un número de tarjeta y va a un dominio no aprobado. Actívela cuando termine el periodo de aprendizaje y sus proveedores de pago estén aprobados.

Content Security Policy

El módulo puede enviar una CSP construida con los dominios aprobados en las páginas vigiladas. Empiece con Solo informe y pase a Aplicar cuando no aparezca ningún dominio inesperado.

Periodo de aprendizaje

Durante 48 horas tras la instalación, los scripts y dominios de terceros de bajo riesgo se aprueban sin alerta. Los sospechosos alertan igualmente. Reinicie el aprendizaje tras un cambio de tema o de método de pago con Aprender durante 48 horas.

Dominios de confianza

Una lista integrada cubre los proveedores habituales (Stripe, PayPal, Braintree, Adyen, Mollie, Klarna, Checkout.com, Worldpay, PayPlug, Stancer, Lyra, PayZen, Systempay, Monetico, Alma, Scalapay, SumUp, Redsys, HiPay, Apple Pay, Google Pay, reCAPTCHA, hCaptcha, Turnstile, Google Analytics, Tag Manager, Meta). Añada sus propios dominios en los ajustes, uno por línea; los subdominios están incluidos.

Pestaña Scripts y dominios

La pestaña lista cada elemento visto en sus páginas con su tipo, dominio, página, puntuación de riesgo y número de apariciones. Tres acciones:

• Aprobar: el elemento y su dominio pasan a la lista de confianza (centinela y CSP). Para un script de las páginas de pago, una ventana pide la justificación.
• Malicioso: el centinela bloquea el dominio y la CSP lo excluye. Si reaparece, se envía una alerta crítica.
• Eliminar: quita el elemento del inventario.

Integridad de los archivos

Qué se vigila

Extensiones por defecto: php, phtml, php5, php7, phar, inc, js, mjs, tpl, twig, html, htm, htaccess, ini, svg, ico. Rutas excluidas por defecto: var, cache, img, upload, download, .git, node_modules, cachés del tema y copias de la carpeta admin. El token {admin} se sustituye por el nombre de su carpeta de administración.

Un archivo se considera sin cambios si su tamaño, su fecha de modificación y su fecha de cambio de inodo no se han movido. La fecha de cambio de inodo no se falsifica con touch. Cada 7 días (ajustable) se recalculan todas las huellas.

Firmas

Cada archivo nuevo o modificado pasa por las firmas: web shells conocidos, eval sobre datos decodificados o de la petición, comandos del sistema a partir de la petición, PHP oculto en una imagen o un .ico, include de un archivo multimedia, auto_prepend_file añadido en .htaccess o .user.ini, archivos multimedia ejecutados como PHP, campos de tarjeta leídos y enviados por la red. Un archivo con riesgo 70 o más genera una alerta crítica inmediata; los demás cambios se agrupan en un resumen por análisis.

Pestaña Archivos

• Ver los cambios: diff línea a línea entre la versión aprobada y el archivo actual. En un JS minificado de una sola línea, solo se muestra el fragmento insertado.
• Restaurar la versión aprobada: vuelve a poner la copia de referencia. La versión modificada se conserva en var/dfskimguard/quarantine como prueba.
• Aprobar: acepta el archivo actual como nueva referencia. La selección múltiple y Aprobar todos los cambios sirven tras una actualización.
• Cuarentena: saca de la tienda un archivo nuevo sospechoso. Se puede restaurar.

Ventana de actualización

Antes de actualizar un módulo o el tema, pulse Estoy actualizando mi tienda (2 h). Durante dos horas, los archivos modificados sin código sospechoso pasan a ser la nueva referencia sin alerta. Un archivo de alto riesgo alerta igualmente.

Comprobación del núcleo de PrestaShop

La pestaña Núcleo de PrestaShop descarga la fuente oficial de su versión desde GitHub y compara los archivos PHP, TPL y Twig de classes, controllers, src, config y los archivos PHP de la carpeta admin. Se ignoran los finales de línea y los ajustes que el build de la release y el modo depuración reescriben en config/defines.inc.php. El módulo señala también los archivos PHP inesperados en classes, controllers y src.

Para cada archivo modificado: Comparar con el oficial y después Restaurar la versión oficial. Un archivo inesperado puede ponerse en cuarentena. La comprobación se repite automáticamente cada semana.

Análisis de la base de datos

Una vez por hora, el módulo busca etiquetas script, gestores onerror u onload, URL javascript: y código ofuscado en la configuración, las páginas CMS, las descripciones de productos, categorías, marcas y proveedores, y los bloques de texto personalizados. Un script hacia un dominio desconocido o marcado aumenta el riesgo.

PCI DSS 6.4.3 y 11.6.1

Para cada script autorizado en las páginas de pago, el módulo registra la justificación, el empleado que lo autorizó y la fecha. El botón Justificar completa un script ya aprobado. El módulo vigila además:

• el contenido de los scripts de terceros de las páginas de pago, descargados y analizados cada día: un dominio aprobado que empieza a servir código malicioso genera una alerta crítica;
• las cabeceras de seguridad de las páginas de pago puestas por PrestaShop y sus módulos (CSP, HSTS, X-Frame-Options, Permissions-Policy). Las cabeceras que añade el servidor web no son visibles desde PHP.

El botón Informe PCI DSS abre un informe imprimible: inventario justificado, mecanismos de detección activos con su última ejecución y eventos de los últimos 90 días. Exportar en CSV proporciona el inventario en bruto.

Alertas

• Email: una o varias direcciones, gravedad mínima ajustable (información, aviso, crítica).
• Webhook: URL HTTPS que recibe un JSON con un campo text compatible con Slack, utilizable con Teams o un servicio propio.
• Sin duplicados: la misma alerta no se reenvía durante 60 minutos, y se envían como máximo 20 alertas por hora (ajustable).
• Banner en el back office: mientras haya una alerta crítica sin leer, aparece un banner rojo en la parte superior del back office.
• Informe semanal: puntuación, alertas de la semana, elementos pendientes y puntos por corregir.

Preguntas frecuentes

Recibo alertas después de actualizar un módulo

Apruebe los cambios en la pestaña Archivos o use la ventana de actualización la próxima vez.

Aparece un dominio desconocido que no reconozco

Puede venir de una extensión del navegador de un visitante. Mientras no lo hayan visto 3 visitantes distintos, no alerta. Si es un servicio que usa, apruébelo; si no, márquelo como malicioso.

¿Dónde se guardan las copias y la cuarentena?

Las copias de referencia se guardan comprimidas en la base de datos. La cuarentena y el archivo oficial de PrestaShop están en var/dfskimguard, protegido por un .htaccess. El módulo no analiza esta carpeta.

¿Cómo empiezo de cero?

El enlace Restablecer la referencia borra la referencia de archivos; el siguiente análisis crea una nueva. Los archivos en cuarentena siguen listados y se pueden restaurar.