WordPress ist gelegentlich nicht wirklich sehr schnell bei der Auslieferung von Seiten. Das hängt unter anderem auch mit der Vielzahl von Datenbankabfragen zusammen, die WordPress pro Aufruf durchführt. Zu einem Problem kann das werden, wenn viele User gleichzeitig ein WordPress-Blog aufrufen und Speicher sowie Prozessorkapazität auf dem Host arg begrenzt sind. Verschärft wird das Problem durch Plugins und Widgets, die gelegentlich auch noch gern Scripte von anderen Seiten nachladen und somit die Ladezeit noch zusätzlich verlängern. Vom Speicherverbrauch dieser Extras mal gar nicht zu reden…

Optimierungsmöglichkeiten gibt es hier einige, überflüssige Gimmicks und Plugins zu entfernen wäre eine Möglichkeit, die man als erstes in Angriff nehmen sollte, wenn die Ladezeit des Blogs zu lang wird. Aber auch Caching trägt einen guten Teil zur Beschleunigung einer Seite bei.

Ich habe hier auf meinem Blog seit 3-4 Wochen das Caching-Plugin W3 Total Cache im Einsatz. Der Geschwindigkeitszuwachs beim laden der Seite war deutlich spürbar. Die Ladezeiten meines Blogs lagen laut Webmaster Tools vor dem Einsatz des Plugins bei teilweise bis zu 8-10 Sekunden, vor allem bei Einträgen mit vielen Kommentaren. Hier hatte ich zunächst die Paged Comments aktiviert (sieht man ja bereits seit einiger Zeit) und so ca. 1 Sekunde Ladezeit gewonnen. Mit dem Plugin ging die Ladezeit der langsamsten Seiten dann herunter auf unter 4, teilweise unter 3 Sekunden. Ziemlich flott, wie ich finde. Weitere Optimierungsmöglichkeiten würde ich jetzt noch am Template sehen, hier kommt aber möglicherweise demnächst ohnehin etwas ganz anderes.

Vor 2 oder 3 Tagen hatte ich ein weiteres Caching-Plugin für WordPress getestet: Hyper Cache. Und ich fand, dass die Seite noch einmal spürbar flotter geladen wurde. Zumindest in Chrome, den ich ja einsetze. Subjektiv war die Seite richtig schnell, messbar war es noch nicht, da die Webmaster Tools ja immer mit ein paar Tagen Verzögerung die Wirkung einer Maßnahme anzeigen.

Leider wurde mir allerdings gestern gemeldet, dass mein Blog „völlig zerschossen“ sei. Der erste Check mit Chrome brachte nix, sah alles toll aus, keine Probleme zu sehen. Doch dann versuchte ich es mit dem Firefox und meine Seite sah so aus (was möglicherweise einigen von Euch ebenfalls aufgefallen ist):

Schick, oder?

Nach einer ersten Schrecksekunde fiel mir auf: Moment, exakt so sehen die Cache-Files aus, die Hyper Cache auf der Platte ablegt. Also Hyper Cache deaktiviert, erneut geprüft und alles war wieder schick.

Bisher habe ich noch keine Lösung gefunden, ich hab noch keinen Schimmer, warum Firefox die Seiten nicht darstellen kann, wenn Hyper Cache aktiviert ist. Ich hoffe, hier noch eine Lösung finden zu können denn ich empfand die Beschleunigung durch Hyper Cache doch noch etwas besser als die, die mir W3 Total Cache liefert. Die ist durchaus auch nicht schlecht, keine Frage, aber Hyper Cache war eben subjektiv einen Touch flotter. Was nur leider nichts bringt, wenn die Browser die Seiten anschließend nicht mehr darstellen können.

Vielleicht ist es in den letzten Minuten dem Einen oder Anderen aufgefallen, kurz bevor mein Blog nicht mehr erreichbar war: Die letzten 49 Beiträge waren durch die Bank identisch.

Eigentlich (!) hatte ich nur mal wieder experimentiert. Ich wollte ein Plugin testen, welches in meiner lokalen Installation anstandslos funktionierte: Shared Items Post. Dieses Plugin liest meine aktuellen Empfehlungen aus, die ich im Google Reader gesetzt habe und postet sie als eigenständigen Beitrag, einmal am Tag. So weit die Theorie.

Was in der Praxis daraus resultierte, konnte man nun gerade eben schön beobachten: Das Plugin hat binnen weniger Sekunden 49 identische Einträge in die Datenbank geschrieben, worauf diese dann dicht machte. Schnelle erste Hilfe: Per FTP das Plugin vom Server gelöscht und einige Sekunden später war der Server wieder erreichbar und die Datenbank um 49 Beiträge größer 😉 Diese hab ich nun wieder gelöscht und das Plugin bleibt draußen.

Eigentlich ein wenig schade, genau diese Möglichkeit würde ich gern noch nutzen. Bislang habe ich immer den Umweg über Delicious genommen, finde aber die Empfehlungen im Reader direkt ungemein praktisch. Als Widget mag ich die Empfehlungen nicht einbinden, mir gefällt die Möglichkeit, dafür täglich einen eigenständigen Beitrag automatisch zu erstellen. Aber leider scheint daraus vorerst nichts zu werden, denn auch die Weiterentwicklung dieses Plugins mit dem Namen SharedItems2WP funktioniert nicht. Im Gegensatz zum Original macht diese nämlich garnix (was angesichts der möglichen Ausmaße, die mir glücklicherweise erspart geblieben sind, angenehm harmlos ist).

Nachdem ich es heute bei Caschy mal live gesehen habe, bastel ich auch gerade mal ein wenig mit Google Friend Connect herum. Man sieht es ja rechts in der Sidebar.

So wie es aktuell integriert ist, macht es allerdings in meinen Augen noch nicht ganz so viel Sinn. Man kann „Mitglied“ werden und das wird dann auch schön mit bunten Bildchen angezeigt, das war es auch schon. Funktionell ist nichts gewonnen. Einen Nutzen bringt das Ganze erst dann, wenn beispielsweise dadurch die lästigen Zusatzangaben beim kommentieren entfallen würden.

Genau da liegt aber im Augenblick noch der Hase im Pfeffer: Ich hab bislang noch kein vernünftiges WordPress Plugin dafür entdeckt. Ein Plugin erweckt den Eindruck, das zu können, aber die Seite der Entwickler steht zum Verkauf, hier ist also wohl nicht mit Updates zu rechnen. Und der getestete Rest ist irgendwie nix. Das Plugin von Google integriert sich so radikal, dass anschließend alle vorhandenen Kommentare nicht mehr zu sehen sind und nur noch die über Google Friend Connect verfassten Kommentare angezeigt werden. Ist also auch nix.  (siehe Update am Ende)

Ich schaue mich natürlich weiter um, vielleicht finde ich ja noch etwas, vielleicht kennt auch jemand von Euch eine gute Lösung. Vorerst ist die Integration von Friend Connect hier definitiv noch im Alpha-Stadium 😉

Update: Anders als eben noch geschrieben, integriert sich das Plugin von Google doch auch wesentlich angenehmer. Die Option „Enable FriendConnect Comments“ tauscht die Kommentarfunktion komplett aus und integriert eine eigene. Dadurch sind auch die alten Kommentare nicht mehr sichtbar. Deaktiviert man diese Funktion, dann hängt sich das Plugin nur über einen Hook in die WordPress Kommentarfunktion und erlaubt es dann, wenn man per Friend Connect angemeldet ist, mit den dort hinterlegten Daten zu kommentieren. So macht das alles natürlich wesentlich mehr Sinn. Also korrigiere ich von Alpha- auf Beta-Stadium 😉

WordPress ist bei den meisten Nutzern gerade aufgrund seiner Flexibilität und einfachen Erweiterbarkeit sehr beliebt. Gerade letzteres bietet jedoch eine Vielzahl von Möglichkeiten, Backdoors einzuschleusen, die unerwünschten „Besuchern“ eine Menge Möglichkeiten für Unsinn verschaffen können.

Wie einfach es beispielsweise ist, eine Backdoor in ein Template zu integrieren, welche einen Benutzer in WordPress anlegt und diesem Administrator-Rechte zuweist, zeigt der Beitrag „How-To: Create Backdoor Admin Access in WordPress„. Der Code sitzt in der functions.php des Templates und wird durch einen speziellen Aufruf der Zielseite aktiviert. Mittels der Funktion wp_create_user aus wp-includes/registration.php wird nun ein neuer Benutzer in der Datenbank angelegt und zum Administrator gemacht. Fertig, die Tür ist offen. Egal, ob die Registrierung von neuen Benutzern erlaubt ist oder nicht.

Um solch eine Backdoor nachträglich in eine WordPress-Installation zu integrieren, benötigt ein Angreifer natürlich Zugriff auf die Daten, beispielsweise via FTP. Allerdings ist man darauf nicht zwingend angewiesen, was hindert einen potentiellen Angreifer daran, eine Seite aufzusetzen, von der man Unmengen an WordPress-Templates herunter laden kann, die durch die Bank mit einer solchen Funktion präpariert sind? Oder warum sollte ein Entwickler nicht ein solches Hintertürchen in sein wunderbares WordPress-Plugin integrieren? Hand aufs Herz: Wie groß wird der Anteil an WordPress-Nutzern wohl sein, die PHP beherrschen und ein solches Hintertürchen erkennen könnten? 10%? Und wie viele prüfen denn tatsächlich jedes Plugin oder Template auf potentiellen Schadcode? 1%? Weniger?

Aktuell überwiegt einfach das Vertrauen. Vertrauen in die Redlichkeit der Entwickler und Vertrauen in die Ehrlichkeit der Betreiber von Template-Portalen. Sicherlich löblich, offenbar ist noch nicht zu viel passiert in der Vergangenheit. Aber ein wenig Vorsicht sollte dennoch angebracht sein und somit sind vorbeugende Maßnahmen sicherlich nicht falsch.

Den oben beschriebenen „Exploit“ (um einen „echten“ Exploit handelt es sich meiner Meinung nach nicht wirklich) kann man auf verschiedene Weisen aushebeln.

Variante 1: Wir benennen die Datei wp-includes/registration.php einfach um. Damit hebeln wir allerdings automatisch sämtliche Funktionen zur Bearbeitung bereits existierender Benutzer aus. Also nicht so schick. Zudem ist das nach jedem WordPress-Update zu wiederholen.

Variante 2: Wir kommentieren die Funktion wp_create_user in der Datei wp-includes/registration.php aus. Das Gleiche müssten wir mit der Funktion wp_insert_user in der gleichen Datei tun. Auch hier sind verschiedene Funktionen in der Admin-Oberfläche anschließend defekt und auch dieses Procedere müsste nach jedem Update wiederholt werden. Also auch nicht wirklich schön…

Variante 3 (empfohlen): Wir legen einen zusätzlichen Verzeichnisschutz für das Verzeichnis /wp-admin/ an. Die meisten Provider bieten diese Funktion in der Admin-Oberfläche an, wer diese Funktion bei seinem Provider nicht findet, dem empfehle ich Punkt 8 dieses Artikels. Hier wird die Vorgehensweise recht gut erläutert, auch die anderen Tipps sind prinzipiell sehr zu empfehlen.
Dieser zusätzliche Verzeichnisschutz sorgt nun dafür, dass für den Zugriff auf /wp-admin/ eine zusätzliche Anmeldung erforderlich ist. Bevor also ein Angreifer, der bspw. die oben beschriebene Backdoor ausführen konnte, sich mit seinem neuen Benutzer an Eurem Blog anmelden könnte, müsste er eine weitere, von WordPress unabhängige Authentifizierung erfolgreich vollziehen. Wenn Ihr hier mit einem ausreichend starken Passwort arbeitet, wird das (relativ) schwierig.

Wie weiter oben bereits geschrieben, sehe ich die im verlinkten Beitrag aufgezeigte Möglichkeit zum Anlegen eines administrativen Benutzers nicht als „echten“ Exploit an sondern sehe die Problematik allgemein in der Möglichkeit der Erweiterbarkeit. Und sicherlich beschränkt sich das Problem somit nicht allein auf WordPress. Allerdings ist es natürlich durch die von WordPress zur Verfügung gestellten Funktionen wesentlich einfacher, erfolgreich eine Hintertür einzurichten. Möglicherweise sollten gerade die Funktionen zur Erstellung und Änderung von Benutzern gekapselt werden und eben nicht von jedem xbeliebigen Addon genutzt werden können. Aktuell ist es aber möglich, daher sollten WordPress-Nutzer sich nicht allein auf die mitgelieferten Sicherheitsfunktionen verlassen, sondern selbst Hand anlegen. Und sicherlich auch hin und wieder mal nachschauen, ob plötzlich neue Benutzer in der Datenbank auftauchen, obwohl die Registrierung nicht erlaubt ist.