Wenn sich die meisten Menschen vorstellen, wie eine Website gehackt wird, sehen sie jemanden im Kapuzenpullover, der wie wild auf ein Terminal eintippt. Die Realit\u00e4t ist weit weniger dramatisch und weit h\u00e4ufiger. WordPress-Websites werden t\u00e4glich von automatisierten Scannern kompromittiert, die das \u00f6ffentliche Web durchsuchen, Tausende Websites gleichzeitig abtasten und durch T\u00fcren hereinspazieren, die offen gelassen wurden. Der Angreifer ist meist ein Skript, keine Person, und das Ziel sind selten Sie pers\u00f6nlich. Es ist, wer auch immer gerade die Software ausf\u00fchrt, die sie auszunutzen wissen.<\/p>\n
Die wahren Einfallstore zu verstehen ist wichtig, denn dieselbe Handvoll Fehler verursacht die \u00fcberw\u00e4ltigende Mehrheit der WordPress-Sicherheitsvorf\u00e4lle. Beheben Sie sie, und Sie werden zu einem viel schwierigeren Ziel. Ignorieren Sie sie, und Sie verlassen sich auf Gl\u00fcck.<\/p>\n
Plugins sind die h\u00e4ufigste Ursache f\u00fcr WordPress-Kompromittierungen. Das Plugin-\u00d6kosystem ist riesig, und die Codequalit\u00e4t ist uneinheitlich. Ein Plugin, das vor zwei Jahren v\u00f6llig sicher war, kann n\u00e4chste Woche eine ver\u00f6ffentlichte kritische Schwachstelle haben, und wenn Sie es nicht aktualisiert haben, sind Sie in dem Moment exponiert, in dem dieser Hinweis \u00f6ffentlich wird.<\/p>\n
Das Muster verl\u00e4uft meist so. Ein Forscher oder ein Angreifer entdeckt eine L\u00fccke in einem beliebten Plugin, oft etwas wie einen Datei-Upload ohne Authentifizierung oder eine SQL-Injection. Die L\u00fccke wird offengelegt. Innerhalb von Stunden durchk\u00e4mmen automatisierte Scanner das Internet auf der Suche nach Websites, die die verwundbare Version ausf\u00fchren. Nicht gepatchte Websites werden in gro\u00dfer Zahl kompromittiert.<\/p>\n
Ein k\u00fcrzlich von uns durchgef\u00fchrtes Audit der Website einer Agentur in Sydney f\u00f6rderte ein Dateimanager-Plugin zutage, das \u00fcber ein Jahr lang installiert und aktiv geblieben war, obwohl diese Plugin-Familie eine lange Geschichte von Schwachstellen zur Remote-Code-Ausf\u00fchrung hatte. Der Angreifer musste nichts Raffiniertes tun. Das Plugin \u00fcbergab ihm Schreibzugriff auf die gesamte Website.<\/p>\n
Brute-Force-Angriffe gegen die WordPress-Anmeldeseite sind konstant. Bots probieren pro Stunde Tausende g\u00e4ngige Benutzername-Passwort-Kombinationen aus, gespeist aus Leak-Datenbanken mit Hunderten Millionen geleakter Zugangsdaten. Wenn Ihr Administrator einen Benutzernamen wie admin, Ihren Firmennamen oder Ihren Vornamen verwendet und ein Passwort, das irgendwo im Internet in einem fr\u00fcheren Leak aufgetaucht ist, stehen Sie bereits auf der Liste.<\/p>\n
Die L\u00f6sung ist nicht kompliziert. Verwenden Sie einzigartige, lange Passw\u00f6rter. Verwenden Sie einen Passwortmanager. Verwenden Sie Zwei-Faktor-Authentifizierung f\u00fcr jedes Administratorkonto. Begrenzen Sie Anmeldeversuche. Benennen Sie Ihren Standard-Admin-Benutzer in etwas Nicht-Erratbares um. Diese Schritte sind langweilig und stoppen die meisten automatisierten Angriffe schlagartig.<\/p>\n
Der WordPress-Core selbst ist im Allgemeinen gut gepflegt, mit schnell ausgelieferten Sicherheitsversionen. Das Risiko besteht nicht darin, dass der Core voller L\u00f6cher ist. Das Risiko besteht darin, dass manche Website-Betreiber automatische Updates deaktivieren und dann vergessen, die manuellen einzuspielen. Eine WordPress-Version auszuf\u00fchren, die ein oder zwei Jahre alt ist, bedeutet, mit \u00f6ffentlich dokumentierten Schwachstellen zu laufen, die jeder Scanner erkennen kann.<\/p>\n
WordPress sagt Ihnen, wenn ein Update verf\u00fcgbar ist. Spielen Sie es ein. Wenn Sie sich um die Plugin-Kompatibilit\u00e4t sorgen, spielen Sie es zuerst auf einer Staging-Kopie ein. Lassen Sie es nicht liegen.<\/p>\n
Themes sind ebenfalls Code und bergen dieselben Risiken wie Plugins. Das gr\u00f6\u00dfere Problem sind raubkopierte Themes, die von zwielichtigen Seiten heruntergeladen werden. Eine kostenlose Kopie eines Premium-Themes von einer Torrent-Seite ist fast immer mit Hintert\u00fcren, versteckten Links oder Schlimmerem durchsetzt. Die Ersparnis bei einem Hundert-Dollar-Theme kann Tausende an Bereinigung kosten.<\/p>\n
Bleiben Sie bei Themes aus dem offiziellen WordPress-Verzeichnis oder von seri\u00f6sen Anbietern mit aktivem Support und regelm\u00e4\u00dfigen Updates. Bezahlen Sie f\u00fcr das, was Sie nutzen. Das ist viel g\u00fcnstiger als die Alternative.<\/p>\n
Eine \u00fcberraschende Zahl von WordPress-Websites l\u00e4sst sensible Dateien durchsickern, die niemals im \u00f6ffentlichen Web h\u00e4tten liegen d\u00fcrfen. Backup-Archive im Dokumentenstammverzeichnis, .sql-Dumps, .env-Dateien und alte Kopien der wp-config.php mit Namen wie wp-config.bak. Sobald ein Angreifer eine davon herunterl\u00e4dt, hat er Datenbank-Zugangsdaten, geheime Schl\u00fcssel oder beides.<\/p>\n
Pr\u00fcfen Sie Ihr Dokumentenstammverzeichnis. Alles, was nicht Teil von WordPress ist, geh\u00f6rt nicht dorthin. Verschieben Sie Backups vom Server weg. L\u00f6schen Sie alte Entwicklerdateien. Sperren Sie den direkten Zugriff auf g\u00e4ngige sensible Dateinamen auf Serverebene.<\/p>\n
Auf g\u00fcnstigem Shared Hosting k\u00f6nnen mehrere WordPress-Websites auf demselben Konto oder sogar derselben Festplatte liegen. Wird eine davon kompromittiert, hat der Angreifer oft die M\u00f6glichkeit, auf die anderen \u00fcberzuspringen und dieselbe Schadsoftware auf jeder Website im Topf abzulegen. Das ist ein h\u00e4ufiges Muster bei Agenturen, die zwanzig oder drei\u00dfig Kundenwebsites auf einem einzigen Shared-Plan betreiben.<\/p>\n
Isolieren Sie Websites. Nutzen Sie ein ordentliches Managed-WordPress-Hosting, bei dem jede Website in ihrem eigenen Container sitzt. Pr\u00fcfen Sie jede andere Website, die sich Ihre Umgebung teilt, mit derselben Sorgfalt wie Ihre eigene.<\/p>\n
WordPress stellt zwei wichtige programmatische Schnittstellen bereit, xmlrpc.php und die REST-API. Beide sind legitim, beide k\u00f6nnen n\u00fctzlich sein, und beide wurden als Angriffsvektoren genutzt. Insbesondere XML-RPC wurde historisch f\u00fcr verst\u00e4rkte Brute-Force-Angriffe missbraucht, bei denen eine einzige Anfrage viele Passwortversuche gleichzeitig unternehmen kann.<\/p>\n
Wenn Sie XML-RPC nicht nutzen, deaktivieren Sie es. Wenn Sie keinen unauthentifizierten REST-API-Zugriff auf bestimmte Endpunkte ben\u00f6tigen, beschr\u00e4nken Sie ihn. Die meisten modernen Hoster und Sicherheits-Plugins machen das unkompliziert.<\/p>\n
Ein Angreifer braucht nicht immer Ihr Passwort. Kann er ein Sitzungscookie abfangen, etwa durch einen Man-in-the-Middle auf einer unsicheren Verbindung, kann er sich f\u00fcr die gesamte G\u00fcltigkeitsdauer dieser Sitzung als Sie ausgeben. Sich \u00fcber \u00f6ffentliches WLAN ohne VPN anzumelden oder eine Website ohne durchg\u00e4ngig korrektes HTTPS zu betreiben, macht das viel leichter.<\/p>\n
Verwenden Sie immer HTTPS. Erzwingen Sie es websiteweit. Setzen Sie sichere Cookie-Flags. Melden Sie sich ab, wenn Sie fertig sind. Rotieren Sie die WordPress-Salts und -Schl\u00fcssel regelm\u00e4\u00dfig, damit bestehende Sitzungen ung\u00fcltig werden.<\/p>\n
Manche Kompromittierungen ben\u00f6tigen \u00fcberhaupt keine Softwarel\u00fccke. Eine Phishing-E-Mail, die einen Mitarbeiter auffordert, sich auf einer gef\u00e4lschten Admin-Seite anzumelden, eine gef\u00e4lschte Rechnungs-E-Mail, die einen Entwickler dazu bringt, einen feindlichen Shell-Befehl auszuf\u00fchren, ein Auftragnehmer, der \u00fcberall dasselbe Passwort wiederverwendet und es dann anderswo geleakt bekommt. Menschen sind Teil der Angriffsfl\u00e4che.<\/p>\n
Schulen Sie Ihre Mitarbeitenden. Nutzen Sie teamweit einen Passwortmanager. Erzwingen Sie Zwei-Faktor-Authentifizierung. Begrenzen Sie die Zahl der Konten mit Administratorrechten. Entfernen Sie Konten, sobald jemand das Projekt verl\u00e4sst.<\/p>\n
Viele WordPress-Websites werden f\u00fcr eine Kampagne, ein Event oder ein Nebenprojekt gestartet und dann vergessen. Sie laufen weiter auf demselben Hosting, mit denselben Zugangsdaten, und veralten langsam. Ein Jahr sp\u00e4ter sind sie ein perfektes Ziel. Der Betreiber pr\u00fcft sie nicht mehr, Google und die Bots schon.<\/p>\n
Wenn Sie eine WordPress-Website nicht mehr brauchen, nehmen Sie sie ordentlich vom Netz. Exportieren Sie die Inhalte, legen Sie die Installation still, geben Sie die Domain frei, archivieren Sie die Datenbank. Lassen Sie keine aufgegebenen Installationen im \u00f6ffentlichen Internet zur\u00fcck.<\/p>\n
Die Verteidigungsma\u00dfnahmen sind nicht exotisch. Halten Sie alles aktuell. Verwenden Sie starke, einzigartige Passw\u00f6rter plus Zwei-Faktor-Authentifizierung. Betreiben Sie ein ernstzunehmendes Sicherheits-Plugin wie Wordfence und beachten Sie, was es Ihnen sagt. Stellen Sie sicher, dass Ihr Hoster seri\u00f6s ist, Websites ordentlich isoliert und externe Backups anbietet. Pr\u00fcfen Sie Ihre Plugins, Themes und Administratorkonten mindestens viertelj\u00e4hrlich. Rotieren Sie Schl\u00fcssel und Salts, wenn Mitarbeitende oder Auftragnehmer wechseln. Stellen Sie gelegentlich aus einem Backup wieder her, einfach um zu wissen, dass es funktioniert.<\/p>\n
Nichts davon ist glamour\u00f6s. Es ist Routine, und es funktioniert. Die Websites, die kompromittiert werden, sind fast nie diejenigen, die all das getan haben. Es sind die, die das meiste davon getan haben oder gar nichts, und annahmen, sie seien zu klein, um aufzufallen.<\/p>\n