Website-Sicherheit: Die Praktiken, die die meisten Vorfälle verhindern
Die meisten Website-Kompromittierungen sind nicht gezielt. Es sind automatische Scanner, die eine bekannte Schwachstelle in veralteter Software finden, oder ein wiederverwendetes Passwort auf einem Admin-Konto. Sich gegen die gewöhnlichen Angriffe zu verteidigen deckt den weit größten Teil des echten Risikos ab.
Dieser Leitfaden behandelt die Praktiken, die die meisten Vorfälle verhindern, grob nach Wirkung geordnet, und was zu tun ist, wenn eine Website bereits kompromittiert wurde.
Die Maßnahmen, die die meisten Vorfälle verhindern#
Geordnet danach, wie viel Risiko sie je Aufwandseinheit beseitigen.
- Halten Sie Software aktuell. Die überwältigende Mehrheit der Kompromittierungen nutzt eine Schwachstelle aus, für die ein Patch verfügbar ist. Dieser eine Punkt wiegt schwerer als alles darunter.
- Einzigartige starke Passwörter plus Zwei-Faktor-Authentifizierung auf jedem Admin-Konto, Hosting-Panel, Domain-Registrar und E-Mail-Konto.
- Geringste Rechte. Redakteurinnen brauchen keine Administratorkonten. Entfernen Sie Konten, wenn Menschen gehen.
- HTTPS überall, mit HSTS, sobald Sie sicher sind, dass jede Unterressource über TLS verfügbar ist.
- Getestete Backups, außerhalb des Servers gespeichert. Ein Backup auf der kompromittierten Maschine wird mit allem anderen verschlüsselt.
- Schränken Sie den Adminbereich nach IP ein, wo es praktikabel ist, und begrenzen Sie Anmeldeversuche immer.
- Entfernen Sie, was Sie nicht nutzen. Jedes inaktive Plugin, Theme und jede alte Installation ist Angriffsfläche ohne Nutzen.
Alte, vergessene Installationen — eine Staging-Kopie unter /alt, ein Testblog in einem Unterordner — sind ein häufiger Einstiegspunkt, gerade weil sie niemand aktualisiert.
Eingabe, Ausgabe und die klassischen Schwachstellen#
Das sind Verantwortlichkeiten der Entwicklung und sie machen den Großteil der Schwachstellen aus, die nicht „Sie haben nicht aktualisiert" lauten.
| Schwachstelle | Was sie bewirkt | Vorbeugung |
|---|---|---|
| SQL-Injection | Liest oder zerstört Ihre Datenbank | Immer parametrisierte Abfragen — nie String-Verkettung |
| Cross-Site-Scripting | Führt fremdes Skript in der Sitzung eines Besuchers aus | Kontextabhängig bei der Ausgabe escapen; eine strikte Content-Security-Policy |
| Cross-Site Request Forgery | Führt Aktionen als angemeldeter Nutzer aus | Sitzungsbezogene Tokens bei jeder zustandsändernden Anfrage |
| Missbrauch von Datei-Uploads | Lädt Code hoch und führt ihn aus | Typ am Inhalt prüfen, außerhalb des Web-Roots speichern, nie ausführen |
| Fehlerhafte Zugriffskontrolle | Nutzer erreichen Daten, die nicht ihre sind | Autorisierung serverseitig bei jeder Anfrage prüfen, nicht in der Oberfläche |
| Offenlegung sensibler Daten | Leakt Schlüssel und Zugangsdaten | Umgebungsvariablen, nie im Repository |
| Server-Side Request Forgery | Bringt Ihren Server dazu, interne Systeme aufzurufen | Ausgehende Ziele auf eine Erlaubnisliste setzen |
Konfiguration und Header#
Billige Maßnahmen, die ganze Problemkategorien schließen und meist Minuten brauchen.
- Liefern Sie Sicherheits-Header: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, X-Frame-Options.
- Deaktivieren Sie Verzeichnislisten; stellen Sie sicher, dass /.git, /.env und Backup-Dateien über HTTP nicht erreichbar sind.
- Schalten Sie ausführliche Fehlerausgaben in der Produktion ab — Stacktraces sind Aufklärung für Angreifer.
- Sperren Sie den Zugriff auf Admin- und Konfigurationspfade aus dem öffentlichen Internet, wo Sie können.
- Setzen Sie Cookies mit HttpOnly, Secure und einem passenden SameSite-Wert.
- Halten Sie Abhängigkeiten auditiert; eine verwundbare Bibliothek in Ihrem Build ist Ihre Verwundbarkeit.
- Protokollieren Sie Authentifizierungsereignisse und alarmieren Sie bei ungewöhnlichen Mustern.
Wenn die Website bereits kompromittiert ist#
Hier zählt die Reihenfolge. Dateien zu säubern, bevor Zugangsdaten gewechselt sind, bedeutet, dass der Angreifer schlicht durch dieselbe Tür zurückkommt.
- Nehmen Sie die Website offline oder in den Wartungsmodus. Lassen Sie sie Besuchern keine Schadsoftware ausliefern.
- Sichern Sie Beweise: Kopieren Sie die Protokolle und einen Stand der Dateien, bevor Sie etwas ändern.
- Wechseln Sie jede Zugangsberechtigung — Hosting, Datenbank, Admin-Nutzer, API-Schlüssel, E-Mail. Nehmen Sie an, alle sind bekannt.
- Stellen Sie aus einem Backup von vor der Kompromittierung wieder her, wenn Sie eines verlässlich bestimmen können.
- Wenn nicht, bauen Sie aus dem Quellcode neu auf und importieren Sie nur Daten, nie Dateien unbekannter Herkunft.
- Beheben Sie die Schwachstelle, durch die sie hereinkamen. Ohne diesen Schritt wiederholen Sie den ganzen Vorgang.
- Suchen Sie nach Persistenz: geplante Aufgaben, zusätzliche Admin-Nutzer, veränderte Kerndateien, eingeschleuste Inhalte.
- Beantragen Sie eine Überprüfung in der Search Console, falls die Website markiert wurde, und suchen Sie nach eingeschleusten Spam-Seiten.
- Benachrichtigen Sie betroffene Nutzer, wenn personenbezogene Daten offengelegt wurden — in vielen Rechtsordnungen innerhalb einer gesetzlichen Frist.
Ein Backup wiederherzustellen, ohne den Einstiegspunkt zu schließen, ist der häufigste Grund, warum Websites binnen zweier Wochen zweimal kompromittiert werden.
Häufige Fragen
Reicht ein Sicherheits-Plugin?
Es hilft bei einigen Dingen — Begrenzung von Anmeldeversuchen, Überwachung von Dateiänderungen, eine einfache Firewall — und es ersetzt weder Updates noch starke Zugangsdaten noch geringste Rechte. Eine Website mit Sicherheits-Plugin und achtzehn Monaten versäumter Updates ist nicht sicher. Bringen Sie zuerst die Grundlagen in Ordnung, dann ergänzen Sie Werkzeuge.
Werden kleine Websites wirklich angegriffen?
Ständig, und nicht wegen dem, wer Sie sind. Automatische Scanner testen jeden erreichbaren Host auf bekannte Schwachstellen; kleine Websites sind gerade deshalb attraktiv, weil sie seltener gepatcht sind. Kompromittierte kleine Websites werden für Spam, Phishing-Seiten und Weiterleitungen genutzt, weshalb das Traffic-Niveau Ihrer Website für das Risiko unerheblich ist.
Wo sollten Backups liegen?
Irgendwo, wohin der Webserver nicht schreiben kann, idealerweise bei einem anderen Anbieter, mit mindestens einer Kopie, die sich nicht mit denselben Zugangsdaten löschen lässt, die die Website betreiben. Ransomware und zerstörerische Angriffe zielen gezielt auf Backups, die von der kompromittierten Maschine erreichbar sind — und das ist genau der Moment, in dem Sie sie brauchen.
Was ist die wertvollste einzelne Sicherheitsmaßnahme?
Updates zügig einzuspielen. Es ist unglamourös und verhindert mehr echte Kompromittierungen als alles andere zusammen, denn die Angriffe, die tatsächlich stattfinden, sind automatisiertes Ausnutzen bekannter, gepatchter Schwachstellen. An zweiter Stelle steht Zwei-Faktor-Authentifizierung auf Admin- und Hosting-Konten.
website sicherheitwebsite gehacktsicherheit best practicessql injectionxsswebsite backups
