DataFirefly Skimming Guard: Skimming-Schutz und Dateiintegrität

Überblick

DataFirefly Skimming Guard überwacht den Code, den Ihr PrestaShop-8- oder -9-Shop an Kunden ausliefert: Dateien, Datenbank, das HTML der Zahlungsseiten und das Verhalten des Browsers im Checkout. Das Modul erkennt eingeschleuste Skripte, die Kartennummern kopieren (Angriffe nach dem Magecart-Muster), geänderte oder hinzugefügte Dateien sowie PrestaShop-Core-Dateien, die vom offiziellen Release abweichen. Es ergänzt DataFirefly Admin Shield, das den Back-Office-Login schützt.

Installation

1. Öffnen Sie im Back-Office Module > Modulverwaltung > Modul hochladen und laden Sie dfskimguard-1.2.1.zip hoch.
2. Öffnen Sie das Modul. Es ist auch unter Erweiterte Einstellungen > Skimming Guard erreichbar.
3. Klicken Sie auf Jetzt scannen. Der erste Scan erfasst die Referenz Ihrer Dateien: einen SHA-256-Fingerabdruck pro Datei und eine Kopie der Theme-Dateien, Modul-Views und Einstiegsdateien.
4. Richten Sie die geplante Aufgabe ein (siehe unten).
5. Senden Sie in der Übersicht eine Testwarnung, um den Empfang zu prüfen.

Geplante Aufgabe

Die Scans laufen im Hintergrund, nie während eines Kundenbesuchs. Drei Möglichkeiten:

• Cron-URL: Kopieren Sie die URL aus dem Block Geplante Aufgabe und rufen Sie sie alle 15 Minuten über den Cron-Manager Ihres Hostings auf. Die URL enthält ein geheimes Token.
• Kommandozeile: Mit SSH-Zugang führen Sie php modules/dfskimguard/cli.php aus. Die Option --full scannt alles in einem Durchlauf, ohne Zeitlimit.
• PrestaShop-Modul cronjobs: Wenn Sie es nutzen, läuft die Aufgabe stündlich.

Jeder Lauf startet oder setzt den Datei-Scan fort, scannt die Datenbank stündlich, prüft den PrestaShop-Core wöchentlich und den Inhalt der Drittanbieter-Skripte täglich.

Übersicht

Das Banner oben auf jedem Tab zeigt einen Sicherheitswert von 0 bis 100 und einen Satz zur Lage, mit Verknüpfungen zu offenen Punkten. Die Übersicht listet zwei Gruppen von Prüfungen, fehlgeschlagene zuerst:

• Einrichtung des Schutzes: aktuelle Referenz, laufende geplante Aufgabe, Empfänger der Warnungen, Ende der Lernphase, Blockierung von Kartendaten, Content Security Policy, Core-Prüfung, Begründung der Zahlungsskripte.
• Absicherung des Shops: Debug-Modus, Installationsordner, Name des Admin-Ordners, aus dem Web erreichbare gefährliche Dateien (SQL- oder ZIP-Backups, phpinfo, adminer, .git, .env, PHPUnit eval-stdin.php), SSL auf allen Seiten, PHP-Version, Rechte der Konfigurationsdateien.

Jeder fehlgeschlagene Punkt erklärt, wie er zu beheben ist.

Schutz des Checkouts

Prüfung des ausgelieferten HTML

Auf Warenkorb, Checkout und Zahlungsseiten der Module liest das Modul das von PrestaShop erzeugte HTML. Es erfasst jedes externe Skript, jeden Iframe, jedes Formularziel und jede in einem Inline-Skript genannte Domain und wendet Signaturen für verschleierten Code an (eval(atob(...)), new Function, fromCharCode-Ketten, Skript-Lader, Erkennung der Entwicklertools). Standardmäßig wird jede Seite höchstens alle 5 Minuten geprüft. Passen Sie das Intervall in den Einstellungen an oder überwachen Sie alle Shopseiten.

Browser-Wächter

Ein 5,5 KB großes Skript wird zuerst in den <head> der überwachten Seiten eingefügt. Es meldet unbekannte Domains, die die Seite kontaktiert, und erkennt auf Zahlungsseiten eine gültige Kartennummer, die an eine nicht freigegebene Domain geht, auch base64-kodiert. Die Nummer wird nie an den Server übertragen. Um Browser-Erweiterungen herauszufiltern, warnt eine unbekannte Domain erst nach 3 verschiedenen Besuchern (einstellbar); ein Versuch, eine Kartennummer zu senden, wird sofort gemeldet.

Blockierung von Kartendaten

Option Kartendaten an unbekannte Domains blockieren: Die Anfrage wird abgebrochen, wenn sie eine Kartennummer enthält und an eine nicht freigegebene Domain geht. Aktivieren Sie sie, sobald die Lernphase vorbei ist und Ihre Zahlungsanbieter freigegeben sind.

Content Security Policy

Das Modul kann auf überwachten Seiten eine CSP aus den freigegebenen Domains senden. Beginnen Sie mit Nur melden und wechseln Sie zu Erzwingen, wenn keine unerwartete Domain mehr auftaucht.

Lernphase

In den 48 Stunden nach der Installation werden Drittanbieter-Skripte und Domains mit geringem Risiko ohne Warnung freigegeben. Verdächtige Elemente lösen trotzdem eine Warnung aus. Starten Sie die Lernphase nach einem Theme- oder Zahlungswechsel mit 48 Stunden lernen neu.

Vertrauenswürdige Domains

Eine integrierte Liste deckt gängige Anbieter ab (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). Ergänzen Sie eigene Domains in den Einstellungen, eine pro Zeile; Subdomains sind eingeschlossen.

Tab Skripte und Domains

Der Tab listet jedes auf Ihren Seiten gesehene Element mit Typ, Domain, Seite, Risikowert und Anzahl der Aufrufe. Drei Aktionen:

• Freigeben: Das Element und seine Domain kommen auf die Vertrauensliste (Wächter und CSP). Bei einem Skript der Zahlungsseiten fragt ein Fenster nach der Begründung.
• Bösartig: Der Wächter blockiert die Domain, die CSP schließt sie aus. Taucht sie wieder auf, wird kritisch gewarnt.
• Löschen: entfernt das Element aus dem Inventar.

Dateiintegrität

Was überwacht wird

Standard-Dateiendungen: php, phtml, php5, php7, phar, inc, js, mjs, tpl, twig, html, htm, htaccess, ini, svg, ico. Standardmäßig ausgeschlossene Pfade: var, cache, img, upload, download, .git, node_modules, Theme-Caches und Backups des Admin-Ordners. Das Token {admin} wird durch den Namen Ihres Admin-Ordners ersetzt.

Eine Datei gilt als unverändert, wenn Größe, Änderungszeit und Inode-Änderungszeit gleich geblieben sind. Die Inode-Änderungszeit lässt sich mit touch nicht fälschen. Alle 7 Tage (einstellbar) werden alle Fingerabdrücke neu berechnet.

Signaturen

Jede neue oder geänderte Datei durchläuft die Signaturen: bekannte Web-Shells, eval auf dekodierten oder Anfragedaten, Systembefehle aus Anfragedaten, in einem Bild oder .ico versteckter PHP-Code, Include einer Mediendatei, in .htaccess oder .user.ini ergänztes auto_prepend_file, als PHP ausgeführte Mediendateien, ausgelesene und über das Netzwerk gesendete Kartenfelder. Eine Datei mit Risiko 70 oder mehr löst sofort eine kritische Warnung aus; andere Änderungen werden in einer Zusammenfassung pro Scan gebündelt.

Tab Dateien

• Änderungen ansehen: zeilenweiser Diff zwischen freigegebener Version und aktueller Datei. Bei einzeiligem minifiziertem JS wird nur das eingefügte Fragment gezeigt.
• Freigegebene Version wiederherstellen: setzt die Referenzkopie wieder ein. Die geänderte Version bleibt als Beweis in var/dfskimguard/quarantine.
• Freigeben: übernimmt die aktuelle Datei als neue Referenz. Mehrfachauswahl und Alle Änderungen freigeben sind für die Zeit nach einem Update gedacht.
• Quarantäne: verschiebt eine verdächtige neue Datei aus dem Shop. Sie kann wiederhergestellt werden.

Update-Fenster

Klicken Sie vor dem Update eines Moduls oder Themes auf Ich aktualisiere meinen Shop (2 Std.). Zwei Stunden lang werden ohne verdächtigen Code geänderte Dateien ohne Warnung zur neuen Referenz. Eine Datei mit hohem Risiko löst trotzdem eine Warnung aus.

Prüfung des PrestaShop-Cores

Der Tab PrestaShop-Core lädt die offizielle Quelle Ihrer Version von GitHub und vergleicht die PHP-, TPL- und Twig-Dateien in classes, controllers, src, config sowie die PHP-Dateien des Admin-Ordners. Zeilenenden und die vom Release-Build und Debug-Modus in config/defines.inc.php umgeschriebenen Einstellungen werden ignoriert. Das Modul meldet außerdem unerwartete PHP-Dateien in classes, controllers und src.

Für jede geänderte Datei: Mit Original vergleichen, dann Offizielle Version wiederherstellen. Eine unerwartete Datei lässt sich in Quarantäne verschieben. Die Prüfung läuft jede Woche automatisch erneut.

Datenbank-Scan

Stündlich sucht das Modul nach Script-Tags, onerror- oder onload-Handlern, javascript:-URLs und verschleiertem Code in Konfigurationswerten, CMS-Seiten, Produkt-, Kategorie-, Marken- und Lieferantenbeschreibungen sowie eigenen Textblöcken. Ein Skript zu einer unbekannten oder markierten Domain erhöht das Risiko.

PCI DSS 6.4.3 und 11.6.1

Für jedes autorisierte Skript auf Zahlungsseiten speichert das Modul die Begründung, den autorisierenden Mitarbeiter und das Datum. Die Schaltfläche Begründen ergänzt ein bereits freigegebenes Skript. Das Modul überwacht außerdem:

• den Inhalt der Drittanbieter-Skripte der Zahlungsseiten, täglich heruntergeladen und gescannt: Eine freigegebene Domain, die plötzlich bösartigen Code ausliefert, löst eine kritische Warnung aus;
• die Sicherheits-Header der Zahlungsseiten, die PrestaShop und seine Module setzen (CSP, HSTS, X-Frame-Options, Permissions-Policy). Vom Webserver hinzugefügte Header sind aus PHP nicht sichtbar.

Die Schaltfläche PCI-DSS-Bericht öffnet einen druckbaren Bericht: begründetes Inventar, aktive Erkennungsmechanismen mit ihrem letzten Lauf, Ereignisse der letzten 90 Tage. Als CSV exportieren liefert das Rohinventar.

Warnungen

• E-Mail: eine oder mehrere Adressen, einstellbarer Mindestschweregrad (Info, Warnung, kritisch).
• Webhook: HTTPS-URL, die JSON mit einem Slack-kompatiblen text-Feld erhält, nutzbar mit Teams oder einem eigenen Dienst.
• Keine Duplikate: Dieselbe Warnung wird 60 Minuten lang nicht erneut gesendet, höchstens 20 Warnungen pro Stunde (einstellbar).
• Back-Office-Banner: Solange eine kritische Warnung ungelesen ist, erscheint oben im Back-Office ein rotes Banner.
• Wochenbericht: Wert, Warnungen der Woche, offene Elemente und zu behebende Punkte.

Häufige Fragen

Nach einem Modul-Update erhalte ich Warnungen

Geben Sie die Änderungen im Tab Dateien frei oder nutzen Sie beim nächsten Mal das Update-Fenster.

Eine unbekannte Domain erscheint, die ich nicht kenne

Sie kann von einer Browser-Erweiterung eines Besuchers stammen. Solange sie nicht bei 3 verschiedenen Besuchern aufgetaucht ist, warnt sie nicht. Nutzen Sie den Dienst, geben Sie sie frei; sonst markieren Sie sie als bösartig.

Wo werden Kopien und Quarantäne gespeichert?

Referenzkopien liegen komprimiert in der Datenbank. Quarantäne und das offizielle PrestaShop-Archiv liegen in var/dfskimguard, geschützt durch eine .htaccess. Das Modul scannt diesen Ordner nicht.

Wie fange ich neu an?

Der Link Referenz zurücksetzen löscht die Dateireferenz; der nächste Scan erstellt eine neue. Dateien in Quarantäne bleiben gelistet und wiederherstellbar.