PrestaShop-Sicherheit: Härtung, Zugriff und Wiederherstellung

Unser Vorgehen

Wir würden zuerst klären, ob Sie einem Problem vorbeugen oder auf Hinweise einer Kompromittierung reagieren. Erfassen Sie für die reguläre Härtung vor der Werkzeugauswahl Ihren Bestand: Hosting, PrestaShop und PHP, Module, Integrationen, Theme-Anpassungen, gespeicherte Daten, Märkte und Personen mit Zugriffsbedarf. Eine Lagerintegration, ein reisendes Supportteam und ein eingebettetes Zahlungsformular stellen unterschiedliche Anforderungen. Behalten Sie funktionierende Kontrollen bei und schließen Sie nachweisbare Lücken.

Kann Ihr Shop keine gewartete Software nutzen, vergleichen Sie ein Upgrade der bestehenden Installation mit einer sauberen Zielinstallation und kontrollierter Datenmigration. Der passende Weg hängt von individuellem Code, Modulalternativen, Theme, Integrationen und Datenqualität ab. Die Härtung eines nicht mehr unterstützten Shops begrenzt währenddessen bestimmte Risiken; sie stellt keine Upstream-Wartung wieder her. Besteht Kompromittierungsverdacht, sichern Sie Beweise und folgen Sie dem Abschnitt zur Vorfallsreaktion, bevor Sie den Shop als sichere Ausgangskopie behandeln.

Nutzen Sie für geplante Änderungen eine geschützte Staging-Kopie, proben Sie betroffene Geschäftsabläufe, dokumentieren Sie die Rücknahme und vereinbaren Sie eine Produktivumstellung mit einem Verantwortlichen, der das Ergebnis überwacht. Eine Plattform- oder Datenbankmigration benötigt auch einen Plan für Bestellungen und andere Schreibvorgänge während der Vorbereitung der Kopie.

Für eine unabhängige Bewertung prüft der PrestaShop Security Audit & Hardening Report die vereinbarte Angriffsfläche und liefert einen priorisierten Plan; Umsetzung und Vorfallsbehebung werden separat abgegrenzt.

Mit Prävention, Erkennung und Wiederherstellung beginnen

Schützen Sie den Shop auf mehreren Ebenen: unterstützte Software, persönliche Zugänge, eingeschränkte Berechtigungen, Serverregeln, Trafficfilterung, Überwachung und wiederherstellbare Backups. HTTPS schützt Daten bei der Übertragung. Ein Backup hilft bei der Wiederherstellung. Beides ersetzt keine Sicherheitsupdates.

Zu den Risiken gehören SQL-Injection im Core oder in Modulen, gestohlene Mitarbeiterzugangsdaten, unsichere Uploads, schädliche Pakete und öffentlich zugängliche Backups oder Konfigurationen. Ein Checkout kann weiterhin funktionieren, während eingeschleustes JavaScript Daten stiehlt. Auch ein kleiner Shop braucht diese Schutzmaßnahmen.

1. Erfassen Sie die genauen Versionen von PrestaShop, PHP, Datenbank, Theme und Modulen.
2. Sichern Sie Dateien und Datenbank und weisen Sie dann die Wiederherstellbarkeit in einer isolierten Kopie nach.
3. Wenden Sie Sicherheitskorrekturen in Staging an und testen Sie vor dem Produktiveinsatz den Checkout.
4. Geben Sie jedem Mitarbeiter ein eigenes Konto, ein starkes Passwort und einen zweiten Faktor.
5. Prüfen Sie beschreibbare Pfade, öffentliche Endpunkte und Überwachungswarnungen.

Ordnen Sie jeder Maßnahme einen Verantwortlichen und ein Prüfdatum zu. Prüfen Sie Zugriffe nach Personalwechseln und wiederholen Sie regelmäßig die umfassendere Prüfung. Schützen Sie Staging durch Authentifizierung und deaktivieren Sie dort echte Zahlungen, Kundenmails und produktive Integrationen.

PrestaShop und PHP im Support halten

Kompatibilität und Sicherheitswartung sind getrennte Fragen. PrestaShop 8.0 bis 8.2 unterstützt PHP nur bis 8.1. PrestaShop 9.0 unterstützt PHP 8.1 bis 8.4; 9.1 unterstützt 8.1 bis 8.5. Auch Version 9.2 unterstützt PHP 8.1 bis 8.5. Gleichen Sie vor einem PHP-Wechsel die genaue Version und jedes Modul ab. Siehe die Kompatibilitätstabelle und Anforderungen für 9.2.

Stand 26. Oktober 2026 hat PHP 8.1 sein Lebensende bereits erreicht. Der Upstream-Sicherheitssupport endete am 31. Dezember 2025. Der Support für PHP 7.4 endete am 28. November 2022. Prüfen Sie neben der Plattformkompatibilität den PHP-Lebenszyklus. Planen Sie ein Plattformupgrade, wenn Ihr Shop keine gewartete Laufzeit nutzen kann; prüfen Sie etwaige Vereinbarungen über erweiterten Support ausdrücklich.

Die reguläre Upstream-Wartung von PrestaShop 1.7 endete mit der Veröffentlichung von 9.0. Ein ausnahmsweise späterer Hotfix ist keine fortlaufende Zweigwartung. Auch PrestaShop 1.6 wird offiziell nicht mehr gewartet. Beachten Sie die Wartungsrichtlinie und planen Sie Ihre Migration.

Aktualisieren Sie auch Betriebssystem, Datenbank, Webserver und Module. Führen Sie ein Modulinventar und abonnieren Sie Anbieterhinweise sowie die Sicherheitshinweise von Friends of Presta. Eine Versionsnummer allein belegt nicht, dass ein bestimmter Exploit anwendbar ist.

Planen Sie Änderungen über PHP- und PrestaShop-Versionen hinweg mit der Migrationscheckliste.

Änderung und Rückweg proben

Strengere Uploadregeln können beispielsweise Kundenanhänge schützen und zugleich ein Modul stören, das sie über einen alten Endpunkt verarbeitet. Dokumentieren Sie zuerst die tatsächlichen Routen dieses Moduls. Proben Sie normale Uploads und gesperrte ausführbare Dateinamen getrennt, damit ein funktionierendes Produktbild keinen defekten Anhangsablauf verdeckt.

1. Erfassen Sie aktuelle Konfiguration, betroffene Pfade, Integrationszugangsdaten und einen zusammengehörigen Wiederherstellungspunkt für Dateien und Datenbank. Dokumentieren Sie das Sollverhalten vor jeder Änderung.
2. Erstellen Sie die geschützte Kopie mit denselben relevanten Serverhandlern, Proxyregeln, Modulen und demselben Theme. Beschränken Sie den Zugriff auf kopierte Kundendaten und ersetzen Sie produktive Ziele durch Testdienste oder kontrollierte Testnachbildungen.
3. Führen Sie jeweils eine logisch zusammengehörige Änderung durch. Ein gleichzeitiger PHP-Wechsel, Modulaustausch und eine Firewalländerung erschweren die Fehlerzuordnung.
4. Testen Sie erlaubte und verweigerte Aktionen: Mitarbeiteranmeldung und Wiederherstellung, Zugriffsversuche außerhalb einer Rolle, Katalogaufrufe, Uploads, Bestellprozess, Zahlungsbenachrichtigungen, Erstattungen, geplante Jobs und Partnerabgleich, soweit zutreffend.
5. Proben Sie die Rücknahme. Die Wiederherstellung einer Konfigurationsdatei, das Zurücksetzen ausgerollten Codes und eine Datenbankwiederherstellung haben unterschiedliche Folgen; bestimmen Sie, was die Änderung erfordert und wer es ausführen kann.
6. Vereinbaren Sie Umstellungsfenster, Freigabe-/Abbruchprüfungen und Rücknahmeauslöser. Werden Daten zwischen Installationen verschoben, definieren Sie das Pausieren oder Abgleichen von Schreibvorgängen und den Umgang mit eingehenden Zahlungsbenachrichtigungen.
7. Prüfen Sie nach der Umstellung echte Bestellverarbeitung und Warnkanal. Bewahren Sie Testergebnisse, geänderte Einstellungen und Wartungsanweisungen für die nächste Veröffentlichung auf.

Eine Datenbankwiederherstellung kann Bestellungen nach dem Wiederherstellungspunkt löschen. Vereinbaren Sie für eine Migrationsrücknahme vor dem Rückwechsel den Abgleich dieser Bestellungen und Anbieterzahlungen. Halten Sie die bisherige Umgebung geschützt, solange sie zur Wiederherstellung aufbewahrt wird.

Für einen älteren Shop, der eine gewartete Plattform benötigt, bewertet der PrestaShop Upgrade Service: Any Version to PrestaShop 9 vor einem schriftlichen Angebot bestehende Version, PHP, Hosting, Theme und Module und arbeitet vor der Produktivumstellung auf Staging.

Backoffice-URL finden oder ändern

Das Backoffice liegt in einem physischen Verzeichnis im Shopstamm. Ist der Shop unter /shop/ installiert, setzen Sie diesen Basispfad vor das Adminverzeichnis. Finden Sie es über SFTP, den Dateimanager Ihres Hosters oder SSH.

Suchen Sie den Shopstamm mit classes/, modules/ und themes/. Mögliche Verzeichnisnamen beginnen häufig mit admin, ein umbenanntes Verzeichnis kann aber anders heißen. Prüfen Sie dessen index.php auf den Admin-Bootstrap und die Definition von _PS_ADMIN_DIR_. Ein Unterverzeichnis controllers/ darin ist nicht erforderlich.

Die standardmäßige app/config/parameters.php speichert den Namen des Adminordners nicht. Halten Sie den vorhandenen zufälligen Namen vertraulich oder benennen Sie den tatsächlichen Ordner in einem abgestimmten Zugriffszeitfenster um. Es muss keine Standard-Datenbankeinstellung daran angepasst werden.

1. Halten Sie einen funktionierenden SFTP- oder Hostingzugang bereit.
2. Bitten Sie Kollegen, sich abzumelden, und benennen Sie dann das Verzeichnis um.
3. Aktualisieren Sie individuelle Proxy-, Firewall-, Zeitplan- oder Modulverweise auf den alten Pfad.
4. Öffnen Sie die neue HTTPS-URL und testen Sie die Anmeldung.
5. Aktualisieren Sie Lesezeichen und Passwortmanager-Einträge. Prüfen Sie, dass der alte Pfad das Backoffice nicht mehr öffnet.

Ein Symlink vom alten Namen hält diesen Einstiegspunkt erreichbar. Ein vertraulicher Pfad reduziert beiläufige Scans, braucht aber weiterhin starke Authentifizierung und Zugriffsbeschränkungen.

Passwörter, Zwei-Faktor-Authentifizierung und Mitarbeitersitzungen

Öffnen Sie in modernen Versionen Erweiterte Einstellungen > Team > Mitarbeiter, Profile und Berechtigungen. In PrestaShop 1.6 liegen diese Seiten unter Verwaltung. Geben Sie jeder Person ein namentliches Mitarbeiterkonto. Teilen Sie den Inhaberzugang nicht.

Verwenden Sie lange, einzigartige, vom Passwortmanager generierte Passwörter. Ein zufälliges Passwort mit mindestens 16 Zeichen ist eine praktikable Vorgabe. Ändern Sie kompromittierte oder mehrfach verwendete Passwörter umgehend. Regelmäßige erzwungene Wechsel ersetzen weder Länge noch Einzigartigkeit. Der moderne Core nutzt seinen Crypto-Hashing-Dienst mit bcrypt und Prüfung älterer Hashes; setzen Sie Passwörter nicht mit reinem MD5 zurück.

Backoffice-TOTP erfordert ein kompatibles Modul oder eine externe Identitäts-/Zugriffsebene. Der Core bietet keinen universellen TOTP-Schalter, wie ihn viele ältere Anleitungen beschreiben. Ein externer Identitätsanbieter kann ebenfalls persönliche MFA durchsetzen. TOTP reduziert Angriffe allein mit Passwörtern, aber Angreifer können einen aktuellen Code durch Phishing weiterleiten. Korrekt implementierte WebAuthn/FIDO-Authentifizierung bietet eine andere Widerstandsfähigkeit gegen Phishing. Siehe die NIST-Authentifizierungsrichtlinien.

Testen Sie Einrichtung und Wiederherstellung, bevor Sie den zweiten Faktor für das Team vorschreiben. Bewahren Sie Wiederherstellungscodes außerhalb des Telefons auf, prüfen Sie Server- und Telefonuhr und dokumentieren Sie das Wiederherstellungsverfahren des Werkzeugs. Der Core hat keine standardmäßigen 2FA-Mitarbeiterspalten zum Leeren.

Security Revolution ergänzt Mitarbeiter-TOTP, Ersatzcodes, Anmeldekontrollen, Sicherheitsheaderverwaltung und Dateivergleiche mit einem Referenzstand; folgen Sie der Modulhilfe für Konfiguration und Wiederherstellung.

Cookie-Ablauf und Inaktivität trennen

PS_COOKIE_LIFETIME_BO wird in Stunden gemessen. Es steuert die Cookielebensdauer, keine allgemeine Inaktivitätsrichtlinie. Daueranmeldung und Inaktivitätsprüfungen unterscheiden sich je Version; PrestaShop 1.7.8 hat im betreffenden Anmeldemodus eine separate einstündige Prüfung der letzten Aktivität. Testen Sie das tatsächliche Abmeldeverhalten.

PS_PASSWD_TIME_BACK wird in Minuten gemessen und bezieht sich auf die letzte Passwortgenerierung. Es garantiert keinen zeitlichen Abstand zwischen Anfragen für Passwort-Reset-Mails. Ergänzen Sie bei Bedarf eine separate Anfragedrosselung.

Verlangen Sie HTTPS und prüfen Sie das tatsächliche Admincookie auf Secure- und HttpOnly-Flags sowie eine geeignete SameSite-Richtlinie. PHP-Sitzungscookie-Einstellungen steuern nicht zwingend jedes PrestaShop-Cookie. Sperren Sie unbeaufsichtigte Arbeitsplätze und widerrufen Sie Sitzungen bei kompromittierten Geräten oder Konten.

Einrichtung und Wiederherstellung mit gewöhnlichem Mitarbeiter nachweisen

1. Verwenden Sie einen namentlichen Mitarbeiter im vorgesehenen Berechtigungsprofil, statt nur als SuperAdmin zu testen.
2. Schließen Sie die Einrichtung ab, melden Sie sich ab und testen Sie eine neue Anmeldung. Bestätigen Sie, dass die geschützte Route nicht durch Überspringen der Zweitfaktorseite erreichbar ist.
3. Testen Sie die dokumentierte Wiederherstellung bei Geräteverlust mit einer verfügbaren autorisierten Hilfsperson. Bestätigen Sie, was die Wiederherstellung ungültig macht und wie der Mitarbeiter ein Ersatzgerät einrichtet.
4. Prüfen Sie die Einrichtung jedes aktiven Mitarbeiters, einschließlich Auftragnehmern und selten genutzten Konten. Definieren Sie, wer Ausnahmen genehmigt und wann sie enden.

CAPTCHA für Kundenformulare und Mitarbeiterauthentifizierung betreffen getrennte Bereiche. Schutz für die Storefront-Anmeldung belegt keine Absicherung der Backoffice-Anmeldung; testen Sie die tatsächliche Mitarbeiterroute.

Zugriff beschränken und fehlgeschlagene Anmeldungen erkennen

Nutzt Ihr Team eine feste Büroadresse oder ein VPN, beschränken Sie das Backoffice am Proxy oder Server. Halten Sie einen autorisierten Wiederherstellungsweg bereit und testen Sie erlaubte sowie gesperrte Adressen. Konfigurieren Sie bei einem Reverse Proxy die vertrauenswürdige Verarbeitung der Client-IP, bevor Sie IP-Regeln nutzen.

Für Apache 2.4 folgt ein Beispiel für ein Adminverzeichnis, dessen autorisiertes Büro das gezeigte Dokumentationsnetz nutzt. Verwenden Sie beim Einsatz Ihr eigenes freigegebenes Netzwerk.

Require ip 203.0.113.10
Require ip 198.51.100.0/24

Drosseln Sie fehlgeschlagene Authentifizierungen mit einem für die Anmelderoute Ihrer Version getesteten Mechanismus. Leiten Sie Fehlschläge nicht aus HTTP 200 oder 302 ab: Erfolgreiche und erfolglose Versuche können dieselben Codes haben. Ein fail2ban-Filter braucht fehlerspezifische Protokolle und Tests, die belegen, dass erfolgreiche Anmeldungen nicht gesperrt werden.

Core-Protokolle sind unvollständige Nachweise. PrestaShop 1.6, 1.7.8 und 8.2 protokollieren erfolgreiche Backoffice-Verbindungen mit Mitarbeiter und Quell-IP. Fehlanmeldungserkennung, Standortanalyse und Warnungszustellung benötigen eigene Kontrollen. Halten Sie Proxy-, Authentifizierungs- und Anwendungsprotokolle mit synchronisierten Zeitstempeln zusammen.

Individuelle Anmeldebenachrichtigungen müssen die richtige Integration nutzen: Kompatible ältere Versionen stellen actionAdminLoginControllerLoginAfter bereit; PrestaShop 9 nutzt Symfony-Authentifizierungsereignisse wie LoginSuccessEvent. Eine funktionierende E-Mail-Warnung benötigt außerdem registrierte Listener, echte übersetzte Vorlagen, einen Vorlagenpfad, erfolgreiche Zustellung und Fehlerbehandlung.

Dateirechte, Hosting-Identitäten und Cachefehler

Ermitteln Sie vor Eigentümeränderungen die Identität des PHP-Prozesses. PHP-FPM-Worker laufen mit dem im Pool konfigurierten Benutzer und der Gruppe, die von Nginx, Apache oder einem Root-Masterprozess abweichen können. Bei mod_php läuft PHP im Apache-Prozess. Bei kontobasiertem Hosting oder suPHP kann es als Ihr Hostingbenutzer laufen.

Für normalen lesbaren Anwendungscode sind 755 für Verzeichnisse und 644 für Dateien übliche Ausgangswerte. Das Ausführungsrecht eines Verzeichnisses erlaubt das Durchqueren. Eigentümer, Gruppe und ACLs bestimmen, wer schreiben kann. Wenn der PHP-Benutzer jede Codedatei besitzt, kann auch kompromittiertes PHP diese Dateien überschreiben. Bevorzugen Sie Code im Besitz des Deployment-Benutzers und eng begrenzte Laufzeitschreibrechte, wo Ihr Wartungsablauf dies unterstützt.

Halten Sie app/config/parameters.php in PrestaShop 1.7, 8 und 9 für PHP lesbar. Das ältere 1.6 nutzt config/settings.inc.php. Ein pauschaler Modus 400 kann den Shop lahmlegen, wenn PHP nicht Eigentümer ist. Nutzen Sie nicht 777, um Fehler beim Schreiben zu beheben. Verwundbares PHP kann weiterhin in ein 755-Verzeichnis schreiben, das ihm gehört.

Cache-Schreibfehler nach einer Migration beheben

1. Lesen Sie den genauen Fehlerpfad und prüfen Sie Eigentümer, Gruppe, Modus sowie Durchquerungsrechte der übergeordneten Verzeichnisse.
2. Prüfen Sie die tatsächliche Worker- und Poolkonfiguration von PHP-FPM.
3. Geben Sie der benötigten PHP-Identität über Eigentum, eine vertrauenswürdige Gruppe oder ACLs Lese-, Schreib- und Suchzugriff.
4. Entfernen Sie erst nach der Zugriffsreparatur generierte Cacheinhalte der betroffenen Umgebung und wärmen Sie den Cache als vorgesehener Laufzeitbenutzer auf.
5. Prüfen Sie Speicherplatz, Inodes, schreibgeschützte Mounts, SELinux/AppArmor, Chroot-Pfade und Deployment-umask, falls der Zugriff weiter scheitert.

Dieses Beispiel setzt voraus, dass Sie bestätigt haben, dass der PHP-Worker als www-data läuft und diesen Cache besitzen soll. Es nutzt erhöhte Rechte für alle Modusänderungen und ändert Dateien getrennt von Verzeichnissen.

sudo chown -R www-data:www-data /var/www/html/var/cache
sudo find /var/www/html/var/cache -type d -exec chmod 750 {} +
sudo find /var/www/html/var/cache -type f -exec chmod 640 {} +

Moderne beschreibbare Pfade umfassen var/cache/, Protokolle, img/, upload/ und download/. Modulinstallation, Themeänderungen, Übersetzungen und Updates benötigen zusätzliche vorübergehende Schreibrechte. Ältere Smarty-Caches von 1.6 können unter cache/smarty/ liegen. Trennen Sie Updater-Berechtigungen von normalen Storefront-Berechtigungen.

Vergleichen Sie in Docker die numerischen UID/GID innerhalb und außerhalb des Containers. Bind-Mounts behalten Hosteigentümer. Auch benannte Volumes benötigen passende Initialisierung und Eigentümerschaft; sie gewähren PHP nicht automatisch Zugriff. Vermeiden Sie wiederkehrendes chown über den gesamten Verzeichnisbaum als Ersatz für ein bewusstes Identitätsmodell.

Prüfen Sie bei Uploadfehlern auch die PHP-Uploadgrenzen. Prüfen Sie bei einer leeren Seite nach chmod die Verzeichnisdurchquerung und das PHP-Protokoll. Kontrollieren Sie SFTP-Client-Berechtigungen und umask, wenn Uploads die Modi immer wieder verändern.

Konfiguration, Uploads und PHP-Laufzeit schützen

Schalten Sie produktive Debugausgaben ab. Setzen Sie _PS_MODE_DEV_ auf false in config/defines.inc.php und prüfen Sie die zutreffende Einstellung Erweiterte Einstellungen > Leistung > Debugmodus. Protokollieren Sie Fehler an einem geschützten Ziel. Prüfen Sie die wirksamen Web-SAPI-Einstellungen, statt sich auf CLI-PHP zu verlassen. Eine kleine Grundkonfiguration umfasst display_errors=Off, log_errors=On, expose_php=Off und allow_url_include=Off.

Das Deaktivieren von Prozessfunktionen wie exec, system, shell_exec, passthru, popen und proc_open kann einige Schadfunktionen begrenzen, aber legitime Aufgaben stören. PHP-FPM-Pools können php_admin_value[disable_functions] zusätzlich zur php.ini setzen. Starten Sie den richtigen Dienst neu, prüfen Sie die Weblaufzeit und testen Sie Bildverarbeitung, Importe und PDF-Aufgaben. Dies hindert PHP nicht daran, beschreibbare Daten zu lesen oder Datenbankzugangsdaten zu verwenden.

open_basedir kann Pfade einschränken, benötigt aber alle legitimen temporären und Anwendungspfade. Behandeln Sie es als zusätzliche Beschränkung, nicht als Sandbox. Lassen Sie keine permanente phpinfo- oder Test-Shell-Datei öffentlich erreichbar.

Vertrauliche HTTP-Pfade sperren

Deaktivieren Sie Verzeichnisauflistungen. Sperren Sie öffentlichen Zugriff auf Konfiguration, Protokolle, Backups, SQL-Dumps, Repository-Metadaten und Abhängigkeitsmanifeste. Bewahren Sie Backups außerhalb des Webroots auf. Eine korrekt ausgeführte PHP-Parameterdatei gibt ihr zurückgegebenes Array nicht aus, aber offengelegter Quelltext oder eine Sicherungskopie kann Zugangsdaten enthüllen.

Erhalten Sie bei Dotfile-Beschränkungen notwendige Zertifikatspfade unter /.well-known/. Sperren Sie nicht blind jede PHP-Datei in Modulen: Callbacks, Cronjobs und ältere AJAX-Endpunkte können darauf angewiesen sein.

Verhindern, dass hochgeladene Skripte PHP erreichen

Decken Sie img/, upload/ und download/ ab, einschließlich alternativer ausführbarer Erweiterungen und Namen mit mehreren Erweiterungen. Prüfen Sie die tatsächliche PHP-Handlerkonfiguration. Dieses Virtual-Host-Beispiel für Apache 2.4 sperrt übliche ausführbare Dateinamen in diesen Pfaden:

<DirectoryMatch "/var/www/html/(img|upload|download)(/|$)">
    <FilesMatch "(?i)\.(php[0-9]?|phtml|phar)(\.|$)">
        Require all denied
    </FilesMatch>
</DirectoryMatch>

DirectoryMatch gehört in die Server- oder Virtual-Host-Konfiguration. php_admin_flag engine off ist spezifisch für mod_php und darf nicht ungeschützt in PHP-FPM-Konfigurationen kopiert werden. Schließen Sie bei PHP-FPM diese Pfade auch von der FastCGI-Ausführung aus.

Setzen Sie unter Nginx eine sperrende Location für ausführbare Namen vor eine allgemeine PHP-Regex-Location, passen Sie sie an etwaige Shopunterverzeichnisse an und prüfen Sie alle Handler-Locations. Zum Beispiel:

location ~* ^/(img|upload|download)/.*\.(php[0-9]?|phtml|phar)(\.|$) {
    return 403;
}
autoindex off;

Validieren Sie die Serverkonfiguration und testen Sie dann gesperrte Dateinamen sowie normale Bilder, Kunden-Uploads, Downloads und Zahlungs-Callbacks. Stimmen Sie die Regeln auf jede Erweiterung ab, die Ihr Server tatsächlich ausführt.

HTTPS, Sicherheitsheader und CSP

Installieren und erneuern Sie ein gültiges Zertifikat, aktivieren Sie SSL und SSL auf allen Seiten in modernen Versionen unter Shop-Einstellungen > Allgemein und prüfen Sie dann HTTP-Weiterleitungen, Checkout und gemischte Inhalte. In 1.6 liegen die allgemeinen Einstellungen unter Voreinstellungen. Browser blockieren aktive gemischte Inhalte wie Skripte und können gemischte Medien auf HTTPS umstellen. Finden Sie sie über Browserkonsole und Netzwerkansicht.

Leiten Sie zu Ihrem konfigurierten vertrauenswürdigen Host weiter. Berücksichtigen Sie TLS-Terminierung am Proxy, um Schleifen zu vermeiden. Ergänzen Sie HSTS erst, wenn HTTPS zuverlässig funktioniert; verwenden Sie includeSubDomains nur, wenn jede betroffene Subdomain HTTPS unterstützt.

Prüfen Sie X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Einbettungsbeschränkungen und eine geeignete Permissions-Policy. Testen Sie eingebettete Zahlungs- und andere Integrationen, bevor Sie Einbettungsbeschränkungen durchsetzen.

Eine Content Security Policy stufenweise einführen

default-src liefert Ausweichwerte. script-src steuert Skripte; style-src, img-src und font-src steuern andere Ressourcen; connect-src steuert Skriptverbindungen. frame-src steuert eingebettete Frames, während frame-ancestors festlegt, wer Ihre Seite einbetten darf. form-action begrenzt Ziele von Formularübermittlungen. Erwägen Sie nach Integrationstests object-src 'none' zum Sperren von Object- und Embed-Inhalten sowie base-uri 'self' zur Begrenzung von Basis-URLs. Setzen Sie base-uri, form-action und frame-ancestors ausdrücklich: Sie fallen nicht auf default-src zurück.

1. Beginnen Sie mit Content-Security-Policy-Report-Only.
2. Prüfen Sie Browserdiagnosen bei Produkt-, Warenkorb-, Konto-, Kontakt-, Checkout-, Weiterleitungs- und 3-D-Secure-Abläufen.
3. Stellen Sie für gesammelte Berichte einen Empfangsdienst bereit, konfigurieren Sie Reporting-Endpoints mit report-to sowie einen geeigneten report-uri-Fallback und weisen Sie den Eingang eines absichtlichen Testverstoßes nach.
4. Erstellen Sie eine Freigabeliste aus tatsächlich benötigten Ursprüngen. Entfernen Sie pauschale Freigaben für https:, 'unsafe-inline' und 'unsafe-eval', wo kompatible Nonce-/Hash- und Vorlagenunterstützung dies erlaubt.
5. Wechseln Sie nach Tests zur Durchsetzung und überwachen Sie Berichte weiter.

Ein Report-only-Header blockiert nichts. Ohne funktionierenden Empfänger sagt ein leeres Serverprotokoll nichts über Verstöße aus. Vertrauen Sie gemeldeten Ursprüngen nicht automatisch und übernehmen Sie sie nicht ungeprüft in die Freigabeliste. Berichtsrichtlinien sind in CSP Level 3 definiert.

Eine Richtlinie, die 'self' erlaubt, kann weiterhin ein infiziertes lokales Skript oder ein Relay desselben Ursprungs zulassen. Unabhängig geschützte Skriptintegritätsprüfungen, Serverüberwachung und aktualisierter Code bleiben notwendig.

Module, Datenbankzugriff und öffentliche Einstiegspunkte

Installieren Sie Module aus Quellen mit klarer Verantwortlichkeit. Prüfen Sie Pflege, Änderungsprotokolle, Sicherheitskorrekturen und Paketintegrität. Nicht vertrauenswürdige oder veränderte Pakete können Schadsoftware enthalten. Ein Eintrag auf einem seriösen Marktplatz beweist nicht, dass Code frei von Sicherheitslücken ist.

Das Deaktivieren eines Moduls sperrt normalerweise dessen standardmäßige ModuleFrontController-Routen. Eigenständige PHP-Skripte können ausführbar bleiben. Sichern Sie vor der Deinstallation ungenutzter Software Geschäftsdaten und prüfen Sie Abhängigkeiten, Callbacks und geplante Aufgaben; entfernen Sie anschließend die Dateien.

Eine Codeprüfung sollte Anfragedaten durch Autorisierung, Typvalidierung, SQL, Dateischreibvorgänge und Ausgabe-Escaping verfolgen. eval oder dekodierte ausführbare Nutzdaten erfordern genaue Prüfung. file_get_contents ruft Bytes ab, statt sie auszuführen; prüfen Sie daher Ziel und anschließende Verwendung. Die Ausführung von String-Assertions wurde in PHP 8 entfernt. Integer-Casts und pSQL() behandeln bestimmte SQL-Eingaben; sie sind keine vollständige Sicherheitsprüfung.

Nutzen Sie ein dediziertes Datenbankkonto, beschränkt auf die Shopdatenbank, kein Datenbankadministratorkonto. Erteilen Sie die für die tatsächlichen Laufzeit- und Wartungsvorgänge nötigen Rechte. Vermeiden Sie unnötige globale, FILE- oder Administratorrechte. Beschränken Sie den Netzwerkzugriff auf die Datenbank und nutzen Sie bei entfernter Datenbank eine private Verbindung.

Schützen oder entfernen Sie öffentliche Datenbankverwaltungstools. Bevorzugen Sie einen authentifizierten privaten Zugang oder SSH-Tunnel und deaktivieren Sie Webanmeldungen ohne Passwort oder als root. Ein anderes Tabellenpräfix repariert keine SQL-Injection.

Löschen Sie den Ordner install nach der Einrichtung und prüfen Sie nach jedem Umzug und jeder Wiederherstellung, dass er nicht zurückgekehrt ist: Über einen erreichbaren Installer kann jeder die Einrichtung erneut starten und den Shop übernehmen. Im April 2026 fand Sansec mehr als 200 PrestaShop-Shops mit offenem Installer.

Webservice-Zugriff, Fulfilment-Partner und Ausscheiden von Mitarbeitern

Deaktivieren Sie unter Erweiterte Einstellungen > Webservice die API, wenn sie ungenutzt ist. Vergeben Sie andernfalls pro Integration einen separaten Schlüssel, beschränken Sie Ressourcen und Methoden, verlangen Sie HTTPS, speichern Sie Geheimnisse sicher und widerrufen Sie ungenutzte Schlüssel. Prüfen Sie eingesetzte Admin-API-Clients und Scopes gesondert.

Erstellen Sie die Zugriffsliste eines 3PL anhand seiner tatsächlichen Anfragen. Bestellungen enthalten Adress-IDs; für den Versand können daher neben Bestellungen und Bestelldetails auch Adress-, Länder-, Bundesland-, Versanddienstleister- und Kontaktdaten nötig sein. Erlauben Sie nur, was der Workflow benötigt.

Ressourcenberechtigungen isolieren weder einzelne Felder noch einzelne Bestellungen. Bestelldetails können Einkaufskostenfelder offenlegen. Eine vom Client gewählte Anzeigeliste ist keine Zugriffsgrenze. Darf ein Partner keine Kosten oder fremden Bestellungen sehen, stellen Sie einen serverseitig kontrollierten gefilterten Endpunkt oder Export bereit.

Trackingaktualisierungen und Bestellstatusänderungen nutzen getrennte Wege. Das Erstellen einer order_histories-Ressource ändert den Status; ergänzen Sie sendemail=1, um dessen konfigurierte Statusmail anzufordern. Der Status muss außerdem E-Mail aktiviert haben und eine passende Vorlage besitzen. Das Aktualisieren einer order_carriers-Ressource ändert das Tracking; dessen separate Option sendemail=1 fordert die Unterwegs-Nachricht an, die zusätzlich eine Tracking-URL des Versanddienstleisters benötigt. Beide Optionen senden standardmäßig keine E-Mail. Aktualisieren Sie Tracking vor dem Anfordern der zugehörigen Nachricht und deduplizieren Sie Wiederholungsversuche.

1. Deaktivieren Sie das Mitarbeiterkonto einer ausscheidenden Person sofort mit dem Zugriffsende.
2. Widerrufen Sie ihre persönlichen Webservice-Schlüssel, API-Clients sowie Hosting-, SFTP-, SSH-, E-Mail- und Drittanbieterzugänge.
3. Machen Sie Sitzungen ungültig und wechseln Sie gemeinsame Geheimnisse, die der Person bekannt waren.
4. Bewahren Sie nützliche Bestell- und Prüfzuordnungen auf.
5. Prüfen Sie geplante Aufgaben, Zuständigkeiten und Wiederherstellungskontakte.

Ein Profil ist eine wiederverwendbare Berechtigungsrolle, kein Zugang mit Aktivschalter. Das Ändern oder Löschen eines gemeinsamen Profils kann andere Mitarbeiter betreffen. API-Konzepte erläutert der Webservice-Leitfaden.

Praxisbeispiel: Übergabe an ein Lager

Angenommen, ein Lager benötigt bezahlte Bestellungen und muss Tracking zurückliefern, darf aber keine Einkaufskosten erhalten. Beginnen Sie mit einer Testbestellung und der tatsächlichen Anfrageliste des Lagers. Legen Standard-Ressourcenrechte Felder außerhalb dieser Vereinbarung offen, filtern Sie in Ihrer serverseitig kontrollierten Integration, statt den vom Lager angeforderten Anzeigefeldern zu vertrauen.

Führen Sie die Übergabe in Staging mit an ein Testpostfach abgefangenen E-Mails durch. Rufen Sie vereinbarte Bestell- und Adressdaten ab und versuchen Sie dann über den Partnerzugang, Einkaufskosten und eine nicht zugehörige Bestellung abzurufen; keiner der Versuche darf ausgeschlossene Daten offenlegen. Aktualisieren Sie Tracking vor den vereinbarten Status- und E-Mail-Aktionen. Wiederholen Sie dasselbe Lagerereignis und bestätigen Sie, dass die Wiederholungsbehandlung doppelte Verlaufseinträge und Nachrichten verhindert. Widerrufen Sie den Testschlüssel des Lagers und bestätigen Sie, dass die nächste Anfrage scheitert; dies belegt, dass Sie die Integration beenden und starten können.

Ausscheiden prüfen, statt nur einen Namen zu entfernen

Testen Sie nach den obigen Austrittsschritten, dass sowohl die bestehende Sitzung als auch eine neue Anmeldung des ausgeschiedenen Mitarbeiters abgelehnt werden und widerrufene API-Zugangsdaten scheitern. Bestätigen Sie, dass übrige Mitarbeiter weiterarbeiten können. Bleibt eine alte Sitzung nutzbar, untersuchen Sie die Sitzungskontrollen der Version oder Zugriffsebene, statt vom Ungültigmachen durch den Mitarbeiterschalter auszugehen. Prüfen Sie, dass Wiederherstellungsadressen, Zugangsdaten geplanter Jobs und Backupziele nun einer verantwortlichen Person zugeordnet sind.

Mit kontrolliertem Zugriff einstellen und delegieren

Ermitteln Sie den Engpass, bevor Sie Hilfe hinzunehmen. Prüfen Sie das Alter offener Supportvorgänge, Verzögerungen zwischen Zahlung und Versand, Bestandsfehler, übersehene Anfragen und Arbeit, die während Ihrer Abwesenheit liegen bleibt. Messen Sie die erste Antwort anhand von Nachrichtenzeitstempeln oder einem Helpdesk-Bericht; die Core-Liste ist kein vollständiges Antwortzeit-Dashboard.

Umsatz oder Bankbewegungen allein liefern keine Nettomarge je Bestellung. Vergleichen Sie mit der folgenden Berechnung die Vollkosten der Hilfe mit dem zusätzlichen Beitrag, den Ihre freigewordene Zeit realistisch erzeugen kann, und berücksichtigen Sie saisonale Nachfrage.

Erstellen Sie zur Aufnahme einer Person die Rolle unter Team > Profile, konfigurieren Sie Berechtigungen und erstellen Sie dann den Mitarbeiter mit diesem Profil und nur relevantem Shopzugriff. Testen Sie die Rolle durch Anmeldung als diese Person, einschließlich direkter URLs und Drittanbieter-Modulaktionen. Ein ausgeblendetes Menü genügt nicht als Autorisierungsprüfung. Beschränken Sie Modulinstallation, SQL-Manager und Mitarbeiterverwaltung streng. Modulinstallationsrechte erlauben das Einbringen serverseitigen PHP-Codes und sind daher als Deployment-Berechtigung zu behandeln.

Dokumentieren Sie Bestellstatusablauf, Retouren-/Erstattungsregeln, Bestandsverfahren und Supporteskalation. Vordefinierte Bestellnachrichten werden auf der Bestellseite gewählt. Kundendienstvorgänge haben eigenes Signatur-/Standardantwortverhalten; ein gemeinsamer Textbausteinkatalog benötigt eine geeignete Helpdesk-Integration.

Halten Sie Produktstrategie, Lieferantenauswahl, Markenausrichtung und Kundenrichtlinien unter klarer Verantwortung. Lagern Sie definierte Ausführung aus, wenn Qualitätsmaßstab, Häufigkeit, benötigter Kontext und Kosten dies rechtfertigen. Vergleichen Sie Lager-, Wareneingangs-, Kommissionier-/Pack-, Versand-, Retouren- und Mindestgebühren eines 3PL mit Ihren eigenen Kosten.

Geben Sie Dienstleistern ein schriftliches Briefing, Abnahmebeispiele, einen Kommunikationsplan und klare Eigentumsregelungen für Inhalte und Zugangsdaten. Bewerten Sie laufende Auftragnehmerarbeit neu, wenn Koordination zum Engpass wird. Der Beschäftigungsstatus hängt von lokalen Regeln und dem tatsächlichen Verhältnis ab, nicht von einer Wochenstundenschwelle. Bevorzugen Sie Hooks, Service-Dekoration und unterstützte Theme-Erweiterungspunkte vor exklusiven Legacy-Overrides.

Hilfe anhand des Engpasses wählen

Rechnen Sie eine Einstellung mit Ihren eigenen Daten durch: Schätzen Sie zusätzliche Bestellungen, die frei gewordene Kapazität realistisch bedienen kann, und multiplizieren Sie mit dem Beitrag je zusätzlicher Bestellung nach Warenkosten, Zahlungsgebühren, Abwicklung, erwarteten Retouren und anderen variablen Kosten. Vergleichen Sie diesen Beitrag im selben Zeitraum mit Lohn oder Auftragnehmerhonorar, Arbeitgeberkosten, Einarbeitung, Betreuung und Werkzeugen. Fehlt realistische Zusatznachfrage, fehlt auch der Wachstumsbeitrag; die Begründung liegt dann bei Servicequalität, Kontinuität oder Arbeitslast statt angenommenem Umsatz.

Geben Sie einem Katalogauftragnehmer beispielsweise eine vereinbarte CSV-Zuordnung und Musterzeilen, bevor Sie Importrechte erteilen. Validieren Sie Produktreferenzen, Sprache und Shopumfang in Staging, prüfen Sie geänderte Produkte und geben Sie dann den Produktivimport frei. Ein Fotograf kann nach Referenz benannte Dateien ohne Backoffice-Anmeldung liefern; eine Spezialistenleistung erfordert nicht automatisch Shopzugriff.

Trafficfilterung und Shops vor der Migration

Eine WAF kann bestimmte Exploit-Anfragen blockieren, Missbrauch begrenzen und aufwendige Routen wie facettierte Such-URLs schützen. Testen Sie Regeln gegen Browsing, Checkout, APIs und Anbieter-Callbacks. Robots.txt ist ein Crawlerhinweis, keine Zugriffskontrolle. Länder- und IP-Sperren können legitime Kunden treffen, besonders hinter gemeinsam genutzten Netzwerken.

Wenn ein Proxy Ihren Shop schützt, beschränken Sie die Webports des Ursprungsservers auf vertrauenswürdige Proxynetze und notwendige Verwaltungswege. Decken Sie IPv4 und IPv6 ab und halten Sie Adresslisten aktuell. Mail-Einträge und altes DNS können eine Ursprungs-IP enthüllen. Regeln Sie SSH-, Mail- und Hostingpanel-Zugriff separat.

Die Ausdrucksfelder für Cloudflare-Rate-Limits variieren je Tarif: Free bietet pfadbasierte Felder, Pro ergänzt Query-Abgleich und Business Quell-IP- und User-Agent-Ausdrucksfelder. Zählung pro IP ist eine separate Funktion. Advanced Rate Limiting ist ein separates Enterprise-Angebot. Prüfen Sie die aktuelle Verfügbarkeit, bevor Sie eine queryabhängige Flood-Regel entwerfen.

CAPTCHA kann Storefront-Missbrauch reduzieren, benötigt aber Barrierefreiheits- und Fehlertests. reCAPTCHA & hCaptcha Protection deckt unterstützte Kundenformulare ab; folgen Sie der Modulhilfe zur Einrichtung.

Customer Extra Info (IP Ban) bietet Besucherinformationen und IP-Sperren; folgen Sie der Modulhilfe für den zutreffenden Geltungsbereich.

Während der Migration ausgleichende Schutzmaßnahmen nutzen

Identifizieren Sie die genaue verwundbare Komponente und den Sicherheitshinweis. Eine externe WAF-Abfangregel ist ein virtueller Patch; eine Quelltextänderung ist ein direkter Patch oder Backport. Verfolgen und testen Sie jede vorübergehende Maßnahme und legen Sie ein an Ihren Upgradeplan gebundenes Entfernungsdatum fest.

Prüfen Sie für die ältere Angriffskette über den Smarty-MySQL-Cache die betroffene Version und die Upstream-Abhilfe. In 1.7.8 ist _PS_SMARTY_CACHING_TYPE_ eine PHP-Konstante, die das Laden der MySQL-Cache-Ressource steuert. Sie ist kein Auswahlfeld auf der Leistungsseite. Prüfen Sie nach der Abhilfe die tatsächlich wirksame Cache-Ressource zur Laufzeit.

Prüfen Sie aufgegebene eigenständige Endpunkte einzeln, statt alle Modul-PHP-Dateien zu sperren. Dateiunveränderlichkeit ist eine optionale Administratorkontrolle für einzeln inventarisierte Dateien; manche Konfigurationsdateien werden von PrestaShop berechtigterweise geändert. Dokumentieren Sie das Entsperren zur Wartung und erneute Sperren danach.

Vorübergehende Schutzmaßnahmen überprüfbar machen

Dokumentieren Sie je temporärer Regel oder Backport betroffene Komponente und installierte Version, Sicherheitshinweis oder Protokollnachweis, abgedeckte Anfrage oder Codepfad, Verantwortlichen, Rücknahmeverfahren und die Migrationsabhängigkeit, die die Maßnahme ablöst. Eine breite Sperre verdächtiger Wörter kann kodierte Eingaben übersehen und legitime Suchen ablehnen; testen Sie den bestätigten Exploitpfad neben normalen Anfragen.

Ein älteres Suchmodul kann beispielsweise sowohl eine gezielte Korrektur eines betroffenen Abfragepfads als auch eine Trafficregel gegen aufwendige Crawleranfragen benötigen. Diese Kontrollen behandeln unterschiedliche Probleme. Belegen Sie, dass die gesperrte Anfrage abgelehnt wird, legitime Filter weiter funktionieren und der Ursprung den Proxy nicht umgehen kann. Bewahren Sie die Ergebnisse mit dem Migrationsplan auf. Prüfen Sie beobachtete WAF-Ereignisse vor der Durchsetzung, damit Zahlungs-Callbacks, nützliche Crawler und Kundentraffic in die Entscheidung einfließen.

Überwachung und praktische Selbstprüfung

Überwachen Sie neue und geänderte PHP-, JavaScript- und Vorlagendateien gegen einen vertrauenswürdigen Deployment-Referenzstand. Schützen Sie diesen separat, prüfen Sie Ausnahmen und planen Sie tatsächliche Scans und Warnungszustellung, wenn Sie unbeaufsichtigte Erkennung benötigen. Ein manueller Scan ist ein Vergleich zu einem bestimmten Zeitpunkt.

Vergleichen Sie den Core mit derselben sauberen Version und Moduldateien mit vertrauenswürdigen Paketen. Prüfen Sie unerklärte Mitarbeiterkonten, veränderte Zahlungseinstellungen, unbekannte Checkout-Felder und unerwartete Skripte. Dateiänderungen können auch legitime Deployments sein; untersuchen Sie Treffer, statt sie automatisch zu löschen.

Ersetzen Sie für eine schreibgeschützte Mitarbeiterprüfung bei Bedarf das Tabellenpräfix:

SELECT id_employee, email, id_profile, active, last_connection_date
FROM ps_employee
ORDER BY id_employee DESC;

Die standardmäßige Mitarbeitertabelle hat kein date_add. Eine steigende ID kann bei der Prüfung unbekannter Konten helfen, ist aber kein Erstellungszeitstempel. last_connection_date ist kein Feld zum Kontoalter.

Diese schreibgeschützten Suchen ab dem Shopstamm identifizieren Dateien zur Prüfung:

find img upload download -type f -iname '*.php*' -print
find img upload download -type f \( -iname '*.phtml*' -o -iname '*.phar*' \) -print
find . -type f -name '*.php' -mtime -14 -print
find . -type f -name '*.js' -mtime -14 -print
find . -type f -name '*.php' -exec awk 'length($0)>5000 {print FILENAME ":" FNR}' {} +

Lange Zeilen und kodierte Strings können legitim sein. Gleichen Sie mtime, ctime, unterstützte Erstellungszeitstempel, Protokolle und Snapshots ab. Ctime ist die letzte Änderung des Inode-Status, nicht die ursprüngliche Dateierstellung; Eigentums- und Modusänderungen können sie aktualisieren.

Überwachen Sie Startseiteninhalte, repräsentative Katalogseiten und Checkout-Verfügbarkeit, nicht nur HTTP 200. Prüfen Sie Zertifikatserneuerungen unabhängig davon. Bestätigen Sie, dass Ihr gewählter Monitoringtarif Zertifikats- und Antwortzeitwarnungen enthält, und testen Sie die Zustellung an einen betreuten Kanal.

Eine Selbstprüfung sollte Softwareversionen, Modulupdates, Mitarbeiter, Dateivergleiche, Ursprungsbeschränkungen und ein wiederhergestelltes Backup abdecken. Ein schreibgeschütztes Mitarbeiterprofil macht nicht automatisch jeden Drittanbieter-Konfigurationsendpunkt für einen Prüfer sicher; vereinbaren Sie nötigen Zugriff und Datenumgang ausdrücklich. Nutzen Sie für externe Prüfungen ein temporäres Konto, geben Sie soweit möglich Lesezugriff auf Dateien und Protokolle und entfernen Sie das Konto nach Abschluss der vereinbarten Arbeit. Der Leitfaden zur Auditvorbereitung hilft bei dieser Übergabe.

Für eine erste lokale Prüfung liefert Security Scan kostenlos priorisierte Befunde und manuelle Korrekturschritte. Die Prüfung ist schreibgeschützt und hält Befunde im Shop; sie blockiert keinen Traffic, patcht keine Dateien und ändert keine Einstellungen. Geplante Scans und Warnungen bei kritischen Befunden unterstützen die Nachverfolgung, ein Punktwert kann aber keine Infektionsfreiheit belegen.

Aus Befunden den nächsten Schritt ableiten

Führen Sie jeden offenen Befund mit Ort, Nachweis, Verantwortlichem und nächstem Schritt. Eine unauffällige Selbstprüfung beantwortet nur tatsächlich durchgeführte Prüfungen. Eskalieren Sie unerklärte Befunde und wiederholen Sie relevante Prüfungen nach Upgrade, Themewechsel, neuer Integration oder Zugriffsübergabe.

Backups und Reaktion auf Vorfälle

Sichern Sie Datenbank und passende Dateien nach einem Zeitplan, der zu Ihrer Toleranz für Bestellverluste passt. Bewahren Sie mehrere Wiederherstellungspunkte auf, verschlüsseln Sie sensible Archive und halten Sie eine Kopie außerhalb des Servers unter separaten Zugangsdaten. Legen Sie die Aufbewahrung anhand von Wiederherstellungs- und Geschäftsanforderungen fest statt anhand einer pauschalen Tageszahl.

Nutzen Sie geschützte Datenbankzugangsdaten und ein Backuptool mit Fehlerprüfung. Bei Inline-Crontab-Befehlen müssen Prozentzeichen einmal maskiert werden; ein Skript für den Backupablauf vermeidet diese Falle. Testen Sie eine Wiederherstellung in einem isolierten Shop einschließlich Kundenanmeldung, Bildern, Bestellungen und Konfiguration. Siehe den Backupleitfaden.

Bei Verdacht auf Kompromittierung

1. Isolieren Sie den Shop auf einer vertrauenswürdigen Server- oder Proxyebene. Verhindern Sie weitere Käufe oder Datenoffenlegung und erhalten Sie den Zugriff für die Vorfallsbearbeiter.
2. Sichern Sie Beweismaterial: Datenbank, Dateien, relevante Protokolle und Zeitstempel. Bewahren Sie Kopien vor destruktiver Bereinigung sicher auf.
3. Ermitteln Sie Einstiegspunkt und Persistenzmechanismen, einschließlich Mitarbeiterkonten, geplanter Aufgaben und in die Datenbank eingeschleuster Inhalte.
4. Widerrufen Sie von einem sauberen Gerät und einer sauberen Umgebung aus Sitzungen und wechseln Sie offengelegte Hosting-, SSH-, SFTP-, Datenbank-, Mitarbeiter-, Mail- und Zahlungs-/API-Zugangsdaten. Stimmen Sie Konfigurationsänderungen ab, damit die Wiederherstellung funktioniert.
5. Bauen Sie aus vertrauenswürdigen Softwarepaketen neu auf, stellen Sie saubere Daten wieder her und schließen Sie dann den Einstiegspunkt. Übernehmen Sie kein kompromittiertes Theme, keinen Bildverzeichnisbaum und keine Datenbank ungeprüft.
6. Testen Sie vor der Wiedereröffnung Checkout, Zahlungen, Erstattungen, E-Mail und Integrationen. Überwachen Sie engmaschig auf Wiederholung.

Wenn Sie mit Apache einen Wartungsstatus zurückgeben, konfigurieren Sie ErrorDocument 503 separat. Eine Rewrite-Regel mit R=503 liefert die Ersetzung nicht selbst als Wartungsseite aus.

Benachrichtigen Sie je nach Fall Hoster, Zahlungsanbieter und Sicherheitsfachkräfte. Nach GDPR-Artikel 33 müssen Sie die Aufsichtsbehörde unverzüglich und möglichst innerhalb von 72 Stunden nach Bekanntwerden informieren, sofern ein Risiko für Personen nicht unwahrscheinlich ist. Artikel 34 verlangt bei voraussichtlich hohem Risiko grundsätzlich die unverzügliche Information betroffener Personen, vorbehaltlich seiner Ausnahmen. Nutzen Sie die EDPB-Leitlinien zu Datenschutzverletzungen und Ihr Datenschutzverfahren.

Bestätigen Sie vor der Wiedereröffnung, dass Debugausgaben abgeschaltet, temporäre Werkzeuge entfernt, verwundbare Endpunkte repariert oder entfernt, Zugangsdaten und Mitarbeiterzugriffe kontrolliert sind, Backups wiederhergestellt werden können und Warnungen die zuständige Person erreichen.

Wiederherstellungsentscheidungen vorab vereinbaren

Halten Sie fest, wer Eindämmung autorisieren, Hoster und Zahlungsanbieter kontaktieren, geschützte Backups abrufen und die Wiedereröffnung freigeben darf. Dokumentieren Sie tolerierbaren Bestellverlust und akzeptable Unterbrechung und messen Sie eine isolierte Wiederherstellung daran. Backups können dieselben schädlichen Dateien oder eingeschleusten Datenbankinhalte wie der produktive Shop enthalten; die Wahl des Wiederherstellungspunkts benötigt daher Nachweise zum Beginn des Einbruchs.

Prüfen Sie, welche personenbezogenen Daten Shop, Module, Exporte und Protokolle aufbewahren. Entfernen Sie unnötige Kopien über einen vereinbarten Aufbewahrungsprozess und beschränken Sie den Rest. Zusätzliche Daten ohne Geschäftsbedarf vergrößern die mögliche Angriffsbeute; auch ihre Kopie in Staging oder ein Vorfallsarchiv benötigt kontrollierten Zugriff.

Fragen an Entwickler oder Agentur

• Welche genaue Komponente und Version ist gefährdet, und welche Nachweise verbinden die vorgeschlagene Änderung mit dieser Gefährdung?
• Welche Kontrollen liegen bei Hoster, Proxy, Shop oder Modul, und wer pflegt sie nach der Übergabe?
• Welche bestehenden Themefunktionen, Zahlungsabläufe, Märkte und Partnerintegrationen wurden in Staging getestet, einschließlich verweigerter Aktionen und Wiederherstellung?
• Wie lauten Umstellungs- und Rücknahmeverfahren, und wie werden während einer Migration eingehende Bestellungen oder Zahlungen abgeglichen?
• Wo liegen Deploymentreferenz, Wiederherstellungsergebnisse und Nachweise zur Warnungszustellung, und wer reagiert auf fehlgeschlagene Prüfungen?
• Welche temporären Regeln, Zugangsdaten und Werkzeuge müssen entfernt werden, und welche Behebungsarbeiten liegen außerhalb der vereinbarten Bewertung?

Häufige Fragen von Shopbetreibern

Übernimmt Managed Hosting die Shopsicherheit?

Lassen Sie sich die Wartungsgrenzen schriftlich geben. Betriebssystem- und Serverwartung klären nicht, wer Ihre PrestaShop-Installation, Theme oder Module aktualisiert. Bestätigen Sie anhand Ihrer tatsächlichen Vereinbarung, wer Sicherheitshinweise prüft, Shopänderungen freigibt und auf Anwendungswarnungen reagiert.

Was, wenn mein Team keine festen Büro-IP-Adressen nutzen kann?

Prüfen Sie einen verwalteten VPN-Ausgang oder einen identitätsbasierten Zugriffsproxy mit individueller Authentifizierung. Testen Sie vor der Durchsetzung tatsächliche Arbeitsorte und Wiederherstellung bei Geräteverlust. Halten Sie einen freigegebenen Wiederherstellungsweg bereit, statt bei jeder Reise die Freigabeliste auszuweiten.

Sollte ich bei Verdacht auf einen Einbruch sofort einen Scanner installieren?

Vereinbaren Sie zuerst die Untersuchungsmethode mit dem Vorfallsbearbeiter. Softwareinstallation ändert Dateien und kann nützliche Beweise oder den zu vergleichenden Referenzstand verändern. Sichern Sie den betroffenen Zustand und veranlassen Sie eine Prüfung aus vertrauenswürdiger Umgebung, bevor Sie einer möglicherweise kompromittierten Installation Werkzeuge hinzufügen.

Wie sollte ich Helfern Protokolle oder Zugangsdaten senden?

Vereinbaren Sie einen geschützten Übertragungsweg und liefern Sie nur die für die Untersuchung nötigen Daten. Entfernen Sie sachfremde personenbezogene Daten und Geheimnisse aus gewöhnlichen Bildschirmfotos und Ticketanhängen; wird ein Originalprotokoll als Beweis benötigt, sichern Sie es separat unter kontrolliertem Zugriff. Nutzen Sie temporäre individuelle Zugänge, statt ein gemeinsames Inhaberpasswort in ein Ticket zu kopieren.

Können temporäre Regeln nach der Migration bleiben?

Prüfen Sie jede Regel anhand der tatsächlichen Angriffsfläche des migrierten Shops. Entfernen Sie veraltete Ausnahmen und nehmen Sie eine ausgleichende Regel erst außer Betrieb, wenn der zugrunde liegende verwundbare Pfad nachweislich behoben oder entfernt ist. Behalten Sie nützlichen Schutz und Überwachung bei, wenn sie weiterhin einen dokumentierten Zweck erfüllen.