WordPress 2.8.3: Das Doppelslash-Problem
04.08.2009 in: PHP, Sicherheit, Suchmaschinen, Webdesign und WordPress • 11 Kommentare
Letzte Änderung: 01.10.2010, 18:49 Uhr.
WordPress hat inzwischen eine Komplexität erreicht, die locker an die vieler Content-Management-Systeme heranreicht. Nur so konnten die komfortablen Schnittstellen für Plugins, Widgets und Themes realisiert werden.
Der Preis besteht aus mehr Fehlern. Das ist unvermeidlich, und es erstaunt auch niemanden, der selbst schon einmal programmiert hat.
WordPress 2.8.3 stopft eine Sicherheitslücke, die seit Freitag bekannt ist: Einfache registrierte Nutzer konnten durch leicht geänderte URLs administrative Rechte ausüben.
Ich hatte zwar schnell eine Fix parat, aber das Team von WordPress Deutschland (WPD) hat mich gebeten, ihn nicht zu publizieren, weil man daraus die Lücke ableiten konnte.
Dieses Verfahren, Problem und Lösung geheimzuhalten, heißt Security by Obscurity. Ich mag es nicht.
Aber bitte … ich kann mein Geltungsbedürfnis gut genug im Zaum halten, um hier nachzugeben.
Dennoch stört mich das Prozedere. Ein Cracker hätte sich die unzensierte Fassung des ersten Reporters leicht aus dem Google-Cache holen können. Und der Administrator eines WordPress-Blogs? Der mußte diesen praktisch unzumutbaren Rat schlucken:
Bis es einen Bugfix für das Problem gibt, raten wir dringend die Benutzerregistrierung zu deaktivieren und ggf. alle (unbekannten) registrierten Benutzer zu löschen, sofern dies vertretbar ist.
Ich habe bei Twitter meinen Bugfix angeboten, und darauf haben sich einige Leute gemeldet – mit Webseiten, deren ganze Funktionsweise vom Engagement registrierter Benutzer abhing. Da sie nicht wußten, wie schnell die nächste Version kommen würde, waren sie verständlicherweise wenig begeistert.
Ich habe mich damit nicht wohl gefühlt, weil ich indirekt auch ein Akteur dieser … Geheimniskrämerei geworden bin.
Wer ein WordPress-Blog verwaltet und nicht die Zeit hat, jeden Tag ins Forum oder ins Blog zu sehen – der hat doch sicher den Feed des WPD-Blogs abonniert. Darüber hätte man leicht die Reparatur verbreiten können – oder sollen.
Ach ja, dieser Schnipsel kommt in die functions.php des Themes:
new Single_Slash;
class Single_Slash
{
function Single_Slash() // PHP 4. Wer das noch erleidet...
{
if ( !strstr($_SERVER['REQUEST_URI'], '//') )
{
return;
}
header('Location: '
. ( empty ( $_SERVER['HTTPS'] ) ? 'http' : 'https' )
. '://'. $_SERVER['HTTP_HOST']
. preg_replace('~/+~', '/', $_SERVER['REQUEST_URI']), TRUE, 301);
die();
}
}
Download als WordPress-Plugin.
Das ist alles. Wenn man einen Doppelslash eingibt, wird man auf eine URL umgeleitet, die eine Kette beliebig vieler Slashes durch genau einen ersetzt.
In WordPress 2.8.3 lenkt einen das Backend jetzt zum Login, wenn man so eine URL eingibt.
Im Frontend bleibt der Mehrfachslash stehen. Probiert es im eigenen Blog: Verdoppelt in einer URL einen Slash, und staunt über die neue URL dieser Seite. Dem Gebot kanonischer Adressen entspricht das nicht gerade.
Wie relevant ist das? Ein Beispiel: Ihr habt ein Blog, das jemand gerne aus seiner guten Position bei Google verdrängen möchte. Er bastelt sich ein Netz kostenloser Weblogs und verfaßt Beiträge, die auf die »alternativen« Adressen der Seiten zeigen, die bei euch am höchsten bewertet werden. Dann wartet er, bis Google erst seine Beiträge indiziert und dann eure »neuen« Seiten. Plötzlich habt ihr eine Menge doppelten Inhalt. Lustig, oder?
Ein kleiner Test im Serendipity-Blog zeigt übrigens, daß nicht nur WordPress daran krankt. ☻
Dem kann man zwar mit der Angabe der kanonischen URL im Markup begegnen, aber das kommt eigentlich zu spät: Ein menschlicher Besucher erfährt davon nichts; er wird eventuell die falsche URL in seinen Lesezeichen verwenden, oder in Links zu eurer Seite. Adressierungsprobleme sollten nicht im Markup gelöst werden, sondern auf der Protokollebene, in HTTP also.
Deshalb bleibt dieser Schnipsel in meinem Theme.
Noch ein Bugfix hat es in dieses Release geschafft, über den sich bestimmt jeder freut: Die URL eines Kommentators verschwindet jetzt nicht mehr, wenn man dessen Text bearbeitet.
Dafür müssen noch 48 Bugs, deren Reparatur für diese Version geplant war, auf die nächste warten. So sei es.
Zieht das Update. Es läuft problemlos (zumindest wenn man es per FTP durchführt) und ist auch schon auf Deutsch zu haben.
Immerhin wurde das Loch gestopft, wenngleich der Bug noch zuckt.
Update 04.08.09
Markus Wulftange hat eine Lösung gefunden, die per .htaccess und mod_rewrite funktioniert:
RewriteEngine On
RewriteBase /
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /(([^/\ ]+/)*)/+([^\ ]*)
RewriteRule ^ /%1%3 [L,R=301]
Das ist deutlich besser als meine PHP-Variante.
Mehr Lektüre zum Thema
- .htaccess: Angriffe sehen und blockieren
- Ungebetene Gäste mit .htaccess blocken
- Website gehackt – und nun?
In jedem Projekt wird die Behandlung von Lücken normalerweise closed behandelt, bis der Fix bereit steht, das ist bei Routerherstellern, DNS Server Software und vielen anderen üblich. Cracker, die einbrechen wollen, brauchen das WPD Forum nicht dazu.
Allerdings gibt es eine Menge Script-Kids, die es cool finden, anderer Leute Blogs abzuschießen, das sollte verhindert werden.
Und die Reichweite einer Meldung WPD an einem Wochenende mit Sonnenschein und super Wetter ist durchaus sehr begrenzt. Das der Fix nicht lange brauchen kann, war bei der Schwere der Fehlers abzusehen.
Und man sollte nicht vergessen, das dies nicht nur 2.8er Versionen betrifft sondern auch die Vorgänger und schon gar nicht nur deutsche Blogs.
Wenn dir daran gelegen wäre, einen temporären Patch öffentlich zu promoten, dann hätte sicher eine Anfrage per Mail an das WPD Team gereicht und man hätte das abstimmen und abklären können. Die Herangehensweise nach dem Motto "Herr Lehrer, ich weis was..." mit anschließender Publizierung ist in der Tat pures Geltungsbedürfnis, Sensationshascherei und auf Schadensmaximierung ausgelegt, sorry.
@codestyling: Wie geschrieben: Ich habe auf den öffentlichen Patch gewartet. Und ich habe auch mit Oliver Baumann in Mailkontakt gestanden. Aber ich muß mich nicht rechtfertigen; ich habe ja extra gewartet, bis die Lücke offiziell geschlossen wurde …
Worauf ich hier hinaus will: Der Fix ist nicht abstrakt genug, und das Problem der Mehrfachslashes besteht nicht nur in WordPress. Wer das ausspricht ist doch gleichgültig. Ich würde nur gerne wissen, ob nur ich das als Problem empfinde, oder ob sich ein neuer Bugreport dafür lohnt.
@Thomas
dein Beitrag über den für Suchmaschinen als mehrfach vermuteter Inhalt bei zu vielen Slashes in URLs hat mich dazu inspiriert, auch für Blosxom ein ähnliches Plugin zu schreiben. Das Blog krankt nämlich auch an „mehrfachen Slashes“.
Ich bin nur früher nie auf die Idee gekommen, dass jemand solche URLs eingibt oder gar woanders aus gemeiner Absicht postet.
@GwenDragon: So häufig wird das Verlinken »doppelslashiger« URLs auch nicht vorkommen, sonst wäre das schon ein sehr bekanntes Problem. Aber ich rechne immer mit dem Schlimmsten …
Bevorzuge auf jeden Fall die Variante in der .htaccess (die hattest du vielleicht noch nicht im Feed). Die ist schneller und greift auch bei URLs, die nicht per Script erfaßt werden.
Merkwürdiges Aufeinandertreffen: Du hast ein sehr ähnliches Thema ja heute auch im Blog angeschnitten. Ich verzichte jetzt lieber auf den Kalauer, das sei ein SommURLochthema. ☻
@Thomas
Ganz herzlichen Dank für Deine Lösungen zu Problemen mit Mehrfachslashes // in der URL.
Meinen Blogbeitrag "Kritische Sicherheitslücke in WordPress" habe ich eben entsprechend ergänzt.
Ich habe bzw. werde sowohl Deine PHP-Lösung für WordPress als auch die .htaccess verwenden.
Wenn ich das richtig sehe, scheint das ja ohne Probleme möglich zu sein.
Falls ich - wider Erwarten - problematische Nebenwirkungen feststellen sollte, werde ich Dir hierüber berichten.
@Dieter: Wenn mod_rewrite funktioniert, dann brauchst du den PHP-Code nicht. Vollkommen überflüssig.
Wozu spiegelst du den Code?
@Thomas
Vielleicht mache ich ja was falsch, aber die Ergänzung der .htaccess alleine beseitigte bei mir nicht den doppelten Slash im Frontend von WordPress.
Ob da etwas in der .htaccess wie die 4G BLACKLIST Schuld daran sein könnte?
Werde mal kurz ohne die anderen .htaccess-Angaben testen.
@Thomas
Weiß als Laie zwar nicht warum, aber wenn ich die Ergänzung der .htaccess von Markus Wulftange aka Gumbo vor die 4G BLACKLIST setze, klappt es. Lustig. Hast Du eine Erklärung dafür?
Damit kann ich in der Tat Deinen PHP-Code in der funcions.php wieder entfernen.
@Dieter: Das wird an diesem Eintrag liegen:
Der greift früher. Die 4G-Blacklist arbeitet, wie der Name schon andeutet, mehr mit Verboten als mit Korrekturen. Wenn du nicht jede einzelne Zeile genau verstehst, dann setze sie nicht ein. Das gilt für jeden Code auf deiner Website.
@Thomas
Das Auskommentieren dieser Zeile hatte ich vorher getestet und schien nicht zu helfen. Ist aber weiterhin auskommentiert. Vielleicht war das auch durch einen Cache verursacht.
Deine Forderung, jede Zeile Code genau zu verstehen, wenn man sie einsetzt, lasse ich für Programmierer gelten, die damit Geld verdienen. ;-)
Diese Forderung zu Ende gedacht, dürften ich und viele andere Nichtprofis keine Webseiten und Code ins Netz stellen. Das sehe ich anders. Mit der Selbstbeschränkung auf vertrauenswürdige Quellen lassen sich die Risiken auf ein für mich vertretbares Niveau reduzieren. Diese Entscheidung muss jeder für sich selbst treffen.
Da vergeht ein Monat, bis ich Deinen Artikel hier lese. Ich habe auch dieses Doppelslash-Problem und wurde schon ganz nervös. Ich habe in den einzelnen Dateien gesucht und habe es letztendlich stehen lassen. Nun werde ich dies ändern. Danke für Deinen Artikel, hatte schon an mir gezweifelt.