Mathias Bank

phpBB ist gestern in der Version 2.18 erschienen. Wie ein Programmierer berichtet hat, wurde der gesamte Quell-Code von Sicherheitsexperten auf Fehler geprüft. Da hier doch etwas mehr Fehler gefunden wurden, ist das Update umfangreicher wie in der Vergangenheit. Die aktuelle Version kann derzeit in der englischen Version unter phpBB.com (zip) geladen werden. Die deutsche Version gibt es unter phpbb.de, auch gibt es hier eine Update-Anleitung.

Folgende Punkte wurden geändert:

# [Fix] incorrect handling of password resets if admin activation is enabled (Bug #88)
# [Fix] retrieving category rows in index.php (Bug #90)
# [Fix] improved index performance by determining the permissions before iterating through all forums (Bug #91)
# [Fix] wrong topic redirection after login redirect (Bug #94)
# [Fix] improved handling of username lists in admin_ug_auth.php (Bug #98)
# [Fix] incorrect removal of bbcode_uid values if bbcode has been turned off (Bug #100)
# [Fix] correctly preview signature if editing other users posts (Bug #101)
# [Fix] incorrect alt tag on generated search images in groupcp.php, viewtopic.php and usercp_viewprofile.php (Bug #102)
# [Fix] consistent forum ordering in all dropdown boxes (Bug #106)
# [Fix] correctly get compression status in page_tail.php and page_footer_admin.php (Bug #117)
# [Fix] set page title on summary page of groupcp.php (bug #125)
# [Fix] correctly test style and avatar in usercp_register.php (bug #129 and #317)
# [Fix] handling of reactivation notifications if admin activation is enabled (Bug #145)
# [Fix] handling of both forms of translation information used in language packs (Bug #159)
# [Fix] key length for activation keys fixed in usercp_sendpassword.php (Bug #171)
# [Fix] use GENERAL_MESSAGE constant in message_die instead of MESSAGE (Bug #176)
# [Fix] incorrect handling of move stubs (Bug #179)
# [Fix] wrong mode_type in memberlist (Bug #187)
# [Fix] SQL errors when setting maximum PMs to 0 (Bug #188)
# [Fix] removed unused variable from topic_notify email template (Bug #210)
# [Fix] removed unset variable from smilies popup window title (Bug #224)
# [Fix] removed duplicate template assignment from admin_board.php (Bug #226)
# [Fix] incorrect search link for guest posts in modcp.php (Bug #254)
# [Fix] all users removed from topics watch table on special occassions (Bug #271)
# [Fix] correctly check returned value from strpos in append_sid function (Bug #275)
# [Fix] correctly display username in private message notification (Bug #278)
# [Fix] fixed “var-by-ref” errors (Bug #322)
# [Fix] changed redirection to installation (Bug #325)
# [Fix] added timout of 10 seconds to version check (Bug #348)
# [Fix] fixed user_level default in postgresql schema file (Bug #444)
# [Fix] multiple minor HTML issues with subSilver
# [Change] deprecated the use of some PHP 3 compatability functions in favour of the native equivalents
# [Change] added 60 days limit for grabbing unread topics in index.php

# [Sec] backport of session keys system from olympus
# [Sec] fixed email bans to use the same pattern as email validation and allow wildcard domain bans
# [Sec] fixed validation of topic type when posting
# [Sec] unset database password once it is no longer needed
# [Sec] fixed potential to select images outside the specified path as avatars or smilies
# [Sec] fix globals de-registration code for PHP5 - (Stefan Esser/Matt Kavanagh)
# [Sec] changed avatar gallery code sections to prevent possible injection points (AnthraX101)
# [Sec] signature field is not properly sanitised for user input when an error occurs while accessing the avatar gallery (AnthraX101)
# [Sec] check to_username and ownership when editing a PM (AnthraX101)
# [Sec] fixed ability to edit PM’s you did not send (depablo84)
# [Sec] compare imagetype on avatar uploading to match the file extension from uploaded file

Ein Update ist dringend zu empfehlen.

Interessant ist unter anderem folgende Code-Änderungen zur Erhöhung der Sicherheit. Interessant deshalb, weil es auch in anderen Projekten sicher seine Anwendung finden könnte:
// Protect against GLOBALS tricks
if (isset($HTTP_POST_VARS['GLOBALS']) || isset($HTTP_POST_FILES['GLOBALS']) || isset($HTTP_GET_VARS['GLOBALS']) || isset($HTTP_COOKIE_VARS['GLOBALS']))
{
die("Hacking attempt");
}

Das gleiche kann man bei SESSION_VARS machen:

// Protect against HTTP_SESSION_VARS tricks
if (isset($HTTP_SESSION_VARS) && !is_array($HTTP_SESSION_VARS))
{
die("Hacking attempt");
}

Alle Änderungen können auf phpBBHacks.com eingesehen werden. Hier ist auch zu sehen, wie das image-Problem gelöst wurde: man prüft explizit auf den mime-Typ. Wenn dieser mit der Datei-Endung übereinstimmt und das Bild zudem größer 0 Byte ist (ein reines Script hat bei getimagesize immer 0 Byte) , dann wird das Bild akzeptiert.

Eben erreichte mich die Nachricht, dass ein neuer Fehler in phpBB Version 2.0.17 (derzeit zum Download noch empfohlen) aufgetaucht ist. Es handelt sich dabei um einen Cookie-Disclosure-Exploit. Wie bereits in der Version 2.0.16 soll es damit möglich sein, Cookie Informationen an andere Server zu senden und somit Benutzerdaten auszulesen. Diesesmal sind jedoch nur User mit dem Internet Explorer betroffen, wie auf securiteam zu lesen ist.

Danach führt der Internet-Explorer Code in fehlerhaften Bildern aus und kann somit Daten auslesen. Dies geschieht dadurch, dass der Internet-Explorer den Bild-Inhalt nicht nur als Bild, sondern auch als HTML-Code interpretieren kann (bekanntermaßen ist der IE recht fehlertollerant und akzeptiert falsche Header-Anweisungen - hier ein Schuss in den Ofen). Dieser Code wird dann gerendert.

Administratoren sind dazu aufgerufen, hochgeladene Daten entweder nicht zu akzeptieren oder den Inhalt genau zu prüfen (was ja eigentlich sowieso gemacht werden sollte, es in phpBB aber derzeit noch nicht gemacht wird). Die Entwickler von phpBB wurden bereits informiert, der Fehler soll in der Version 2.0.18 behoben werden.

[Update]
Interessant ist für Forenbetreiber und Entwickler evtl. diese Wiki-Seite. Danach gibt es ein Apache-Modul, welches den Inhalt einer Datei prüft und somit fehlerhafte Bilder nicht als Bilder ausliefert. Ebenfalls ist hier ein Code zu finden, mit dem man in PHP prüfen kann, ob ein Bild einen korrekten Header hat. Damit könnte man fehlerhafte Bilder bereits beim Upload ablehnen (es sei denn, man bindet externe Bilder ein, auf die man keinen Zugriff hat).

Heute konnte ich feststellen, dass sich die Bemühungen in der letzten Zeit wohl für den Strohhalm gelohnt haben. So ist jetzt wieder nach ein paar Monaten ein Page-Rank von 5 zu verzeichnen (anstatt zuvor 4). Ob dies an den Umleitungen der Domains oder an der Verwendung der Google-Sitemaps mit Hilfe von RSS liegt, ist natürlich die Frage. Zeit für Spekulationen!

Wie im vbSEO-Forum zu erfahren ist, soll vbSEO nun in einer Copyright-freien Version erscheinen. Bisher wurde beim Einsatz der Software am Ende der Seite ein Verweis auf vbSEO gesetzt. Nach den Wünschen einiger Kunden soll dies jetzt entfernbar sein. Nicht zuletzt dürfte dies mit Gerüchten zusammenhängen, nach dem Seiten mit einem Backlink auf vbSEO in Suchmaschinen schlechter bewertet werden. Wie so oft bei Gerüchten kann man sich auf diese Aussage aber nicht verlassen, da sie wohl schwer verifizierbar sein dürfte. Trotzdem stärken Gerüchte das Vertrauen in ein Produkt natürlich nicht. Deshalb wohl die - meiner Meinung nach überfällige - Entscheidung.

Suchmaschinenfreundliche URLs sind trotzdem wohl eine wichtige Voraussetzung, um von Google und Co. möglichst gut indiziert zu werden und somit viele neue Besucher anzulocken. Vor allem für neue Foren ist dies wichtig. Bekannte Foren haben meist einen höheren Pagerank, so dass auch dynamische Seiten bis zu einem bestimmten Level (abhängig vom Pagerank) indiziert werden. vbSEO zeigt, dass solche URLs auch einfach zu erreichen sein können. Ein gutes Beispiel für andere Foren.

Bei der Implementierung der Ajax-Funktion in das Bewertungssystem im Strohhalm kam ich auf die Idee, was man in einem Forum noch alles mit Ajax vereinfachen könnte. Dabei sollte die Funtion natürlich sinnvoll sein, also nicht nur “weil es geht”, sondern weil der Benutzer davon einen echten Mehrwert hätte.

So kam ich auf die Idee, für Administratoren die Möglichkeit zu bieten, die Forenbeschreibung direkt zu ändern. Ein Doppelklick auf die bestehende Foren-Beschreibung sollte dann die Beschreibung in ein Textarea umwandeln, das verlassen der Box sollte die Änderung dann sofort übernehmen - mittels Ajax.

Moderatoren könnte man das Leben vereinfachen, in dem man diesen die Möglichkeit bietet mittels einfachem Doppelklick einen Thread-Titel oder sogar einen User-Eintrag direkt zu ändern, ohne über das entsprechende Formular gehen zu müssen. Dieses würde natürlich weiterhin bestehen (Fallback), aber eine Vereinfachung dürfte das auf jeden Fall sein.

“Normale” Benutzer könnte man dagegen ein Formular am Ende eines Threads anbieten, das nicht direkt abgeschickt wird, sondern dessen Eintrag mittels Ajax direkt an den aktuellen Thread angehängt wird. Somit wäre auch kein Reload nötig. Das zusätzliche Einblenden von neuen Beiträgen ohne Reload halte ich dagegen für unnötig. Das würde bloß den Server mit zusätzlichen Anfragen belasten (”ist denn schon was neues da”) und würde den Mehraufwand meiner Meinung nach nicht rechtfertigen.