Drei Blogsysteme im Sicherheits- und Antispam-Test

Eine Software zum Veröffentlichen von Textbeiträgen auf HTML-Seiten, das klingt nach einer Anwendung, die ein Webmaster an einem Nachmittag selbst schreibt. Für das verbreitete Blogsystem Wordpress [1] gibt das Software-Evalutionsportal Ohloh.net (siehe auch Einführung zur Rubrik "Software") jedoch einen Repository-Umfang von über 1,5 Millionen Zeilen PHP-Code an. B2evolution [2] bringt es auf immerhin knapp 100 000 Zeilen. Die Releases liegen bei 3,5 MByte (Wordpress 2.3 DE-Edition) und 7,5 MByte (B2evolution 1.10.2) Code.

Sancta simplicitas

Da die Sicherheit einer so großen Webanwendung schwer zu gewährleisten ist, bezieht diese Bitparade das Project Steve Guttenberg 1.13.0 [3] mit ein, das mit zirka 250 KByte Code auskommt.

Wordpress gilt mit seinen in der Vergangenheit aufgetretenen Anfälligkeiten, die von XSS-Attacken bis zur SQL-Injektion reichen, als geradezu berüchtigt. Secunia.de listet seit 2005 ganze 66 Schwachstellen. Hinzu kommen noch Verwundbarkeiten einzelner Plugins oder Themes. Stefan Esser, Gründer des PHP-Security-Response-Teams, wirft der Blogsoftware Schwächen bei der Umsetzung des Datenbankzugriffs vor [4].

Die bereits im Mai 2007 auf Hackers.org veröffentlichten URLs für XSS-Attacken [5] funktionieren auch bei der aktuellen Version immer noch. Sie verdeutlichen die Sicherheitsproblematik einer RPC-Schnittstelle, wie sie Wordpress und B2evolution für das Editieren des Blogs bereitstellen. Schließlich ist es Hackern sogar gelungen, in den Wordpress-Server einzubrechen [6].

Die große Verbreitung von Wordpress relativiert allerdings die Zahl der Problemberichte, die im Internet zu finden sind. Dass Secunia.de mit sechs Einträgen B2evolution deutlich weniger Probleme attestiert, lässt nicht unbedingt auf größere Sicherheit schließen. Vermutlich liegt die weniger bekannte Anwendung nicht in gleichem Umfang im Fokus der Sicherheitsexperten.

Auch selbst gestrickte Lösungen bergen Gefahrenpotenzial. Der Code mag noch so schlank und übersichtlich sein, bei der Vielzahl der Angriffstechniken auf Webanwendungen kann ein einzelner Entwickler kaum alle Bedrohungen vorhersehen. Auf das große Sicherheitsplus, dass viele Augen stets mehr sehen als zwei, müssen Eigenbauten im Gegensatz zu Open-Source-Anwendungen mit breitem Community-Support verzichten. Bis zu einem gewissen Grad gilt dies auch für Project Steve Guttenberg, bei dem laut Ohloh.net in den letzten zwölf Monaten nur zwei Entwickler Code beigetragen haben [7].

Qualitätskontrolle

Ein Blick in den Quellcode zeigt, dass es um die Code-Kommentierung bei Wordpress schlecht bestellt ist. Ohloh zählt 8 Prozent der Codezeilen als Kommentare, weit unter den üblichen 27 Prozent und wesentlich weniger als die 38 Prozent bei B2evolution. Die Kommentare dort sind so aussagekräftig, dass sich der Code schnell nachvollziehen lässt. Ohloh folgert vorsichtig: "Viele Kommentare könnten auf gut organisierten Code und ein engagiertes und diszipliniertes Entwicklerteam hindeuten."

Gewissheit über die Sicherheit der Anwendung können jedoch nur von Experten durchgeführte Sicherheits-Audits bringen, wie sie sich das Bulletin-Board Phpbb [8] Ende 2005 leistete. Für keines der drei getesteten Systeme liegen solche Audits vor. Die drei Blogsysteme sollten also, da Sicherheitslücken in der Vergangenheit häufig auftraten, nicht auf geschäftskritischen Servern laufen, der Administrator muss laufend nach aktuellen Versionen Ausschau halten.

Ein Debuggerlauf durch den Code fördert weitere Indizien über die Sicherheit zu Tage. So fällt positiv auf, dass B2evolution die höchste Error-Reporting-Stufe von PHP einschaltet. Nicht initialisierte Variablen lösen damit Fehlermeldungen aus, was aber im Test mit der Standardinstallation nicht der Fall war. Damit ist B2evolution zumindest in der Theorie gegen untergeschobene Variablenwerte sicher, selbst wenn der Server das verrufene PHP-Feature »register_globals« einschalet, das alle per Formular zugesandten Felder automatisch als gleichnamige Variablen registriert.

Zwar ist es nicht möglich, »register_globals« zur Laufzeit abzuschalten. Alle globalen Variablen, außer den für die Auswertung von Formulardaten eingeführten Arrays wie »$_GET« und »$_POST«, beim Start der Anwendung zu löschen ist jedoch leicht möglich. Entsprechender Code dazu ist in B2evolution in der Datei »_main.inc.php« ab Zeile 98 vorhanden, jedoch mit dem Hinweis auf Testbedarf auskommentiert. Da die Software seit 2003 existiert, enttäuscht es, dass sich der Sicherheitsmechanismus erst im Teststadium befindet.

Wordpress enthält zu Beginn von »wp-settings.php« PHP-Code, der gefährliche, automatisch registrierte Variablen löscht. Da Wordpress jedoch die Ausgabe von Debug-Mitteilungen ausschaltet und der Code uninitialisierte Variablen enthält, bedeutet das Löschen eventuell untergeschobener Werte hier keine zusätzliche Sicherheit, sondern bildet den einzigen Schutz für ansonsten bloßliegende Schwachstellen. Da das Verfahren aber nur greift, wenn jede PHP-Datei, die der Webserver abrufen kann, den entsprechenden Code auch ausführt, wäre es dennoch geboten, alle uninitialisierten Variablen im Quellcode zu tilgen.

Das Sicherheitsplus von Project Steve Guttenberg liegt in einem mit 250 KByte noch überschaubarem Quellcode. Das Blogsystem verzichtet außerdem auf eine Datenbank. Es speichert Blogeinträge und Kommentare in Dateien, die außerhalb von Webroot liegen dürfen.