© smile4mone, Photocase.com
Mit Blog-Komplettpaketen wie WordPress oder B2evolution ist es für den Anwender kinderleicht, Texte im Internet zu veröffentlichen. Doch für die vielen handlichen Features brauchen große Blogsysteme mehrere MBytes potenziell unsicheren PHP-Code.
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.
Schreibwerkzeug
Der Editor in WordPress präsentiert sich als Musterbild für Usability (Abbildung 1): Der linke Teil des Fensters ist ganz den Texteingabefeldern vorbehalten, die Kontrollkästchen für Einstellungen finden sich am rechten Rand, farbige Titelleisten gliedern sie übersichtlich. Ein Klick auf das Symbol links oben in der Leiste enthüllt oder verbirgt eine Gruppe von Bedienelementen, dank Ajax ohne Verzögerung. Auch die Größe des Editorfenster passt der Benutzer wie von einer Desktopanwendung gewohnt durch Ziehen des Anfassers am rechten unteren Rand an. Die Einstellungs-Unterfenster lassen sich ein- und ausblenden und per Drag&Drop neu anordnen.
Abbildung 1: Gut zu bedienen: In dem mit Ajax-Elementen ausgestatteten Editor von WordPress kann sich der Blogautor ganz auf das Texten konzentrieren.
Beim B2evolution-Editor (Abbildung 2) lenken animierten Smileys am oberen Rand des Eingabefelds vom Text ab. Formatierungs-Buttons wie bei WordPress sucht der Anwender vergebens. Zwar gibt es sie in der Experten-Ansicht, doch beim Zurückschalten in den einfachen Modus verwandelt sich eingegebener HTML-Code nicht wie bei WordPress in eine Wysiwyg-Anzeige. Selbst wer mit HTML vertraut ist, kann den Mix aus Tag und Text schwer lesen. Beim Schreiben längerer Beiträge stört es außerdem, dass sich die Größe des Editorfensters nicht verändern lässt. Abhilfe verspricht das Tinymce-Plugin [9].
Abbildung 2: Zuckende Smileys als Blickfang: Der Standardeditor von B2evolution ist nicht Wysiwyg-fähig, die Oberfläche wenig ergonomisch gestaltet. Das Tinymce-Plugin sorgt wenigsten für formatierten Text.
Wer auf »Speichern« klickt, gelangt bei B2evolution auf eine Seite, die den Erfolg des Speicherns bestätigt. Wer zum bearbeiteten Eintrag zurückkehren will, benötigt den »Zurück«-Button des Browsers. Ein Pendant zum »Zwischenspeicher«-Button bei WordPress, der den Editor wie in Desktop-Anwendungen beim Sichern geöffnet lässt, gibt es nicht.
Hinterfragt
Punkte sammelt B2evolution hingegen mit seinem HTML-Syntax-Check: Wie ein Blick in »conf/_formatting.php« zeigt, überprüft die Software den vom Benutzer eingegebenen HTML-Code anhand von Positivlisten erlaubter Tags und ergänzt fehlende Tag-Paare, wenn die Variable »$use_balanceTags« den Standardwert »1« behält. Nicht unbedingt sinnvoll ist es, dass B2evolution ohne die Anpassung von »_formatting.php« auch dem Eigentümer der Seite Javascript-Code nicht erlaubt.
Der WordPress-Editor dagegen warnt bei ungültigem HTML-Code wie etwa bei Text, der in einer ungeordneten Liste außerhalb von »li«-Tags steht, selbst dann nicht, wenn die Einstellung »Wordpress soll falsch verschachteltes XHTML automatisch korrigieren« aktiv ist. Im Wysiwyg-Editor entstehen HTML-Syntaxfehler allerdings erst gar nicht. WordPress prüft die Rechtschreibung des eingegebenen Textes mit Hilfe eines Online-Dienstes auf WordPress.com, bisher allerdings nur auf Englisch. [10] erläutert, wie sich Aspell durch ein Upgrade des in WordPress integrierten Editors Tinymce einbinden lässt.
Schlank und rank
Beim Feature-Count kann Project Steve Guttenberg mit den beiden großen Blogsystemen im Test nicht mithalten: Statt eines Editors mit Formatierungsfunktion enthält die Software für die Texteingabe nur ein einfaches HTML-Formularfeld. Die Software enthält jedoch einen Rechtschreib-Check und eine HTML-Gültigkeitsprüfung.
Für die Rechtschreibung nutzt Project Steve Guttenberg Aspell, das auf dem Server zur Verfügung stehen muss. Beim Aufruf von Aspell übergibt die Software auch die unter »Preferences« eingestellte Sprache als Parameter, was Hoffnung auf eine deutsche Rechtschreibprüfung macht. Da die Anwendung bei Texten mit Umlauten die Wortgrenzen falsch setzt, hebt sie jedoch im Spellcheck die falschen Wörter als Fehler hervor.
Wie Abbildung 3 zeigt, beziehen sich die Korrekturvorschläge auf den nicht markierten Fehler »Passphrassen«, nicht auf das dahinter stehende, rot hervorgehobene »Bild«. Auch der HTML-Syntaxcheck enttäuscht: »<a href=”https://www.linux-magazin.de”>Linux-Magazin</a>« lehnt dieser mit der Fehlermeldung »> required (code 73)« ab.
Abbildung 3: Des Deutschen nicht mächtig: Wie die Korrekturvorschläge zeigen, markiert die Rechtschreibprüfung von Project Steve Guttenberg falsche Wörter, wenn im Text Umlaute vorkommen.
Der nutzbare Funktionsumfang von Project Steve Guttenberg beschränkt sich also auf die Blog-Grundfunktion, das Veröffentlichen von Textbeiträgen. CSS-Tags ermöglichen es, das Blog in ein bestehendes Layout einzupassen. Blogeinträge dürfen aus direkt auf der Seite angezeigtem Vorspann und weiterführendem Text bestehen, der erst nach Klick auf »Read More…« sichtbar wird. Englische Beschriftungen wie »Read More…« oder »Posted by« lassen sich durch Bearbeiten der Include-Datei »messages_en.php« übersetzen. Eine deutsche Variante der »messages_de.php« liegt bei, sie ist allerdings unvollständig. Auch WordPress liegt in einer deutschen Version vor [1], für B2evolution gibt es viele Sprachenpakete [11].
Neue Artikel speichert Steve Guttenberg zunächst auch als Draft zwischen, der Editor bleibt dabei geöffnet. Veröffentlichte Artikel können unregistrierte Seitenbesucher mit Kommentaren versehen, wenn die festgelegte Maximalzahl der Kommentare pro Artikel größer null ist. Ist die Option »Moderate Comments« aktiv, warten eingegangene Kommentare unter »Moderate« auf Freigabe.
Eine Liste zum schnellen Überblick über neue Kommentare gibt es nicht, dafür jedoch eine E-Mail-Benachrichtigung. Voraussetzung für das Versenden von Mails ist eine korrekte Sendmail-Konfiguration, die manche Webhoster aber nicht bereitstellen. WordPress und B2evolution erweisen sich mit einer chronologischen Liste neuer Kommentare als praxistauglicher. Besonders hilfreich beim schnellen Überblick ist der Masseneditiermodus in WordPress, der viele Kommentare in einen Arbeitsschritt löscht.
Angehängt
Alle drei getesteten Blogsysteme unterstützen Datei-Attachments. Bei Project Steve Guttenberg fällt diese Funktion allerdings ziemlich rudimentär aus: Der Benutzer fügt beim Erstellen von neuen Artikeln eine Datei zum Upload hinzu. Die Software ersetzt dann den Schlüsselcode »<Upload>« durch den Pfad zu dieser Datei auf dem Server. Soll der Pfad als Link dargestellt werden, muss sich der Anwender aber selbst um den HTML-Code dazu kümmern. Beim Editieren bestehender Einträge steht diese Funktion unverständlicherweise nicht zur Verfügung.
Eine Tagging-Funktion gibt es bei allen drei Systemen. Bei Project Steve Guttenberg besteht sie nur in einem Texteingabefeld, in das der Benutzer Schlagwörter kommasepariert einträgt. Besser für die Kohärenz der Auszeichnung ist die Kategorienliste in B2evolution, in der der Anwender aus vorher festgelegten Kategorien auswählt. Wer jedoch neue Einträge benötigt, muss den Texteditor verlassen. Am besten löst WordPress das Problem: Hier ergänzt ein Freitextfeld die Liste der bereits verwendeten Kategorien.
Nicht für alles offen
Alle drei getesteten Systeme bringen im Standardumfang einfache Antispam-Funktionen mit. Der Spamschutz von Project Steve Guttenberg beschränkt sich auf das Ausschließen bestimmter Domains oder IP-Adressen und ist in der Praxis weitgehend nutzlos. Der Programmcode der aktuellen Version 1.13.0 enthält jedoch Hooks zum Einbinden der Spamschutzdienste Captchas.net und Akismet.com. Captchas.net stellt die bekannten Captcha-Images (Abbildung 4), kostenlos zur Verfügung, die Kennwörter vor einem gemusterten Hintergrund darstellen und damit eine maschinelle Erkennung erschweren. Akismet.com sortiert die Kommentarbeiträge anhand ihres Inhalts, erfordert also keine Benutzerinteraktion. Für nicht kommerzielle Seiten ist der Dienst kostenfrei.
Abbildung 4: So genannte Captcha-Images, die eine vom Benutzer einzugebende Passphrase vor gemustertem Hintergrund anzeigen, um OCR zu erschweren, bilden einen wirkungsvollen Schutz gegen Spamroboter.
Plugins als Ausweg
Der Spamschutz von B2evolution geht bereits im Auslieferungszustand etwas weiter. B2evolution.net stellt zur Spamerkennung aktuell gehaltene Listen mit Schlüsselwörtern zur Verfügung. Ein Task-Planer, der dies automatisiert, ist eingebaut. Damit er funktioniert, muss allerdings ein Cronjob regelmäßig »cron/cron_exec.php« aufrufen. Stärkeren Schutz versprechen Plugins. Wie bei Project Steve Guttenberg existieren ein Captcha-Image- und ein Askimet-Plugin. Eine vollständige Liste steht unter [13]. Um ein Plugin zu installieren, muss der Administrator lediglich den Inhalt eines Zip-Archivs in den »plugins«-Unterordner im B2evolution-Verzeichnis kopieren und die Erweiterung über das grafische Backend aktivieren.
Wie bei B2evolution ist auch bei WordPress der Spamschutz im Lieferumfang der Software nur schwach vertreten. Da Spameinträge oft viele Links enthalten, kann der Administrator eine Anzahl festlegen, ab der Kommentare in der Freigabewarteschlange landen.
Auch bei WordPress bieten erst Plugins einen wirksamen Schutz vor Spam. Wie bei B2evolution muss der Administrator diese lediglich in das »plugins«-Verzeichnis entpacken und über das Konfigurations-Backend einschalten und konfigurieren. Für die verbreitete Software gibt es eine große Auswahl an Spamschutz-Plugins: Die WordPress-Plugindatenbank [14] listet 31 Erweiterungen. Darunter befindet sich auch ein Captcha-Plugin, das nicht von einem externen Dienst abhängt, sondern die Bilder mit den PHP-Bordmitteln erzeugt.
Siegertreppe
WordPress erringt den ersten Preis für Usability. Die bereits aufgetretenen Sicherheitsprobleme schrecken jedoch ab. Das Backend von B2evolution ist schlechter zu bedienen, die Anwendung gibt sich aber in puncto Sicherheit weniger auffällig. Doch nur ein Sicherheits-Audit könnte klären, ob dies an besserer Qualität oder geringerer Verbreitung liegt. Project Steve Guttenberg braucht keine Datenbank, bleibt mit 250 KByte Code überschaubar und eignet sich zum Einbetten in eigene Anwendungen.
