Neuigkeiten & Entwicklungen

Acht Reiter in Ihrem Backoffice, mit dem PrestaShop-Menü: Übersicht, Scan, Firewall, Anmeldungen, Verlauf, Einstellungen, Bericht und Hilfe. Bewertung, Schwachstellen und Befunde berechnet PrestaSecure: Modul und Kundenbereich zeigen dieselben Zahlen und bieten dieselben Aktionen. Die Übersicht ordnet die Aufgaben vom dringendsten zum am wenigsten dringenden.

Ob im Modul, in Ihrem PrestaSecure-Kundenbereich oder von unserem Team gestartet: Der laufende Scan zeigt seinen Fortschritt und die gefundenen Bedrohungen, die schwerste zuerst. Eine gemeldete Datei öffnet sich mit hervorgehobenen Zeilen, eine Kerndatei wird mit dem Original Ihrer Version verglichen, und auch bei einem Scan hinzugefügte oder geänderte Dateien lassen sich lesen. Dateien mit den Zugangsdaten des Shops werden nie angezeigt.

Eine PrestaShop-Kerndatei wird aus dem Original wiederhergestellt, nie in Quarantäne verschoben. Bei anderen Dateien geht der Quarantäne eine Warnung voraus: Das Entfernen einer genutzten Datei kann die Website beschädigen. Sie können die Einschätzung von PrestaSecure anfordern, ohne Frist und unverbindlich (3 Anfragen pro Monat); mit Serenity melden Sie die Datei unserem Team. Eine ignorierte Datei erscheint wieder, wenn sich ihr Inhalt ändert, und jede Quarantäne lässt sich rückgängig machen.

Nach der Bereinigung der Datenbank blieb die Warnung sichtbar, bis jemand sie von Hand als behoben markierte. Das Modul teilt PrestaSecure nun mit, ob es die Datenbank waehrend des Scans tatsaechlich gelesen hat: Ist das der Fall und die Tabelle nicht mehr betroffen, schliesst sich die Warnung. Ist das Lesen fehlgeschlagen, bleibt die Warnung offen, denn ein Scan, der nichts lesen konnte, beweist nichts.

Schadcode kann direkt in die Datenbank geschrieben werden, zum Beispiel in die Notiz eines Kundendatensatzes. Er wird dann im Browser des Mitarbeiters ausgefuehrt, der den Kunden oder die Bestellung oeffnet, und kann die Adresse Ihres Back-Office an Dritte senden. Da keine Datei veraendert wird, konnten weder der Datei-Scan noch der Scan der Shopseiten ihn erkennen. Der Scan prueft nun Kundennotizen, Adresszusaetze sowie Bestell- und Kundendienstnachrichten. PrestaShop lehnt solche Inhalte bei der Eingabe ab: ihr Vorhandensein deutet auf einen direkten Schreibzugriff auf die Datenbank hin. Die Warnung erscheint in Ihrem PrestaSecure-Bereich mit der Zahl der betroffenen Datensaetze, und unser Team wird benachrichtigt.

In einem Shop, dessen geplante Aufgabe alle fuenfzehn Minuten laeuft, startete ein neuer vollstaendiger Scan, sobald der vorige beendet war, bis zu mehreren Dutzend pro Tag: unnoetige Last fuer Ihren Server. Die geplante Aufgabe schliesst einen laufenden Scan weiterhin ab, startet aber nur dann einen neuen, wenn der letzte mehr als zwanzig Stunden zurueckliegt. Von Ihnen selbst gestartete Scans bleiben unveraendert.

Das Widget der Startseite listet jede verfuegbare Korrektur mit dem betroffenen Modul, der Art der Luecke in einfachen Worten und der Zahl der Tage seit ihrer Meldung. Ein Klick genuegt, um sie anzuwenden, nach einer automatischen Sicherung; ein Zuruecksetzen bleibt moeglich. Die Sicherheitsnote zeigt auch, welche Note der Shop nach den Korrekturen haette, und die Firewall zeigt die in den letzten 24 Stunden abgewiesenen Anfragen.

Wenn eine Korrektur nicht greift, bleibt Ihr Shop unveraendert und das Modul teilt Ihnen dies klar mit, mit einer Vorgangsnummer. Unser Team wird benachrichtigt und prueft die Korrektur; Sie erhalten eine E-Mail, sobald sie repariert ist, und die Schaltflaeche zum Anwenden erscheint von selbst wieder.

Eine Adresse, die Angriffe aneinanderreiht, wird beim dritten Versuch 15 Minuten, beim fuenften 2 Stunden und beim zehnten 24 Stunden gesperrt. Der Zaehler wurde bei jeder Anfrage zurueckgesetzt: jeder Angriff wurde zwar abgewiesen, aber der Angreifer konnte unbegrenzt weitermachen und Varianten ausprobieren. Der Zaehler bleibt nun erhalten, und eine bereits gesperrte Adresse, die erneut angreift, wird laenger gesperrt.

Bots rufen Kategorieseiten mit gestapelten Filtern oder Listen von Hunderten Produkten in Serie auf. Die Firewall wies sie bereits ab, aber erst nachdem der Shop geladen war, nach Hunderten Datenbankabfragen: bei einem begrenzten Shared Hosting genuegte das, um die Seite lahmzulegen. Diese Anfragen weist nun der Webserver selbst ab, mit einer schlanken Seite, ohne die Datenbank zu beruehren. Dieser Filter folgt Ihrer Lizenz und entfernt sich selbst, wenn das Modul deaktiviert wird.

Nach jeder Korrektur liest das Modul die Datei erneut und bestaetigt den Erfolg nur, wenn sich ihr Inhalt tatsaechlich geaendert hat. Jede geaenderte Datei wird geprueft, und bei einem Fehler wird die Originalversion automatisch wiederhergestellt. Bereits von Ihrem Entwickler entschaerfter Code wird erkannt und unveraendert gelassen.

Ein Modulordner, der auf dem Server liegt, aber im Shop deinstalliert ist, kann eine ausnutzbare Luecke enthalten. Diese verwaisten Ordner waren verborgen und liessen sich nicht entfernen, wenn es sich um ein mit PrestaShop geliefertes Modul handelte. Sie werden nun als solche aufgefuehrt und koennen geloescht werden, nach einer Sicherung in Quarantaene. Ein in Ihrem Shop installiertes Modul wird nie angetastet.

Unter PrestaShop 8 und 9 erreichte der auf dem Bestaetigungsbildschirm eingegebene Code unseren Dienst von manchen Back-Office-Seiten aus nicht: der Mitarbeiter landete wieder auf der Eingabemaske und hielt den Code fuer falsch. Das ist behoben. Eine aus Ihrem Kundenbereich oder von unserem Team freigegebene Adresse gilt nun innerhalb einer Minute, statt auf die geplante Aufgabe Ihres Shops zu warten; dasselbe gilt fuer das Abschalten des Schutzes. Und wenn kein Code ausgestellt werden kann, bleibt die Tuer geschlossen und der Bildschirm zeigt die Wartezeit an: kein Zugang mehr ohne Bestaetigung.

Eine Anmeldung an Ihrer Verwaltung von einer Adresse, die Ihr Shop nie genutzt hat, kann nun angehalten werden, bis ein per E-Mail gesendeter Code eingegeben wird. Der Schutz startet im Beobachtungsmodus: in den ersten Tagen erfasst er lediglich die von Ihrem Team genutzten Adressen, ohne jemanden zu blockieren oder etwas zu versenden. Sie entscheiden anschliessend, wann er aktiviert wird, sobald die Liste steht. Ab dem Tarif Advance.

Hinter Cloudflare oder einem Load Balancer schienen alle Verbindungen von derselben Adresse zu kommen, was jede Unterscheidung unmoeglich machte. Wir lesen nun die Ursprungsadresse, aber nur wenn die Anfrage von einem uns bekannten Vermittler stammt: ein von einem Angreifer gefaelschter Header kann daher keine vertrauenswuerdige Adresse vortaeuschen.

Wenn eine Sicherheitskorrektur die vorgesehene Datei nicht fand, schlossen wir daraus, dass die Luecke verschwunden war. Das stimmt meistens, aber nicht immer: die Datei kann auch anderswo liegen als dort, wo wir gesucht haben, waehrend die Luecke bestehen bleibt. Wir unterscheiden nun beide Faelle, und kein Shop gilt ohne Nachweis als sicher.

Unsere Sicherheitskorrekturen ersetzen einen Codeblock Byte fuer Byte, damit nie etwas anderes als das Vorgesehene beruehrt wird. Dieselbe Datei wird jedoch unterschiedlich geschrieben, je nachdem, ob sie unter Windows oder auf einem Server gespeichert wurde: die Zeilenenden unterscheiden sich, unsichtbar. In diesen Shops erkannte die Korrektur den Zielblock nicht mehr und hielt sich vorsichtshalber zurueck. Die Engine formuliert das Muster nun im Stil der vorliegenden Datei: der Schutz greift ueberall, ohne je etwas aufs Geratewohl umzuschreiben.

Schadcode in einer Datei zu verstecken, die sich als Bild ausgibt, ist eine bewaehrte Technik: die Datei traegt eine Foto-Endung, doch der Server findet darin Anweisungen. Wir suchten danach dort, wo Dateien von aussen ankommen — in den Upload- und Download-Ordnern. Die Schwierigkeit liegt nicht darin, anderswo zu suchen, sondern darin, es zu tun, ohne bei jedem Scan die Hunderttausenden legitimen Bilder Ihres Katalogs erneut zu lesen. Wir pruefen nun ueberall den Kopf jedes Bildes, auch unter Ihren Themes, Modulen und Bibliotheken, und untersuchen nur die genauer, die tatsaechlich Code enthalten. Der Scan bleibt ebenso schnell und laesst diese Ecke nicht mehr aus.

Sobald eine Datei gemeldet wird, untersucht unser System sie gründlich. Sie sehen jetzt in Ihrem Dashboard, wohin diese Analyse tendiert, wahrscheinlich Fehlalarm oder echte Bedrohung, samt Konfidenzniveau, ohne zu warten, bis wir im Hintergrund eingreifen. So wissen Sie sofort, was Ihre Aufmerksamkeit verdient.

Manche Händler betreiben zusätzlich ein WordPress in ihrem PrestaShop-Shop. Das ist nicht ratsam, kommt aber vor, und sein Kern löste manchmal versehentlich Warnungen aus. Dasselbe galt für die mit bestimmten Modulen gelieferten Test-Bibliotheken und für komprimierte JavaScript-Dateien. Der Scanner erkennt diese normalen Komponenten jetzt und lässt sie beiseite, ohne bei den wirklich riskanten Dateien nachzulassen. Ihre Scan-Berichte werden übersichtlicher.

Manche Angreifer pflanzen ein unsichtbares Skript in die Login-Seite Ihres Back-Office, um bei jeder Anmeldung Benutzername und Passwort abzugreifen, und installieren sich nach einem einfachen Passwortwechsel von selbst neu. So kommen sie Tag für Tag zurück. Wir erkennen diese Art von Einpflanzung jetzt: ein heimlich in die Verwaltung geladenes Skript und eine versteckte Browser-Markierung, auch wenn der Angreifer seine Dateien umbenennt, um Spuren zu verwischen. Auf einem echten Shop entdeckt, blieb diese Falle bisher unbemerkt und löst nun eine kritische Warnung aus.

Bei Shops mit sehr vielen Dateien oder umfangreichen Aktivitätsprotokollen konnte die Analyse mangels Speicher mittendrin abbrechen. Sie hält ihren Verbrauch jetzt laufend im Griff und läuft vollständig durch, unabhängig von der Größe des Shops.

Wir haben die Erkennung von Kartenskimmern (Magecart-Art) verschärft, die ihre Sammeladresse codiert in einem Skript oder einem gefälschten Bild verstecken, ebenso wie von Ladern, die eine von einem externen Server heruntergeladene Backdoor ausführen, selbst wenn der Code absichtlich getarnt ist. Auf echten Shops entdeckt, erscheinen diese Muster nun als kritische Warnung, statt unter dem Radar zu bleiben.

Wir jagen jetzt Backdoors, die sich tarnen, indem sie ihren Code verschleiern (etwa durch Spielen mit Groß- und Kleinschreibung, um Virenscanner zu täuschen) oder sich über eine von außen heruntergeladene Datei selbst neu installieren. Auf echten Shops gefunden, oft in raubkopierten Modulen versteckt, blieben diese Fallen bisher „unauffällig": Sie lösen nun eine kritische Warnung aus.

Keine abrupte „Zugriff verweigert“-Seite mehr. Nach wiederholten Versuchen sieht der Kunde das gewohnte Login-Formular mit einer klaren Meldung: zu viele Versuche, verbleibende Wartezeit und ein direkter Link zum Zurücksetzen des Passworts. Die Schwelle wurde gelockert, damit ein Kunde, der sich nur vertippt, nicht bestraft wird, automatisierte Angriffe werden weiterhin sofort blockiert.

Sehen Sie den Inhalt einer markierten Datei oder ihren Vergleich mit der offiziellen PrestaShop-Version direkt in Ihrem PrestaSecure-Dashboard, ohne SSH oder FTP. Schreibgeschützter Zugriff, strikt auf Ihren Shop und sichere Dateitypen beschränkt.

Der Scanner prüft jetzt auch die Konfiguration und die im Shop angezeigten redaktionellen Inhalte, nicht nur die Dateien. Das schließt eine Lücke, die manche Angreifer nutzen, um ein Karten-Skimming-Skript außerhalb der Dateien einzuschleusen, ein bei einem realen Vorfall beobachteter Vektor.

Kataloge mit mehreren Millionen Dateien, Multistore: Der Scan analysiert jetzt den gesamten Bestand, ohne Abschneiden oder Speicherüberlauf, mit mehreren automatischen Durchläufen bei Bedarf. Kein Bereich des Shops bleibt außen vor.

Wiederkehrende Scans analysieren jetzt nur noch die seit dem letzten Lauf tatsächlich geänderten Dateien, statt alles neu zu durchsuchen. Die Zeitersparnis ist bei großen Shops enorm, ohne Abdeckungsverlust: schon ein einziges geändertes Byte wird erkannt.

Der Bericht entsteht vor Ihren Augen: Bedrohungen erscheinen während des Scans, mit Schweregrad und Gruppierung, statt erst ganz am Ende.

Das Modul durchsucht das PHP-Fehlerprotokoll Ihres Shops nach bekannten Angriffssignaturen (Template-Injection, Leseversuche an sensiblen Konfigurationsdateien, Remote-File-Inclusion …). Angreifer hinterlassen oft monatelang fehlgeschlagene Versuche, bevor sie erfolgreich sind: Sie werden ab den ersten Signalen alarmiert.

Beim Scan wird kein Ordner mehr übersprungen (Abhängigkeiten, Themes, Backoffice, Upload-Ordner …). Schadcode kann sich überall verstecken, auch in einer Abhängigkeit oder einer im Admin abgelegten Webshell. Die Analyse deckt nun die gesamte Website ab.

Beheben Sie Probleme mit wenigen Klicks: Einspielen geprüfter Sicherheitspatches, Bereinigen infizierter Dateien, Entfernen von Phantom-Modulen (auf der Festplatte vorhanden, aber PrestaShop unbekannt) und Aktualisieren verwundbarer Module, alles mit automatischem Backup und Rollback.

Ein Abzeichen zeigt für jede erkannte Schwachstelle, ob sie bereits von der PrestaSecure-Anwendungsfirewall neutralisiert wird. Sie erkennen auf einen Blick, was geschützt ist und was Handlung erfordert.

Spielen Sie Patches für bekannte Schwachstellen im PrestaShop-Kern und in Modulen direkt aus Ihrem Dashboard ein, mit vorherigem Backup, automatischer Prüfung nach dem Einspielen und der Möglichkeit, jederzeit rückgängig zu machen.

Erste Version: Schutz-Dashboard mit Punktzahl, Antivirus (Datei- und Fingerprint-Scan), Anwendungsfirewall (SQL-Injection, XSS, Brute Force, Path Traversal), Behebungswerkzeuge, exportierbarer Sicherheitsbericht und automatische Modul-Updates.