WordPress Sicherheit | YuMDaP.net Blog

Auf be-jo.net gibt es gerade ein paar Tipps zum Absichern von WordPress. Dazu hier noch mal ein paar ergänzende Tipps:

Im Admin-Backend ausschließlich TLS nutzen, oder einfach gleich auf der ganzen Seite.
BACKUPS!!!!11!!!!1elf
Nicht admin als Admin-Username benutzen
Datenbank-Tabellen einen (zufälligen) Prefix geben. Da WordPress bis heute darauf verzichtet auf sichere Art und Weise mit der Datenbank zu kommunizieren (s.g. prepared statements) können immer wieder SQL-Injection-Lücken auftauchen, sowohl bei WordPress selbst, wie auch bei den genutzen Plugins (und das passiert auch bis heute regelmässig). Um nicht Opfer von (billigen) automatisierten Angriffen zu werden reicht häufig ein Prefix
Zugriff auf wp-config.php webserverseitig verbieten. Aus unterschiedlichen Gründen könnte PHP mal nicht laufen. Per default würde die wp-config.php dann einfach als Text ausgeliefert werden, so dass extern die Datenbank-Passwörter und Security-Keys bekannt wären.
Dateirechte so weit wie möglich begrenzen. Je nach Webserverkonfiguration sind z.B. diese Werte sinnvoll:
755 für alle Ordner, 644 für alle Dateien, 600 für wp-config.php
Mit iThemes Security das WordPress-Backend verstecken bzw. unter einer anderen URL zugänglich machen als wp-login.php bzw wp-admin. Das ist ganz klar security-by-obscurity, sollte man aber gerade bei prominenten Seiten machen, um sich schon mal einige Idioten vom Hals zu halten.

5 Gedanken zu „WordPress Sicherheit“

Peter 26. Januar 2018 um 20:29

kein WordPress nutzen

Antworten ↓

dakira Beitragsautor26. Januar 2018 um 20:31

Auf jeden Fall auch sinnvoll. Als Alternative kann ich da z.B. Hugo empfehlen.

Antworten ↓
Fryboyter 27. Januar 2018 um 07:23

Leichter gesagt als getan. WordPress hat halt den Vorteil, dass man es leicht bedienen kann, dass es viele Plugins gibt und das es so gut wie auf jedem Webspace läuft. Mir ist jetzt keine vergleichbare Alternative bekannt, die die alles unter einen Hut bringt.

Nehmen wir alleine schon mal die oft fehlenden Plugins diverser Alternativen. Nicht jeder kann oder will sich hier etwas selbst basteln. Ich will lieber gar nicht wissen, was passiert wenn Lieschen Müller sich selbst etwas zusammen frickelt. Da ist der nächste Supergau schon vorprogrammiert.

Das Problem an WordPress ist auch nicht WordPress an sich. Wenn man hier zeitnah die Updates einspielt und vernünftige Zugangsdaten nutzen, hat man eigentlich kein Problem. Wer halt nur alle 6 Monate (wenn überhaupt) Updates einspielt, braucht sich nicht wundern wenn seine Seite kompromittiert wurde. Dafür kann aber WordPress nichts. Sicherheitslücken gibt es auch bei anderen Systemen. Fluch und Segen zugleich sind die Plugins. Hierüber werden meiner Erfahrung nach die meisten Seiten kompromittiert (trifft zum Beispiel auch bei Joomla zu). Was aber halt auch wieder oft am Betreiber liegt. Plugins die schon 2 Jahre kein Update mehr erhalten haben, sollte man halt nicht installieren. Hier sollten die WordPress-Entwickler und Seitenbetreiber vielleicht auch mal ausmisten. Und von den restlichen Plugins lässt sich eigentlich mit Google und Co. recht leicht die Spreu vom Weizen trennen.

Als ich noch WordPress genutzt habe, habe ich die Updates zeitnah eingespielt und nicht jeden Mist installiert. Zudem hatte ich noch den Benutzernamen des Admin-Kontos sowie den Datenbank-Suffix geändert. Das hat bei mir schon gereicht, um mehrere Jahre einer Kompromittierung aus dem Wege zu gehen. Versuche von Scriptkiddies gab es aber oft genug.

Antworten ↓
1. dakira Beitragsautor27. Januar 2018 um 17:09
  Das Problem an WordPress ist auch nicht WordPress an sich.
  
  Doch, das würde ich schon so sehen. Es hat ganz nette Backend-Nutzbarkeit, aber die Entwicklungs- und Sicherheitspolitik bei WordPress ist einfach nur zum Gruseln. Wie oben bereits angedeutet:
  - WordPress nutzt keine prepared statements. Es gibt zwar die Funktion wpdb::prepare(), die gaukelt aber nur prepared statements vor. In Wirklichkeit wird im Hintergrund nur mysqli_real_escape_string() genutzt, was nachweislich unsicher ist (und auch ausgenutzt wird). Wenn man überlegt, dass SQL-Injections mit der Einführung von PDO im Jahre 2005 als Bug-Klasse eigentlich besiegt wurden ist es einfach nur lächerlich, dass WordPress das 13 Jahre später immer noch nicht auf die Kappe kriegt.
  - Automatische Updates (eigentlich ja gut) sind unsicher, weil nicht signiert und auch sonst nicht geschützt.
  - MD5 für Password hashes. Ja genau. Obwohl WordPress eine library nutzt, die per default automatisch sichere hashes nutzen würde. Aus backward-compatibility-Gründen (falls mal jemand sein WordPress downgraden will, kein witz) enforcen sie die Nutzung vom MD5.
  - Quellcode ist ein Graus. Pseudo-OOP, überall „god objects“ und riesige Dateien mit etlichen helper Funktionen.
  Das heutige WordPress sieht trotz der gut aufgestellten Firma dahinter immer noch aus, wie ein PHP-Projekt Ende der 90er, Anfang 2000. Ich will ja nicht jedem „moderne“ Entwicklungsmethoden aufzwingen. Aber einige Dinge haben sich einfach bewährt, wie z.B. ein wohldefinierter Request<->Respone-Zyklus mit vernünftigem Routing.
  
  Das einzige, was WordPress ausmacht ist das Ökosystem darum und das gut funktionierende Backend. Wenn man sich so einige Plugins und Themes anschaut, dann sind die übrigens von deutlich höherer Qualität als der WordPress-Core.
  Antworten ↓

Pingback: Wochenrückblick KW 4/2018 – vNotes

Schreibe einen Kommentar zu Fryboyter Antworten abbrechen

Peter 26. Januar 2018 um 20:29

kein WordPress nutzen

Antworten ↓
1. dakira Beitragsautor26. Januar 2018 um 20:31
  
  Auf jeden Fall auch sinnvoll. Als Alternative kann ich da z.B. Hugo empfehlen.
  
  Antworten ↓
2. Fryboyter 27. Januar 2018 um 07:23
  
  Leichter gesagt als getan. WordPress hat halt den Vorteil, dass man es leicht bedienen kann, dass es viele Plugins gibt und das es so gut wie auf jedem Webspace läuft. Mir ist jetzt keine vergleichbare Alternative bekannt, die die alles unter einen Hut bringt.
  
  Nehmen wir alleine schon mal die oft fehlenden Plugins diverser Alternativen. Nicht jeder kann oder will sich hier etwas selbst basteln. Ich will lieber gar nicht wissen, was passiert wenn Lieschen Müller sich selbst etwas zusammen frickelt. Da ist der nächste Supergau schon vorprogrammiert.
  
  Das Problem an WordPress ist auch nicht WordPress an sich. Wenn man hier zeitnah die Updates einspielt und vernünftige Zugangsdaten nutzen, hat man eigentlich kein Problem. Wer halt nur alle 6 Monate (wenn überhaupt) Updates einspielt, braucht sich nicht wundern wenn seine Seite kompromittiert wurde. Dafür kann aber WordPress nichts. Sicherheitslücken gibt es auch bei anderen Systemen. Fluch und Segen zugleich sind die Plugins. Hierüber werden meiner Erfahrung nach die meisten Seiten kompromittiert (trifft zum Beispiel auch bei Joomla zu). Was aber halt auch wieder oft am Betreiber liegt. Plugins die schon 2 Jahre kein Update mehr erhalten haben, sollte man halt nicht installieren. Hier sollten die WordPress-Entwickler und Seitenbetreiber vielleicht auch mal ausmisten. Und von den restlichen Plugins lässt sich eigentlich mit Google und Co. recht leicht die Spreu vom Weizen trennen.
  
  Als ich noch WordPress genutzt habe, habe ich die Updates zeitnah eingespielt und nicht jeden Mist installiert. Zudem hatte ich noch den Benutzernamen des Admin-Kontos sowie den Datenbank-Suffix geändert. Das hat bei mir schon gereicht, um mehrere Jahre einer Kompromittierung aus dem Wege zu gehen. Versuche von Scriptkiddies gab es aber oft genug.
  
  Antworten ↓
  1. dakira Beitragsautor27. Januar 2018 um 17:09
    Das Problem an WordPress ist auch nicht WordPress an sich.
    
    Doch, das würde ich schon so sehen. Es hat ganz nette Backend-Nutzbarkeit, aber die Entwicklungs- und Sicherheitspolitik bei WordPress ist einfach nur zum Gruseln. Wie oben bereits angedeutet:
    
    WordPress nutzt keine prepared statements. Es gibt zwar die Funktion wpdb::prepare(), die gaukelt aber nur prepared statements vor. In Wirklichkeit wird im Hintergrund nur mysqli_real_escape_string() genutzt, was nachweislich unsicher ist (und auch ausgenutzt wird). Wenn man überlegt, dass SQL-Injections mit der Einführung von PDO im Jahre 2005 als Bug-Klasse eigentlich besiegt wurden ist es einfach nur lächerlich, dass WordPress das 13 Jahre später immer noch nicht auf die Kappe kriegt.
    
    Automatische Updates (eigentlich ja gut) sind unsicher, weil nicht signiert und auch sonst nicht geschützt.
    
    MD5 für Password hashes. Ja genau. Obwohl WordPress eine library nutzt, die per default automatisch sichere hashes nutzen würde. Aus backward-compatibility-Gründen (falls mal jemand sein WordPress downgraden will, kein witz) enforcen sie die Nutzung vom MD5.
    
    Quellcode ist ein Graus. Pseudo-OOP, überall „god objects“ und riesige Dateien mit etlichen helper Funktionen.
    
    Das heutige WordPress sieht trotz der gut aufgestellten Firma dahinter immer noch aus, wie ein PHP-Projekt Ende der 90er, Anfang 2000. Ich will ja nicht jedem „moderne“ Entwicklungsmethoden aufzwingen. Aber einige Dinge haben sich einfach bewährt, wie z.B. ein wohldefinierter Request<->Respone-Zyklus mit vernünftigem Routing.
    
    Das einzige, was WordPress ausmacht ist das Ökosystem darum und das gut funktionierende Backend. Wenn man sich so einige Plugins und Themes anschaut, dann sind die übrigens von deutlich höherer Qualität als der WordPress-Core.
    Antworten ↓
Pingback: Wochenrückblick KW 4/2018 – vNotes

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.