8. September 2009 von Dieter | 10 Kommentare | drucken
WordPress: Wider dem Katastrophen-Gerede
Inhaltsverzeichnis
1. Hintergrund
Auf praegnanz.de erschien am 6. September 2009 der Blogbeitrag “WordPress – wann kommt es zur Katastrophe?“.
Dazu habe ich auch bereits einen Kommentar geschrieben. Gleichwohl habe ich aufgrund der apokalyptischen Stimmung, die mit diesem Artikel und einigen der dortigen Kommentare verbreitet wird, das Bedürfnis noch selbst Position zu Vor- und Nachteilen (Pros und Cons) von WordPress zu beziehen.
Vorsorglich noch der Hinweis, dass die Auflistung von Vor- und Nachteilen natürlich subjektiv ist und nicht abschließend sein kann.
Vor diesem Hintergrund sind Aktualisierungen und Ergänzungen
- aufgrund von Anmerkungen und Diskussionen in den Kommentaren sowie
- Geistesblitzen
möglich. Sie werde ich dann selbstverständlich kenntlich machen.
2. Vorteile von WordPress
Die Vorteile (Pros) von WordPress im Einzelnen:
Es
- lässt sich leicht und schnell installieren (sog. 5 Minuten Installation),
- erzeugt validen Code,
- verfügt über eine ausgesprochen intuitive Oberfläche im Administrationsbereich (Backend),
- gibt eine sehr aktive und hilfreiche WordPress-Gemeinde (Community) unter WordPress.org (englisch) und WordPress-Deutschland.org (deutsch),
- ist gut dokumentiert (Codex, Handbuch und deutsche Dokumentation),
- gibt viel und gute bis hervorragende Literatur dazu,
- ist Open-Source-Software (kostenlos und der Quelltext ist frei, sprich öffentlich zugänglich),
- gibt Hunderte von (kostenlosen) CSS-Layouts (sog. Themes) dafür,
- gibt Tausende von (kostenlosen) Erweiterungen (sog. Plugins) dafür,
- wächst mit meinen Bedürfnissen mit (von der reinen Blog-Software zu einem Content-Management-System (CMS)),
- gibt mehrere Themes auf YAML-Basis (Blitzblank, Simplex Theme, YAML Green, YAML Coffee)
- viele Arbeiten lassen sich mit WordPress und Plugins automatisieren (insbesondere Navigation, Anlegen neuer Seiten, Schlagwortwolke (tag cloud), ähnliche Artikel, Sitemap, XML-Sitemap für Suchmaschinen).
3. Nachteile von WordPress
Kommen wir zu den Nachteilen (Cons) von WordPress:
Es
- weist in der Standardinstallation - vergleichbar mit früheren Windows-Versionen - Sicherheitslücken ein defensives Sicherheitskonzept auf. Dieses lassen lässt sich jedoch durch Handarbeit sowie mit Plugins und zeitnahen Aktualisierungen (Updates) von WordPress schließen verbessern (siehe hierzu insbesondere meinen Blogbeitrag “Sicherheit von WordPress verbessern“),
- gibt wegen Sicherheitslücken (siehe hierzu meine Blogbeiträge “Angriffe auf alte WordPress-Installationen” und “Kritische Sicherheitslücke in WordPress“) und Weiterentwicklungen häufig Aktualisierungen (Updates), die möglichst zeitnah vorgenommen werden sollten (siehe hierzu meine Blogbeiträge “Webseiten-Infos.de auf WordPress 2.8.4 aktualisiert“, “Webseiten-Infos.de auf WordPress 2.8.3 aktualisiert“, “Webseiten-Infos.de auf WordPress 2.8.2 aktualisiert” und “Webseiten-Infos.de auf WordPress 2.8.1 aktualisiert“),
- benötigt immer mehr PHP-Speicher im Administrationsbereich (Backend), so dass aufgrund des PHP-Speicher-Limits für eine Aktualisierung (Update) ein Wechsel des Hosters notwendig werden kann (siehe hierzu meine Blogbeiträge “Ursache des enormen Speicherbedarfs gefunden!“, “Umzug zu einem anderen Webhoster” und “In eigener Sache: Umzug zu Alfahosting“),
- ist im Administrationsbereich (Backend) aufgrund des massiven Einsatzes von JavaScript relativ träge. Durch den Einsatz von modernen Browsern mit einer schnellen JavaScript-Engine (wie beispielsweise aktuell Google Chrome 2 und Firefox 3.5) kann man dem etwas entgegenwirken.
- Es ist schon lustig! Aktuell wird über WordPress hergezogen, weil es nicht sicher sei. Dabei ist die aktuelle Version 2.8.4 (ein Sicherheitsrelease!) von dem Wurmangriff nicht betroffen, weil mit ihr eben schnell eine Sicherheitslücke geschlossen wurde. Vor 2 1/2 Jahren stellte sich die Sicherheitsfrage viel drängender: Damals hatte es ein Cracker geschafft, sich Zugang zu einem Server von WordPress.org zu verschaffen und hatte zwei Dateien der zum Herunterladen bereitstehenden WordPress-Version 2.11 verändert (siehe dazu den Blogbeitrag “WordPress 2.1.1 und der “worst case”” bei WordPress-Deutschland.org).
4. Mein persönliches Fazit
- Jeder muss selbst abwägen und entscheiden, ob sie oder er WordPress angesichts der oben genannten Vor- und Nachteile einsetzen will.
- Sicherheitsmaßnahmen sind sehr wichtig. Wer nicht bereit ist dafür einschließlich zeitnahes Einspielen von Aktualisierungen (Updates) Zeit zu investieren, lebt mit einem höheren Risiko, dass seine WordPress-Installation gehackt wird. Alternativ kannst Du auch auf eine andere Software umsteigen und Du lässt gleich die Finger von eigenen Web-Anwendungen.
- WordPress wird immer mehr als Content-Management-System (CMS) oder als CMS mit integriertem Blog nutzbar und auch genutzt.
- Beliebte und stark verbreitete Open-Source-Software wie WordPress und der Browser Firefox werden verstärkt Ziele von Angriffen. Gefundene Sicherheitslücken werden dort aber regelmäßig schnell geschlossen. Diesbezüglich sei für den Firefox auf meinen Blogbeitrag “Sicherheitslücken: Internet Explorer besonders gefährdet” hingewiesen.
Das musste ich jetzt einfach mal raus lassen und bloggen. 
Infos
Webseite veröffentlicht am Dienstag, den 8. September 2009, um 20:45 Uhr, zuletzt geändert am Montag, den 26. Oktober 2009, um 23:17 Uhr.
Kategorie: WordPress
Schlagworte: Bücher, Nachteile, Plugins, Sicherheitslücken, Themes, Update, Vorteile, WordPress
Statistik: 204 Blogbeiträge, 568 Schlagworte, 695 Kommentare, 745 Feedleser
1. Thomas Scholz
Kommentar vom 8. September 2009 um 21:49
Welche Sicherheitslücken hat denn die Standardinstallation? Hast du dazu einen Bug gemeldet? Welche Nummer hat er? Das würde ich schon gerne wissen.
2. Dieter
Kommentar vom 9. September 2009 um 07:16
@Thomas
In der Standardinstallation ist
- der Zugang zum Login ungeschützt aufrufbar,
- wird automatisch der Nutzer Admin angelegt und
- gibt es keine Begrenzung der Anzahl der Login-Versuche.
Wenn man da nicht mittels
- Passwortschutz über die .htacess-Datei,
- Löschen des Nicks Admin,
- Plugin die Anzahl der Login-Versuche begrenzt oder
vergleichbare Maßnahmen ergreift,
dann dürften das leider gute Rahmenbedingungen für eine Brute-Force-Attacke sein oder habe ich da als Laie einen Denkfehler?
Wenn dann noch ein schwaches Passwort für den Administrator Admin gewählt wird, dann dürfte das m.E. kritisch sein. Zwar bekomme ich im Administrationsbereich (Backend) inzwischen angezeigt, ob ein Passwort schwach, mittel oder stark ist, aber ich glaube, schwache Passwörter werden von WordPress trotzdem zugelassen. Das habe ich allerdings allein schon aus Sicherheitsgründen nicht ausprobiert.
3. Thomas Scholz
Kommentar vom 9. September 2009 um 07:42
Das Paßwort, das WordPress bei der Installation erzeugt, ist schon recht stark. Es dürfte selbst mit Rainbow-Tables kaum in absehbarer Zeit zu knacken sein.
Das Verstecken des Logins und das Umbenennen des Administrators fallen unter »Security by obscurity«. Kann man machen, bringt aber kaum echte Sicherheitsvorteile.
Wer eine Brute-Force-Attacke wagt, der läßt sich davon nicht abschrecken.
»Sicherheitslücken« sind weder der Login noch das Standardkonto, es sei denn, du führst den Beweis dafür.
4. Dieter
Kommentar vom 9. September 2009 um 07:55
@Thomas
Das automatisch generierte Passwort dürften wohl die wenigsten WordPress-Administratoren belassen. Stattdessen wird dann ein eigenes Passwort gewählt, das auch schwach sein kann. Hier wäre meines Erachtens ein zusätzlicher Sicherheitsmechanismus, der den bequemen Nutzer schützt, weil er beispielsweise kein schwaches Passwort zulässt, hilfreich.
Sicherheit durch Unklarheit (Security through obscurity) würde ich auch nur ergänzend einsetzen. Der zusätzliche Passwortschutz mit der .htaccess-Datei erscheint mir da wichtig.
Du scheinst Dich an der Verwendung des Begriffs “Sicherheitslücken” zu stören. Wäre Schwachstellen im Sicherheitskonzept treffender oder hast Du einen anderen passenden Begriff?
5. Thomas Scholz
Kommentar vom 9. September 2009 um 08:41
Ja genau, an dem Ausdruck reibe ich mich. »Sicherheitslücke« heißt: Es existiert ein bekanntes und nachvollziehbares Einbruchsszenario, dessen Ursache im WordPress-Code liegt.
Aber das ist derzeit nicht der Fall. Wer seine Paßwörter vereinfacht, nimmt weniger Sicherheit bewußt in Kauf. Daran ist nicht WordPress schuld.
Man kann bestimmt ein paar Details verbessern. Aber wenn WordPress die Benutzer zu sehr gängelt, wird auch wieder geschimpft.
Im Moment regen sich all die Updateschlampen auf, zeigen mit dem Finger auf allen anderen und werfen mit halbgaren Vorschlägen um sich. Irgendwo habe ich sogar gelesen, WordPress solle doch einfach mal den Core neu schreiben. Hallo? Das wäre noch dämlicher als ein Jahr auf Updates zu verzichten.
Wenn also so viele Leute ihren Verstand ausknipsen, dann sollte doch der Rest – und dazu möchte ich dich gerne zählen – auf harte Fakten pochen und wieder Sachlichkeit in die Debatte bringen.
Übertreibungen nützen niemand. WordPress’ derzeitiges defensives Sicherheitskonzept ist keine »Lücke«, sondern schlicht der Weg, dem einzelnen Nutzer die Details zu überlassen. Ob das gut ist oder nicht, kann und sollte man diskutieren; aber bitte ohne Panikmache.
6. Dieter
Kommentar vom 9. September 2009 um 10:15
@Thomas
Danke für Deine sachliche und konstruktive Kritik.
Ich habe den Begriff “Sicherheitslücke” im ersten Kugelpunkt (bullet point) unter “3. Nachteile von WordPress” durch “defensives Sicherheitskonzept” ersetzt und den Text angepasst. Ich hoffe, das berücksichtigt hinreichend Deine berechtigte Kritik an der Verwendung des Begriffs Sicherheitslücke.
Ich suche auch nicht die Schuld bei WordPress, denn da gibt es viele andere wichtige Faktoren wie etwa die Konfiguration des Servers oder Webspaces sowie von PHP (Stichworte: safe_mode, open_basedir, register globals) sowie eben den WordPress-Betreiber selbst (Stichwort: Das Problem sitzt meistens 30cm vor dem Bildschirm
).
Damit hast Du den Nagel auf den Kopf getroffen.
Den Vorschlag den Core von WordPress neu zu schreiben habe ich im Blogbeitrag “WordPress – wann kommt es zur Katastrophe?” von Gerrit van Aaken gelesen. Das war übrigens der Auslöser für meinen Blogbeitrag (siehe 1. Hintergrund). Ich gebe zu, dass ich die Sinnhaftigkeit den Core von WordPress neu zu programmieren nicht beurteilen kann. Deshalb hatte ich mich auch einer Aussage dazu enthalten.
Ich teile Deine Auffassung, dass harte Fakten und Sachlichkeit die Grundlage der Debatte sein sollten. Sprachliche Genauigkeit ist da eine zwingende Voraussetzung. Hierzu gehört Dein Hinweis auf den nicht korrekten Gebrauch des Begriffs Sicherheitslücken. Er war für mich erhellend und äußerst hilfreich.
Ich würde es begrüßen, wenn künftige WordPress-Versionen den Nutzer durch intelligente Lösungen bei Sicherheitsfragen unterstützen (beispielsweise indem nur starke Passwörter zugelassen werden). Werde mal auf meine ToDo-Liste die Beschäftigung mit dem Vorschlagswesen bei WordPress.org setzen.
7. Trierer
Kommentar vom 5. Dezember 2009 um 21:02
Das Problem mit dem PHP-Speicher ist eigentlich ein ziemlich großes. Bei einem großen Provider, der gerade vom rosa Riesen mit dem T aufgekauft wurde, verursacht das regelmäßig Probleme, nicht nur bei WordPress, sondern auch bei Joomla. Ansonsten ist WordPress eigentlich sehr zu empfehlen, lässt sich intuitiv und schnell bedienen. Dass aber die Entwickler dieses PHP-Speicherproblem nicht anders lösen, ist mir schleierhaft.
8. Dieter
Kommentar vom 5. Dezember 2009 um 21:31
Das PHP-Speicherproblem habe ich für Webseiten-Infos.de durch einen Providerwechsel von one.com zu Alfahosting.de gelöst (siehe hierzu auch meine Blogbeiträge “In eigener Sache: Umzug zu Alfahosting” und “Umzug zu einem anderen Webhoster“).
Die Entwickler können nur bedingt etwas am Speicherbedarf verbessern. Meine persönliche Vermutung ist, dass der höhere Speicherbedarf zum einem aus dem Einsatz von objektorientierter PHP-Programmierung resultiert und zum anderen aus dem ständig steigenden Funktionsumfang neuer WordPress-Versionen.
Im Übrigen empfehle ich Dir meinen Blogbeitrag “Kommentar-Spam bekämpfen” zur Lektüre.
9. Thomas Scholz
Kommentar vom 5. Dezember 2009 um 21:40
@Trierer: Das Problem des Arbeitsspeichers liegt nicht beim PHP-Code, sondern beim Hoster. RAM ist so billig – 6 GB kosten nicht einmal 100 € – daß eine Begrenzung auf 32 MB oder weniger nur noch als Totalversagen des Anbieters bezeichnet werden kann.
Der erhöhte Speicherbedarf moderner Webanwendungen ist unausweichlich, und er hilft den Kunden, die Versager leichter zu erkennen. Deshalb finde ich ihn nützlich.
10. Dieter
Kommentar vom 5. Dezember 2009 um 21:51
@Thomas
Du hast in der Sache Recht, auch wenn ich Deine Formulierungen wie Totalversagen und Versager für zu kraftvoll halte.