Die Begriffe, die wir verwenden, wenn wir über die Sicherheit Ihres Shops sprechen — ohne Fachjargon erklärt. Jeder Begriff hat seinen eigenen Anker: die übrigen Seiten der Website verlinken direkt hierher.
Ein Fehler in einem Code, der es erlaubt, ihn zu etwas zu bringen, was er nicht tun sollte.
Eine Schwachstelle ist kein Virus: sie ist ein Entwurfs- oder Programmierfehler, meist eine vergessene Prüfung eines von aussen empfangenen Werts. Solange sie niemand nutzt, passiert nichts. Gefährlich wird es, wenn jemand den Weg schreibt, sie auszunutzen - das ist der Exploit. Bei PrestaShop steckt die überwiegende Mehrheit der ausgenutzten Lücken nicht im Kern, sondern in Modulen von Drittanbietern.
Die Anleitung, die aus einer Lücke einen echten Einbruch macht.
Das Stück Code oder die Abfolge von Anfragen, die eine Schwachstelle konkret ausnutzt. Es macht aus einem theoretischen Problem eines, das Geld kostet: eine Lücke ohne bekannten Exploit bleibt schlafend, eine Lücke mit öffentlichem Exploit wird binnen Stunden von Bots abgegrast. Deshalb zählt die Zeit zwischen der Veröffentlichung einer Lücke und der Aktualisierung Ihres Shops so sehr.
Eine Lücke, die ausgenutzt wird, obwohl es noch keine Korrektur gibt.
Der unangenehmste Fall: die Angriffe haben begonnen und der Modulhersteller hat noch kein Update veröffentlicht - manchmal wird er es nie tun, besonders bei einem aufgegebenen Modul. Aktualisieren hilft nicht, weil es nichts zu installieren gibt. Genau das deckt eine Application Firewall ab: sie weist die angreifende Anfrage vorher ab und schützt damit sofort, ohne auf eine Korrektur zu warten, die es nicht gibt.
Ein versteckter Zugang, den der Angreifer hinterlässt, um jederzeit zurückzukommen.
Eine unauffällige Datei auf Ihrem Server, oft in einem gewöhnlichen Ordner wie /upload, /img oder /cache, mit der ein Angreifer die Kontrolle über den Shop zurückgewinnt — selbst nachdem Sie alle Passwörter geändert haben. Genau deshalb genügt «ich habe mein Admin-Passwort geändert» nie, um einen Hack zu beheben: solange die Hintertür da ist, bleibt sie offen. Eine ernsthafte Bereinigung beginnt damit, sie alle zu finden.
Eine Hintertür, die sich über den Browser bedienen lässt — wie ein fremdes Admin-Panel.
Eine Form der Hintertür, die dem Angreifer eine vollwertige Oberfläche bietet: Ihre Dateien durchsuchen, weitere hochladen, Befehle auf dem Server ausführen, sich mit Ihrer Datenbank verbinden. Webshells tarnen sich gerne: ein Name, der wie eine PrestaShop-Datei aussieht, oder Code, der am Ende eines Bildes versteckt ist.
Code auf der Zahlungsseite, der die Kartennummern Ihrer Kunden mitschreibt.
Ein paar Zeilen JavaScript im Bestellprozess. Der Kunde zahlt normal, die Bestellung läuft normal durch — und parallel geht seine Kartennummer an den Angreifer. Mit blossem Auge ist nichts zu sehen, weder für Sie noch für den Käufer: meist meldet es die Bank oder ein Kunde, Wochen später. Es ist die teuerste Art der Infektion: über den Betrug hinaus ist Ihre DSGVO-Verantwortung unmittelbar betroffen.
Sammelbegriff für jeden Code, der ohne Ihre Zustimmung auf Ihrer Website landet.
Der Begriff umfasst Hintertüren ebenso wie Weiterleitungsskripte, Kryptowährungs-Miner oder Spam-Relays. Auf PrestaShop kommt er fast immer über denselben Weg: ein Drittanbieter-Modul, dessen Schwachstelle nie behoben wurde.
Ihre Dateien oder Ihre Datenbank unlesbar gemacht, mit Lösegeldforderung zur Freigabe.
Bei einem Shop nimmt der Angriff selten die spektakuläre Verschlüsselungsform an, die man von Bürorechnern kennt: meist verschlüsselt oder löscht der Angreifer Datenbank und Dateien und hinterlässt eine Zahlungsaufforderung. Die einzige Verteidigung, die wirklich trägt, ist ein ausgelagertes Backup, das Sie bereits durch eine Wiederherstellung geprüft haben — kein Backup auf demselben Server, denn das wird mitverschlüsselt. Zahlen garantiert nichts und finanziert den nächsten Angriff.
Ein Formular oder eine URL zweckentfremden, um Ihre Datenbank zum Reden zu bringen.
Der Angreifer schiebt ein Stück Datenbankabfrage in ein Suchfeld, einen Filter oder einen URL-Parameter. Prüft das Modul nicht sauber, was es erhält, führt die Datenbank die Abfrage aus: Kundenkonten, Bestellungen, manchmal das Anlegen eines Administratorkontos. Es ist die häufigste Schwachstelle in PrestaShop-Modulen von Drittanbietern.
Den Code des Angreifers im Browser Ihrer Besucher ausführen lassen.
Der Angreifer platziert ein Skript in einem Bereich, den Ihr Shop unverändert wieder ausgibt — eine Produktbewertung, einen Namen, einen URL-Parameter. Das Skript läuft anschliessend bei jedem Besucher, der die Seite öffnet: Diebstahl der Sitzung, Weiterleitung oder das Platzieren eines Skimmers auf der Zahlungsseite.
Tausende Passwörter durchprobieren, bis eines passt.
Bots testen in Dauerschleife Benutzername-Passwort-Kombinationen auf Ihrer Administrator-Anmeldeseite. Ohne Begrenzung fällt ein schwaches Passwort in wenigen Stunden. Über das Einbruchsrisiko hinaus bremsen diese Wellen den Server aus und legen den Shop mitunter allein durch ihre Last lahm.
Eine gefälschte Nachricht, die Sie Ihre Zugangsdaten auf einer nachgebauten Seite eingeben lässt.
Eine E-Mail oder SMS, die sich als Ihr Hoster, als PrestaShop, als Ihr Zahlungsdienstleister — oder als Ihr eigenes Back-Office — ausgibt und Sie auffordert, sich «erneut anzumelden». Das eingegebene Passwort landet beim Angreifer, der anschliessend durch die Vordertür spaziert: es braucht keine technische Lücke, und genau deshalb reicht eine Firewall allein nicht aus. Dafür ist die Prüfung von Anmeldungen aus ungewohnten Adressen da. Gut zu wissen: Angreifer phishen auch Ihre Kunden und nutzen dafür die Daten aus einem kompromittierten Shop, damit die Nachricht glaubwürdig wirkt.
Die Website eine Datei lesen lassen, die sie nie hätte öffnen dürfen.
Durch Manipulation eines Parameters, der eine Datei bezeichnet, klettert der Angreifer im Serververzeichnis nach oben und lässt sich eine sensible Datei anzeigen — typischerweise Ihre parameters.php mit den Zugangsdaten zur Datenbank. Im schlimmsten Fall erlaubt die Lücke zusätzlich, eine zuvor hochgeladene Datei auszuführen.
Ihnen eine saubere Seite zeigen und allen anderen eine gehackte.
Der Schadcode prüft, wer die Seite anfordert. Ein Besucher, der über Google kommt, wird auf Spam oder Phishing umgeleitet; Sie selbst, angemeldet von Ihrer gewohnten Adresse, sehen nichts Auffälliges. So kann ein Hack wochenlang laufen, ohne dass der Händler es bemerkt — bis der Traffic einbricht.
Ihre Startseite ersetzt durch eine Botschaft des Angreifers.
Die sichtbarste Form eines Angriffs: der Shop verschwindet hinter einer Seite, die eine Gruppe für sich reklamiert. Paradoxerweise ist sie die harmloseste - man sieht sie sofort, also wird sie schnell behandelt. Teuer werden die Infektionen, die sorgsam nichts am Erscheinungsbild ändern. Ein Defacement bleibt dennoch ein ernstes Signal: wer Ihre Startseite überschreiben konnte, hatte Zugriff auf alles andere.
Ihr Server wird gekapert, um E-Mails für den Angreifer zu verschicken.
Ein Skript auf der Website versendet Tausende betrügerischer E-Mails über Ihren Server. Unmittelbare Folgen: Ihre Domain landet auf den Sperrlisten der Mailanbieter (Ihre echten Bestellbestätigungen kommen nicht mehr an), und Ihr Hoster sperrt am Ende das Konto.
Niemand hat Sie ausgewählt: Bots klopfen ununterbrochen an jede Tür.
«Warum mein Shop? Ich bin nicht Amazon.» Weil kein Mensch Sie ins Visier genommen hat. Netze gekaperter Rechner durchkämmen das Internet pausenlos und testen an jeder Website die Liste der veröffentlichten Lücken, ohne Rücksicht auf Grösse oder Umsatz. Ein kleiner Shop mit einem nicht aktualisierten Modul ist ein ebenso gültiges Ziel wie ein grosser - oft ein besseres, weil weniger beobachtet. Genau das macht auch die gemeinsame Sperrliste wirksam: es sind überall dieselben Adressen.
Ein Filter, der feindliche Anfragen stoppt, bevor sie Ihren Shop erreichen.
Wo ein Antivirus Ihre Dateien prüft, prüft die Application Firewall den eingehenden Verkehr und weist alles ab, was nach Angriff aussieht: SQL-Injection, eingeschleustes Skript, massenhafte Anmeldeversuche. Ihr grösster Wert ist Zeit: sie schützt eine bekannte Lücke sofort, ohne auf einen Patch des Modulherstellers zu warten.
Die öffentliche Kennung einer bekannten Sicherheitslücke.
Wird in PrestaShop oder einem Modul eine Lücke entdeckt, erhält sie eine weltweit gültige Referenznummer, zum Beispiel CVE-2024-6648. Diese Nummer ist öffentlich: Angreifer nutzen sie als Katalog und durchsuchen das Internet nach Shops, die noch nicht aktualisiert haben. Es ist ein Wettlauf zwischen der Veröffentlichung der Lücke und dem Moment, in dem Sie sie schliessen.
Der Eintrag zu einer Lücke: betroffenes Modul, Versionen, Behebung.
Zu jeder Lücke, die wir verfolgen, führen wir einen Eintrag: welches Modul, welche Versionen verwundbar sind, ab welcher Version es behoben ist und was wir in der Zwischenzeit tun. Ihr Dashboard gleicht diese Einträge mit den tatsächlich installierten Modulen Ihres Shops ab, damit Sie nur sehen, was Sie betrifft.
Jede Ihrer Dateien mit dem offiziellen PrestaShop-Original vergleichen.
Jede Datei hat einen eindeutigen digitalen Fingerabdruck. Durch den Vergleich der Fingerabdrücke Ihrer Dateien mit denen der offiziellen Dateien Ihrer PrestaShop-Version erkennen wir dateigenau, was verändert, hinzugefügt oder gelöscht wurde — auch wenn der eingeschleuste Code zu gut geschrieben ist, um wie ein Virus auszusehen.
Ein bei einem Kunden geblockter Angriff schützt sofort alle anderen.
Greift eine IP-Adresse einen Shop im Netzwerk an, wird sie einer Liste hinzugefügt, die alle geschützten Shops teilen. Derselbe Angreifer, der danach bei Ihnen auftaucht, wird abgewiesen, bevor er es überhaupt versucht. Je mehr Shops im Netzwerk, desto aktueller die Liste.
Ein zweiter Faktor zusätzlich zum Passwort, damit ein gestohlenes Passwort nicht mehr genügt.
Ein Einmalcode, der beim Anmelden zusätzlich zum Passwort abgefragt wird. Es ist der einzige wirklich wirksame Schutz gegen Phishing und Zugangsdatendiebstahl: selbst mit dem richtigen Passwort wird der Angreifer gestoppt. Dasselbe Prinzip gilt für die Prüfung von Administrator-Anmeldungen aus einer Adresse, die der Shop noch nie verwendet hat: vor dem Einlass wird ein zusätzlicher Nachweis verlangt.
Eine Datei wird als verdächtig gemeldet, obwohl sie völlig legitim ist.
Manche kommerziellen Module liefern komprimierten oder kodierten Code aus, der von weitem wie Schadcode aussieht. Ein guter Antivirus sollte ihn melden statt ihn zu übergehen — aber er muss auch eine schnelle Entscheidung ermöglichen. Das Dashboard liefert Ihnen den Kontext und den genauen Codeausschnitt, und unser Team entscheidet die Zweifelsfälle.
Unnötige Türen schliessen, damit ein Angreifer weniger erreichen kann.
Die Summe der Einstellungen, die einen Einbruch erschweren und weniger lohnend machen: korrekte Dateirechte, gepflegte PHP-Version, eingeschränkter Administratorzugang, entfernte Installationsordner. Es ist kein Schutz gegen einen bestimmten Angriff — es ist das, was dafür sorgt, dass eine ausgenutzte Lücke weniger Schaden anrichtet.
Der rote Warnbildschirm «Gefährliche Website», der Ihren Traffic abschneidet.
Erkennt Google Schadinhalte in einem Shop, zeigt es eine bildschirmfüllende Warnung, bevor der Besucher hineingelassen wird — und die Platzierungen brechen ein. Die Entfernung erfolgt nicht automatisch: erst bereinigen, dann in der Search Console eine Überprüfung beantragen. Rechnen Sie mit 24 bis 72 Stunden nach der Freigabe.
Eine Lücke schließen, ohne die Modulversion zu wechseln.
Wird eine Lücke veröffentlicht, ist die übliche Antwort ein Modul-Update — sofern der Anbieter eine korrigierte Version veröffentlicht hat, sie mit Ihrem Shop kompatibel ist und Sie sie installieren können. Ein Patch arbeitet anders: er ändert genau die fehlerhaften Zeilen in der Version, die Sie bereits einsetzen. Die Lücke schließt sich ohne Versionswechsel, ohne Regressionsrisiko für Ihr Theme, und der Vorgang ist umkehrbar.
Erst den Anbieter informieren, das Detail später veröffentlichen — oder nie.
Das Detail einer Lücke zu veröffentlichen, bevor der Anbieter sie behoben hat, bewaffnet jeden gegen alle Shops, die das Modul einsetzen. Koordinierte Offenlegung heißt: den Anbieter benachrichtigen, ihm Zeit für eine Korrektur lassen und erst danach veröffentlichen. Deshalb zählen wir unsere eigenen Funde öffentlich, ohne das Modul je zu nennen, solange die Korrektur nicht für alle verfügbar ist.
Fehlt ein Begriff, oder ist eine Definition unklar? Sagen Sie uns Bescheid, wir ergänzen sie.
