PrestaShop-Sicherheit: Die vollständige Checkliste

Wie ein kompromittierter PrestaShop-Shop tatsächlich aussieht

Die meisten gehackten Shops, in die wir seit 2013 zur Bereinigung gerufen wurden, sahen von der Startseite aus völlig normal aus. Der Inhaber erfuhr erst davon, weil Google die Seite markierte, der Zahlungsdienstleister die Auszahlungen einfror oder ein Kunde wegen einer „seltsamen Weiterleitung nach dem Checkout" anrief. Zu diesem Zeitpunkt saß der Angreifer in der Regel schon seit Wochen drin.

Die Muster wiederholen sich. Ein anfälliges Drittanbieter-Modul gibt die Datenbank preis. Eine ausgespähte Admin-URL wird übers Wochenende per Brute Force angegriffen. Eine als Bild getarnte PHP-Shell landet in img/. Eine Hintertür injiziert einen Karten-Skimmer in order-confirmation.tpl. Nichts davon ist exotisch. Alles davon lässt sich mit der folgenden Checkliste verhindern.

Diese Seite ist das, was wir Kunden aushändigen, bevor wir der Betreuung ihres Shops zustimmen. Sie gilt für PrestaShop 1.6, 1.7, 8.x und 9.x, Pfade und PHP-Versionen verschieben sich leicht, die Härtung nicht. Für die nichttechnische Variante schicken Sie den Shop-Inhaber zu unserem Sicherheitsleitfaden in einfacher Sprache.

1. Wie PrestaShop-Shops wirklich gehackt werden

SQL-Injection in einem Drittanbieter-Modul

Das ist mit großem Abstand der Vektor Nummer eins. Der Kern ist einigermaßen kampferprobt; die Module sind es nicht. Ein Junior-Entwickler liefert einen Front-Controller aus, der $_GET['id'] direkt in eine Abfrage einbettet, ein automatisierter Scanner findet ihn, und der Angreifer leert ps_customer und ps_orders noch vor dem Mittagessen. Wir haben das bei Modulen vom offiziellen Addons-Marktplatz gesehen, nicht nur aus dubiosen Foren.

Brute Force auf den Admin-Bereich

PrestaShop hat kein natives Rate Limiting für das Admin-Login-Formular. Sobald ein Angreifer Ihr Admin-Verzeichnis kennt (und das wird er, denn die Hälfte der Shops, die wir prüfen, nutzt immer noch /admin/ oder /admin123/), feuert er Tausende von Passwortversuchen pro Minute ab. Jedes Konto mit welcome2024 oder dem Shop-Namen ist in Minuten verloren.

Nutzen Sie Login-Rate-Limits, IP-basierte Sperren und Warnmeldungen bei Angriffen auf Mitarbeiterkonten. Diese Maßnahmen ergänzen starke Passwörter und 2FA, ersetzen sie aber nicht.

Datei-Upload zur PHP-Shell

Ein „Profilbild"- oder „Produktbild"-Upload, der nicht den tatsächlichen Dateiinhalt prüft, sondern nur die Endung. Der Angreifer lädt shell.php.jpg hoch, der Server ist so konfiguriert, dass er alles ausführt, was im Pfad auf .php passt, Spiel vorbei. Die Lösung auf Webserver-Seite (PHP-Ausführung in img/, upload/, download/ blockieren) finden Sie weiter unten, einmal gesetzt, neutralisiert sie eine ganze Klasse schlechter Module.

End-of-Life-PHP und ungepatchte Software

PHP 7.4 ist seit November 2022 EOL. Wir sehen es immer noch in Produktion. Jeder öffentlich dokumentierte Exploit gegen PHP 7.x ist ein geschenkter Sieg für einen Angreifer, und dasselbe gilt für MySQL 5.7, Apache 2.2 und PrestaShop 1.7.6 mit drei Jahren ungepatchter CVEs.

Offengelegte Konfigurationsdateien

Ein falsch konfigurierter Webserver liefert fröhlich /.env, /.git/config oder /app/config/parameters.php an jeden aus, der danach fragt. Datenbankpasswort, Cookie-Schlüssel, Name des Admin-Ordners, alles, im Klartext, in einer einzigen GET-Anfrage. Diese Prüfung führen wir bei jedem Shop durch, den wir übernehmen.

Realitätscheck: „Mein Shop ist zu klein, um ein Ziel zu sein", das sagt uns jeder Inhaber, bevor die Rechnung für die Bereinigung kommt. Scanner lesen Ihre Über-uns-Seite nicht, sie durchkämmen jede IPv4-Adresse im Internet auf der Suche nach PrestaShop-Signaturen. Die Größe ist irrelevant.

2. Härtung auf Server-Ebene

PHP-Version und Konfiguration

Betreiben Sie die neueste PHP-Version, die Ihre PrestaShop-Version unterstützt, PHP 8.1+ für PS 8.x, PHP 8.1–8.4 für PS 9.x. Wenn Sie wegen eines Moduls auf etwas Älterem als PHP 8.1 festhängen, lautet die Antwort: das Modul ersetzen, nicht auf EOL-PHP bleiben.

Die php.ini-Härtung, die wir standardmäßig anwenden:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen
expose_php = Off
allow_url_include = Off
display_errors = Off
log_errors = On
session.cookie_httponly = 1
session.cookie_secure = 1
session.use_strict_mode = 1
session.cookie_samesite = Lax
open_basedir = /var/www/html:/tmp:/usr/share/php

Eine Handvoll Module (ältere Bildverarbeitungen, manche PDF-Generatoren) benötigt tatsächlich exec(). Öffnen Sie nicht die gesamte Liste wieder, um ein einziges Modul zum Laufen zu bringen. Reaktivieren Sie nur die eine Funktion, die es verlangt, protokollieren Sie die Entscheidung, und wenn Sie das Modul durch eines ersetzen können, das nicht in die Shell ausbricht, tun Sie das beim nächsten Wartungsfenster.

Dateiberechtigungen

Die drei Zahlen, auf die es ankommt:

755 für Verzeichnisse: der Eigentümer darf schreiben, alle anderen dürfen auflisten und durchqueren
644 für Dateien: der Eigentümer darf schreiben, alle anderen dürfen lesen
400 für app/config/parameters.php: nur der Eigentümer darf sie lesen. Diese Datei enthält Ihre Datenbank-Zugangsdaten. Behandeln Sie sie wie einen privaten Schlüssel.

chown -R www-data:www-data /var/www/html/prestashop
find /var/www/html/prestashop -type d -exec chmod 755 {} \\;
find /var/www/html/prestashop -type f -exec chmod 644 {} \\;
chmod 400 /var/www/html/prestashop/app/config/parameters.php

# Schreibbare Verzeichnisse, die PrestaShop benötigt
chmod -R 775 /var/www/html/prestashop/var/cache
chmod -R 775 /var/www/html/prestashop/var/logs
chmod -R 775 /var/www/html/prestashop/img
chmod -R 775 /var/www/html/prestashop/upload
chmod -R 775 /var/www/html/prestashop/download

Wenn ein Tutorial, ein Support-Artikel oder ein Hosting-Helpdesk Ihnen sagt, Sie sollten irgendetwas auf chmod 777 setzen, ignorieren Sie das und suchen Sie eine bessere Quelle. Es gibt kein Szenario, in dem 777 auf einem Produktiv-Shop die richtige Antwort ist.

SSL/TLS und Sicherheits-Header

Aktivieren Sie SSL unter Shop-Parameter → Allgemein, erzwingen Sie die Weiterleitung auf Webserver-Ebene und fügen Sie HSTS hinzu, damit der Browser ein Downgrade verweigert.

# Apache .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

# Nginx
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$server_name$request_uri;
}
server {
    listen 443 ssl http2;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

Content Security Policy

Eine CSP kann die Auswirkung eines injizierten Karten-Skimmers oder einer XSS-Payload abmildern, aber eine strikte Policy bricht bei PrestaShop den Checkout, sobald Sie sie zum ersten Mal ausprobieren. Zahlungs-Widgets, Analytics, Chat, Schriftarten und viele JavaScript-Dateien aus Modulen laden von Drittanbieter-Ursprüngen. Führen Sie sie in zwei Stufen ein:

# Apache: zuerst überwachen, nicht sofort erzwingen
Header always set Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; font-src 'self' data: https:; connect-src 'self' https:; frame-src 'self' https:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; report-uri /csp-report"

# Nginx: zuerst überwachen, nicht sofort erzwingen
add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data: https:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; font-src 'self' data: https:; connect-src 'self' https:; frame-src 'self' https:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; report-uri /csp-report" always;

Lassen Sie sie mindestens eine Woche echten Datenverkehrs im Report-Only-Modus laufen. Sammeln Sie die Verstöße, ersetzen Sie den Platzhalter https: durch Ihre tatsächlichen Anbieter-Domains (Stripe, PayPal, Adyen, Klarna, GA, GTM, Hotjar usw.) und schalten Sie erst dann auf Erzwingung um, wenn ein vollständiger Checkout-Test sauber durchläuft. Behalten Sie 'unsafe-inline' so lange, wie Ihr Theme es benötigt, es zu entfernen erfordert Nonce- oder Hash-Unterstützung über jedes Template hinweg.

Verzeichnisauflistung und sensible Dateien blockieren

Die .htaccess-Regeln, die wir in das Stammverzeichnis jedes Shops legen, den wir hosten:

Options -Indexes

# Sensible Dateitypen blockieren
<FilesMatch "\\.(env|yml|yaml|log|sql|bak|old|orig|save|swp|dist|config|ini|phps)$">
    Require all denied
</FilesMatch>

# Versteckte Dateien und Verzeichnisse blockieren (.git, .env usw.)
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule (^\\.|/\\.) - [F]
</IfModule>

# Composer-Dateien blockieren
<FilesMatch "^(composer\\.json|composer\\.lock)$">
    Require all denied
</FilesMatch>

# Konfigurations-, vendor- und Log-Verzeichnisse blockieren
<IfModule mod_rewrite.c>
    RewriteRule ^config/ - [F]
    RewriteRule ^vendor/ - [F]
    RewriteRule ^var/logs/ - [F]
    RewriteRule ^app/config/ - [F]
</IfModule>

# PHP-Ausführung in Upload-Verzeichnissen blockieren
<Directory "/var/www/html/prestashop/upload">
    <FilesMatch "\\.ph(p[3457]?|t|tml)$">
        Require all denied
    </FilesMatch>
</Directory>

<Directory "/var/www/html/prestashop/img">
    <FilesMatch "\\.ph(p[3457]?|t|tml)$">
        Require all denied
    </FilesMatch>
</Directory>

Nginx-Entsprechung:

location ~* \\.(env|yml|yaml|log|sql|bak|old|swp|dist|config|ini)$ { deny all; return 404; }
location ~ /\\. { deny all; return 404; }
location ~* ^/(upload|img|download)/.*\\.php$ { deny all; return 404; }
location ~* ^/(config|vendor|var/logs|app/config)/ { deny all; return 404; }
autoindex off;

Prüfen Sie es nach. Öffnen Sie nach dem Deployment https://yourshop.com/.env und https://yourshop.com/app/config/parameters.php in einem Inkognito-Fenster. 403 oder 404 ist korrekt. Alles andere bedeutet, dass Sie Zugangsdaten verteilen.

3. Härtung des Admin-Bereichs

Sicherheitseinstellungen im Back Office von PrestaShop 8.

Token-Schutz und Passwort-Richtlinie sind hier die beiden Einstellungen. Der Token-Schutz sollte aktiviert bleiben; der Passwort-Score sollte mindestens 3 betragen.

Sicherheitsseite im Back Office von PrestaShop 8 mit Schalter für Token-Schutz und Einstellungen zur Passwort-Richtlinie

Das Admin-Verzeichnis umbenennen: richtig

PrestaShop installiert standardmäßig einen zufälligen Admin-Ordner. Wenn Ihrer noch /admin/ oder ein erratbares Wort ist (/backoffice, /panel, der Shop-Name, die Initialen des Entwicklers), benennen Sie ihn noch heute in zehn oder mehr zufällige Zeichen um:

mv /var/www/html/prestashop/admin /var/www/html/prestashop/admin-x7k9m2p4
rm -rf /var/www/html/prestashop/var/cache/*

Es ist für sich genommen keine Sicherheit. Es ist der Unterschied, ob Sie auf der Zielliste jedes Scanners stehen oder nicht. Setzen Sie ein Lesezeichen auf die neue URL, speichern Sie sie in Ihrem Passwort-Manager und gehen Sie weiter.

Starke Passwörter und 2FA: nicht optional

Jedes Admin-Konto: 16+ Zeichen, von einem Passwort-Manager generiert, niemals wiederverwendet. PrestaShop 1.7.6 und neuer unterstützen TOTP (Google Authenticator, Authy, 1Password, Bitwarden) nativ unter Erweiterte Parameter → Verwaltung. Aktivieren Sie es für jeden Mitarbeiter, ohne Ausnahmen. Dieser eine Schalter wehrt die überwältigende Mehrheit der Brute-Force- und Credential-Stuffing-Angriffe ab, die wir sehen.

Security Revolution erzwingt 2FA, prüft die Härtung von Mitarbeiterkonten und zeigt Konten an, die aus der Richtlinie herausgefallen sind. Die Grundregel mit oder ohne das Modul ist dieselbe: 2FA aktiviert für jedes Konto, das /admin/ erreichen kann.

Den Admin-Bereich nach IP einschränken, wenn möglich

Wenn Ihr Team von einer festen Büro-IP oder einem VPN aus arbeitet, sperren Sie den Admin-Bereich auf diese Adressen:

# .htaccess im Admin-Verzeichnis
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REMOTE_ADDR} !^203\\.0\\.113\\.10$
    RewriteCond %{REMOTE_ADDR} !^198\\.51\\.100\\.20$
    RewriteRule .* - [F,L]
</IfModule>

Nur-VPN ist der Sweet Spot: Mitarbeiter können aus jedem Café in Europa arbeiten, der Admin-Bereich weist alle anderen weiterhin auf Webserver-Ebene ab, noch bevor der Login-Code von PrestaShop überhaupt läuft. Wenn der Missbrauch von wiederkehrenden Kunden- oder Besucher-IPs ausgeht und nicht von festen Admin-Angriffen, bietet Customer Extra Info & IP Ban dem Support-Personal einen sichereren Prüf- und Sperrweg als das händische Bearbeiten von Webserver-Regeln.

Mitarbeiterkonten ausmisten

Öffnen Sie jetzt Erweiterte Parameter → Team → Mitarbeiter. Jedes Konto ist eine Zugangsberechtigung, die per Phishing abgegriffen werden kann. Löschen Sie:

Jeden, der das Unternehmen vor mehr als 30 Tagen verlassen hat
Testkonten, die der ursprüngliche Entwickler angelegt und vergessen hat
Auftragnehmer, deren Projekt abgeschlossen ist

Und stufen Sie jeden herunter, der kein SuperAdmin sein muss. Lagerpersonal muss den Cookie-Schlüssel nicht zurücksetzen. Der Kundendienst muss keine Module installieren.

Fail2ban am Login-Endpunkt

# /etc/fail2ban/filter.d/prestashop-admin.conf
[Definition]
failregex = ^<HOST> -.*"POST .*/admin.*/index\\.php\\?controller=AdminLogin.*" (200|302)

# /etc/fail2ban/jail.d/prestashop.conf
[prestashop-admin]
enabled = true
filter = prestashop-admin
logpath = /var/log/apache2/access.log
maxretry = 5
findtime = 600
bantime = 3600

Fail2ban überwacht Server-Logs. Für kundenseitige Formulare, bei denen Bots den Admin-Endpunkt nie berühren, fügt reCAPTCHA & hCaptcha Protection die Challenge-Schicht hinzu, bevor Spam zu Konto-, Kontaktformular- oder Registrierungsmissbrauch wird.

4. Modul-Sicherheit

Module sind die mit Abstand größte Angriffsfläche jeder PrestaShop-Installation. Behandeln Sie jedes einzelne als nicht vertrauenswürdigen Code, der mit vollem Datenbankzugriff läuft, bis es das Gegenteil beweist.

Woher Sie Module beziehen, und woher nicht

Akzeptable Quellen: der offizielle PrestaShop-Addons-Marktplatz, etablierte Anbieter mit nachweisbarer Erfolgsbilanz und gut gepflegte Open-Source-Projekte auf GitHub, bei denen Sie den Code selbst lesen können. Alles andere ist ein Risiko.

Genullte Module bringen Ihnen einen Hack ein. Das ist nicht theoretisch. Wer das Modul geknackt hat, fügte vor dem erneuten Hochladen eine Hintertür ein. Genau das ist der Sinn der Sache. Wir haben Shops bereinigt, in denen ein einziges genulltes „Gratis-Download"-Modul sechs Monate lang heimlich jede Bestellung an einen Dritten ausschleuste. Keine Ausnahmen, kein „Ich verwende es nur auf Staging". Am Ende landet es in der Produktivumgebung.

Modul-Code vor der Installation prüfen

Öffnen Sie das ZIP. Suchen Sie im ZIP nach diesen Mustern:

# Gefährlich: beliebige Codeausführung
eval($variable)
eval(base64_decode($something))
assert($user_input)

# Gefährlich: Laden von Remote-Code
file_get_contents('http://external-domain.com/...')
include('http://...')

# Gefährlich: nicht bereinigtes SQL
"SELECT * FROM ps_table WHERE id = " . $_GET['id']
Db::getInstance()->execute("... " . $_POST['value'] . " ...")

So sieht sauberer Modul-Code aus:

// SICHER: Auf Integer casten, pSQL() verwenden
$id = (int)Tools::getValue('id');
$name = pSQL(Tools::getValue('name'));

Wenn Ihnen die Zeit oder der PHP-Hintergrund für eine Prüfung fehlt, kontrollieren Sie zumindest, ob der Entwickler eine Seite für Sicherheitshinweise hat, Changelogs ausliefert und auf Issues reagiert. Stille nach einem CVE ist ein Warnsignal.

Halten Sie sie aktuell

Mindestens wöchentlich auf Modul-Updates prüfen
Den Sicherheits-Newsletter Ihres Anbieters abonnieren
Friends of Presta für PrestaShop-Modul-CVEs folgen. Das ist das, was dem Ökosystem am nächsten an einen koordinierten Offenlegungs-Feed herankommt
Vor jedem Update sichern. Immer.

Deaktivieren ist nicht Entfernen

Die PHP-Dateien eines deaktivierten Moduls liegen weiterhin auf der Platte und seine Front-Controller sind weiterhin per direkter URL erreichbar. Wenn es eine SQL-Injection enthält, bewirkt das Deaktivieren gar nichts. Der einzig sichere Zustand ist „weg":

# Über das Back Office deinstallieren, dann die Dateien löschen
rm -rf /var/www/html/prestashop/modules/unused_module

Öffnen Sie jetzt Ihre Modul-Liste und tun Sie das. Jedes Modul, das Sie 2022 getestet und nie verwendet haben, ist unnötiges Risiko.

Berechtigungen für das Modul-Verzeichnis

find /var/www/html/prestashop/modules -type d -exec chmod 755 {} \\;
find /var/www/html/prestashop/modules -type f -exec chmod 644 {} \\;

5. Datenbank-Sicherheit

PrestaShop nicht als root betreiben

Der Datenbankbenutzer in parameters.php sollte genau die Berechtigungen haben, die PrestaShop benötigt, und nichts darüber hinaus:

CREATE USER 'prestashop_user'@'localhost' IDENTIFIED BY 'long-random-password';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER,
      CREATE TEMPORARY TABLES, LOCK TABLES
      ON prestashop_db.* TO 'prestashop_user'@'localhost';
FLUSH PRIVILEGES;

Wenn eine SQL-Injection einschlägt (und auf einem Shop mit 50 Modulen wird sie das irgendwann), ist ein eingeschränkter Benutzer der Unterschied zwischen „eine Datenbank ausgelesen" und „jede Datenbank auf dem Server ausgelesen, /etc/passwd über LOAD_FILE gelesen und eine Webshell über INTO OUTFILE geschrieben".

Backups, die tatsächlich funktionieren

# Crontab-Einträge
# Datenbank-Backup: täglich um 3 Uhr
0 3 * * * mysqldump -u backup_user -p'password' prestashop_db | gzip > /backups/db/ps_$(date +\\%Y\\%m\\%d).sql.gz

# Datei-Backup: täglich um 3:30 Uhr
30 3 * * * tar -czf /backups/files/ps_files_$(date +\\%Y\\%m\\%d).tar.gz /var/www/html/prestashop/

# Backups älter als 30 Tage aufräumen
0 4 * * * find /backups/ -name "*.gz" -mtime +30 -delete

Die Regeln, die wir uns auf die harte Tour verdient haben:

Außerhalb des Servers. Backups auf derselben Maschine werden vom selben Angreifer gelöscht, der die Originale gelöscht hat. S3, ein zweiter VPS, irgendwo mit separaten Zugangsdaten.
Die Wiederherstellung monatlich testen. Ungetestete Backups sind Geschichten, keine Versicherung. Stellen Sie sie in einem Staging-Container wieder her und laden Sie die Startseite.
Vor dem Verlassen des Servers verschlüsseln. SQL-Dumps enthalten Kunden-PII und Passwort-Hashes. gpg oder age, die Schlüssel liegen irgendwo, wo nur Sie und eine weitere Person herankommen.
Mindestens 30 Tage Aufbewahrung. Manche Kompromittierungen tauchen erst Wochen später auf. Eine 7-Tage-Rotation wird Sie nicht retten.

phpMyAdmin: entfernen oder einkapseln

Unsere Standardhaltung ist: in Produktion gar nicht erst installieren. Ein SSH-Tunnel leistet dasselbe, ohne eine breite webbasierte Angriffsfläche zu exponieren:

# Von Ihrer LOKALEN Maschine
ssh -L 3307:localhost:3306 user@yourserver.com
# Dann verbinden Sie Ihren lokalen MySQL-Client mit localhost:3307

Wenn Sie phpMyAdmin behalten müssen: zufälliger URL-Pfad, IP-Einschränkung, HTTP-Basic-Auth davor und root-Login deaktiviert:

$cfg['Servers'][$i]['AllowRoot'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;

6. Überwachung und Erkennung

Datei-Integritätsüberwachung

Ein Angreifer, der drinnen ist, wird Dateien verändern, Webshell in img/, Skimmer in einem Template, ein zusätzlicher Admin in ps_employee. Eine tägliche Hash-Prüfung fängt die Datei-Hälfte davon ab:

#!/bin/bash
# /usr/local/bin/prestashop-integrity-check.sh
SHOP_DIR="/var/www/html/prestashop"
BASELINE="/var/backups/prestashop-file-hashes.txt"
CURRENT="/tmp/prestashop-file-hashes-current.txt"
ALERT_EMAIL="admin@yourdomain.com"

find "$SHOP_DIR" -type f \\
    -not -path "*/var/cache/*" \\
    -not -path "*/var/logs/*" \\
    -not -path "*/img/p/*" \\
    -not -path "*/img/c/*" \\
    -exec md5sum {} \\; | sort > "$CURRENT"

if [ -f "$BASELINE" ]; then
    DIFF=$(diff "$BASELINE" "$CURRENT")
    if [ -n "$DIFF" ]; then
        echo "$DIFF" | mail -s "ALERT: PrestaShop files modified" "$ALERT_EMAIL"
    fi
fi

Erzeugen Sie die Baseline direkt nach einem sauberen Deployment, planen Sie das Skript täglich ein und justieren Sie die Ausschlüsse, bis Sie nur noch bei echten Änderungen Warnmeldungen erhalten. Rechnen Sie in der ersten Woche mit Rauschen.

Security Revolution bündelt dies und einige weitere Prüfungen, falls Sie ein Cron-Skript und eine Baseline-Datei nicht selbst pflegen möchten.

Log-Überwachung

# SQL-Injection-Versuche
grep -iE "(union\\s+select|or\\s+1=1|information_schema)" /var/log/apache2/access.log

# File-Inclusion-Versuche
grep -iE "(etc/passwd|\\.\\.\\/\\.\\.\\/)" /var/log/apache2/access.log

# Direkter Zugriff auf Modul-Dateien (mögliche Exploit-Versuche)
grep -E "modules/.*/ajax|modules/.*/api" /var/log/apache2/access.log

Ein nächtlicher Cron, der die Treffer per E-Mail versendet, ist die günstige Variante. Logs an Graylog, Loki oder Papertrail zu schicken und auf Muster zu alarmieren, ist die richtige Variante.

Verfügbarkeitsüberwachung: Inhaltsprüfung, nicht nur HTTP 200

UptimeRobot, HetrixTools oder das selbstgehostete Uptime Kuma, alle in Ordnung
Überwachen Sie Startseite und Checkout, ein teilweiser Einbruch legt oft nur den Checkout-Ablauf lahm
Prüfen Sie auf bestimmten Seitentext („In den Warenkorb", Ihr Shop-Name), nicht nur auf eine 200-Antwort. Ein manipulierter Shop liefert weiterhin HTTP 200.
Intervalle von 1–5 Minuten, Benachrichtigungen per SMS oder Slack, E-Mail allein geht unter

Warnmeldungen bei Admin-Logins

Mitarbeiter-Sitzungen in PrestaShop 8.

Diese Seite zeigt jede aktive Admin-Sitzung mit Mitarbeitername, E-Mail und Zeitstempel der letzten Aktivität. Wenn Sie einen unbefugten Login vermuten, ist dies die erste Stelle, die Sie prüfen sollten.

Ein kleines, eigenes Modul, das in das Post-Login-Ereignis eingehängt ist, sendet bei jedem Login eine E-Mail an die Sicherheit. Günstig auszuliefern und verrät Ihnen sofort, ob eine Zugangsberechtigung durchgesickert ist:

public function hookActionAdminLoginControllerLoginAfter($params)
{
    $employee = $params['employee'];
    $ip = Tools::getRemoteAddr();

    Mail::Send(
        (int)Configuration::get('PS_LANG_DEFAULT'),
        'alert_admin_login',
        "Admin Login: {$employee->email} from {$ip}",
        ['{body}' => "Employee: {$employee->email}
IP: {$ip}
Time: " . date('Y-m-d H:i:s')],
        'security@yourdomain.com',
        'Security Alert'
    );
}

7. Sie wurden gehackt. Was jetzt.

Die ersten 30 Minuten

Löschen Sie noch nichts. Der kompromittierte Zustand ist forensisches Beweismaterial. Sie brauchen ihn, um den Einstiegspunkt zu finden.
Nehmen Sie den Shop vom Netz mit einer Wartungsseite oder einer vorübergehenden Passwortsperre: stoppen Sie den laufenden Schaden sofort.
Rotieren Sie jede Zugangsberechtigung. SSH, FTP, Datenbank, jedes Admin-Konto, das Hosting-Panel, die API-Schlüssel des Zahlungs-Gateways, alles, was in der kompromittierten parameters.php gespeichert war.
Erstellen Sie einen Snapshot des kompromittierten Zustands (vollständiger tar + mysqldump) und beschriften Sie ihn. Sie werden ihn für die Analyse brauchen, wenn sich der Staub gelegt hat.
Rufen Sie Ihren Zahlungsdienstleister an, wenn Sie Kartendaten direkt verarbeiten. Er hört lieber zuerst von Ihnen.

# Schneller Wartungsmodus
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR\\.IP\\.ADDRESS$
RewriteCond %{REQUEST_URI} !^/maintenance\\.html$
RewriteRule .* /maintenance.html [R=503,L]

Die Hintertür finden: sie hinterlassen immer eine

Den sichtbaren Schaden zu beseitigen, ohne den Persistenzmechanismus zu finden, bringt Ihnen innerhalb einer Woche eine erneute Kompromittierung ein. Die Stellen, an denen Sie suchen sollten:

# Nach Hintertür-Mustern suchen
grep -rn "eval(" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\\|cache"
grep -rn "base64_decode" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\\|cache"
grep -rn "shell_exec\\|passthru\\|system(" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\\|cache"

# Kürzlich geänderte PHP-Dateien finden
find /var/www/html/prestashop/ -name "*.php" -mtime -7 -not -path "*/cache/*"

# PHP-Dateien in Verzeichnissen finden, in denen sie nicht existieren sollten
find /var/www/html/prestashop/img/ -name "*.php"
find /var/www/html/prestashop/upload/ -name "*.php"

# Auf obfuskierten Code prüfen (sehr lange einzelne Zeilen)
find /var/www/html/prestashop/ -name "*.php" -exec awk 'NR==1 && length>5000' {} +

Halten Sie nicht beim Dateisystem inne, Angreifer persistieren auch über die Datenbank:

SELECT id_cms, meta_title FROM ps_cms_lang WHERE content LIKE '%<?php%' OR content LIKE '%eval(%';
SELECT * FROM ps_employee ORDER BY date_add DESC LIMIT 10;

Diese zweite Abfrage fängt einen klassischen Zug ab: Der Angreifer legt sein eigenes Admin-Konto an, damit er den Zugang behält, nachdem Sie jedes Passwort geändert haben.

Wiederherstellung

Finden Sie den Einstiegspunkt in den Zugriffsprotokollen. Suchen Sie nach ungewöhnlichen POSTs an modules/*/ajax.php oder modules/*/api.php um den Zeitpunkt herum, an dem die Integritätsprüfung erstmals eine Änderung meldete.
Stellen Sie aus einem als sauber bekannten Backup wieder her, falls eines existiert und der Kompromittierung vorausgeht.
Wenn es kein sauberes Backup gibt: ersetzen Sie alle Kerndateien durch einen frischen Download Ihrer exakten PS-Version, installieren Sie jedes Modul aus seiner ursprünglichen Quelle neu und behalten Sie nur Ihr Theme und das img/-Verzeichnis, nachdem Sie sie gründlich gescannt haben.
Scannen Sie die Datenbank nach injiziertem Inhalt in ps_configuration, ps_cms_lang und ps_meta_lang. Skimmer lieben diese.
Patchen Sie alles: Kern, Module, PHP, MySQL, Betriebssystem. Bringen Sie den Shop nicht auf derselben Software wieder online, die sie hereingelassen hat.

Nach der Bereinigung

Beheben Sie die konkrete Schwachstelle, die ausgenutzt wurde. Das schlechte Modul zu deaktivieren, ist keine Behebung, entfernen oder patchen Sie es.
Überwachen Sie die ersten 30 Tage intensiver. Sie werden versuchen, zurückzukommen.
Eine WAF vor dem Shop (die kostenlose Stufe von Cloudflare ist ein vernünftiger Startpunkt) fängt beim nächsten Durchlauf viele derselben Scanner ab.
Wenn Kunden- oder Zahlungsdaten möglicherweise offengelegt wurden, sprechen Sie mit einem Anwalt über die DSGVO-Meldung von Datenpannen. Es läuft eine 72-Stunden-Frist.

Harte Wahrheit: Wenn Sie nicht feststellen können, wie sie hereingekommen sind, gehen Sie davon aus, dass sie wieder hereinkommen werden. Ein einmaliges professionelles Audit kostet weit weniger als ein zweiter Einbruch plus die regulatorischen Folgen.

8. Die Checkliste

Drucken Sie diese aus und arbeiten Sie sie durch. Jedes nicht abgehakte Kästchen ist ein Weg hinein.

Server und PHP

PHP-Version aktuell und unterstützt
Gefährliche PHP-Funktionen deaktiviert
expose_php = Off
display_errors = Off in Produktion
allow_url_include = Off
Session-Cookies: HttpOnly, Secure, SameSite
open_basedir gesetzt
Betriebssystem, MySQL, Webserver aktuell
SSH-Schlüssel-Authentifizierung an, Passwort-Authentifizierung aus
Firewall. Nur die Ports, die Sie brauchen

Dateisystem

Verzeichnisse 755, Dateien 644
parameters.php auf 400
Nichts auf 777 gesetzt
PHP-Ausführung blockiert in upload/, img/, download/
Verzeichnisauflistung aus
.env, .git, YAML, Konfigurationsdateien alle vom Web blockiert
vendor/ und var/logs/ vom Web blockiert

SSL und HTTPS

Gültiges Zertifikat mit automatischer Erneuerung
HTTP→HTTPS-Weiterleitung am Webserver
HSTS-Header gesetzt
SSL für alle Seiten in PrestaShop aktiviert
Keine Mixed-Content-Warnungen

Admin-Bereich

Admin-Verzeichnis ist eine zufällige Zeichenkette
Alle Passwörter 16+ Zeichen aus einem Passwort-Manager
2FA aktiviert für jedes Konto, ohne Ausnahmen
Admin nach IP eingeschränkt, wo machbar
Ungenutzte Konten gelöscht, ehemalige Mitarbeiter entfernt
Jeder Mitarbeiter auf Least-Privilege-Profil
fail2ban oder Äquivalent am Login-Endpunkt

Module

Jedes Modul aus einer vertrauenswürdigen Quelle
Null genullte Module
Alle Module aktuell
Ungenutzte Module gelöscht, nicht nur deaktiviert
Modul-Code stichprobenartig auf eval() und nicht bereinigtes SQL geprüft
Die Sicherheitshinweise Ihrer Anbieter abonniert

Datenbank

Dedizierter Datenbankbenutzer, nicht root
Nur die minimal erforderlichen Berechtigungen
Datenbankpasswort mit 20+ Zeichen
MySQL an localhost gebunden
phpMyAdmin entfernt oder nach IP eingeschränkt
Tabellenpräfix vom Standard ps_ geändert

Backups

Täglicher Datenbank-Dump automatisiert
Tägliches Datei-Backup automatisiert
Backups außerhalb des Servers gespeichert
Backups vor der Übertragung verschlüsselt
30+ Tage Aufbewahrung
Wiederherstellung in den letzten 30 Tagen getestet

Überwachung

Datei-Integritätsprüfungen laufen
Zugriffsprotokolle auf Angriffsmuster gescannt
Verfügbarkeitsüberwachung mit Inhalts-String-Prüfung
Warnmeldungen bei Admin-Logins aktiv
Sicherheits-Header bei jeder Antwort ausgeliefert

Vorfallbereitschaft

Notfallplan schriftlich festgehalten
Kontakte zu Hosting und Zahlungsdienstleister griffbereit
DSGVO-Meldeprozess dokumentiert
Wartungsseite bereit zum Deployment
Jede kritische Zugangsberechtigung in einem Passwort-Manager

Sicherheit ist eine Wartungsaufgabe, kein Projekt. Setzen Sie eine vierteljährliche Erinnerung in Ihren Kalender, um diese Liste erneut durchzugehen. Das erste Mal wird einen Tag dauern. Danach ist es eine Stunde. Fangen Sie ganz oben an: alles aktualisieren, 2FA für jedes Konto aktivieren, die Module löschen, die Sie nicht nutzen, Backups außerhalb des Servers zum Laufen bringen. Der Rest folgt.

Weiterführende Lektüre

PrestaShop Backup & Notfallwiederherstellung: bauen Sie den Wiederherstellungsweg, bevor Sie ihn brauchen
DSGVO-Konformität für PrestaShop-Shops: bringen Sie die Sicherheitsarbeit mit den Datenschutzpflichten in Einklang
PrestaShop Hosting-Leitfaden: Server-Anforderungen, PHP-Limits und Härtung auf Hosting-Ebene
PrestaShop Fehlerbehebung: 500er, weiße Seiten und Wiederherstellung nach einem Vorfall diagnostizieren
PrestaShop Hooks-Leitfaden: Kontext für die Prüfung riskanter Modul-Anpassungen
Security Revolution: 2FA-Erzwingung, Datei-Integritätsprüfungen und Admin-Härtung in einem Modul
Total Defender: Schutz vor Admin-Brute-Force und Login-Überwachung