“WordPress: Eine Studie in Scharlachrot” (computec.ch)
Marc Ruef hat sich den Quellcode von WordPress angeschaut, meint dieser wäre schon vom Ansatz her nicht sehr sicher und die von ihm genannte Stelle würde in Zukunft zu Problemen führen.

Es geht um die wp-login.php und die Zeile 188:
$key = preg_replace('/[^a-z0-9]/i', '', $key);

Was macht denn nun diese eine Zeile PHP? Eigentlich nicht viel, sie wandelt nur alle Zeichen die nicht Buchstaben (a-z) oder Ziffern (0-9) sind in das Zeichen zwischen den Hochkommas '' um, löscht sie also. Ja, das war schon alles. Diese eine Zeile Code macht nun WordPress nicht unsicher, zeigt aber, wie Herr Ruef es nennt, eine “Art der defensiven Programmierung”.

Da $key (laut Ruef) nur ein MD5-Hash sein darf,

• Buchstaben von a bis f
• Ziffern von 0 bis 9
• Länge: 32 Zeichen

ist ganz klar festgelegt, was vom Script verarbeitet werden darf und was sofort als Fehlfunktion bzw. Angriff eines Hackers gewertet und abgebrochen werden muss.

Hätten sich die WP-Entwickler ähnliche Gedanken über die Sicherheit gemacht wie Herr Ruef, so würden alle Prüfungen die nach der Zeile 188 vorgenommen werden, auch wenn es kein MD5-Hash ist, nicht ausgeführt – die weitere Verarbeitung würde mit einer Fehlermeldung abgebrochen werden – aber dem ist leider nicht so.

Genau solche vermeintlichen Kleinigkeiten, führen in der Summe eines Projektes (WP hat 276 PHP-Dateien), im Zusammenspiel unzähliger Scripte, sehr schnell zu Fehlern, die dann eben doch kritisch sein können.


Ich habe es ja auch immer wieder mit Entwicklern zutun, die eher darauf schauen das ihr Code schnell ausgeführt wird und möglichst wenig Zeilen verbraucht (sic!). Sie wollen oft nicht einsehen, dass es immer besser ist, sich den Code auch von der Seite des Hackers her anzuschauen und zum Beispiel alle Benutzereingaben abzufangen und auszuschließen, die nicht benötigt werden.


Warum muss z.B. ein Feld für deutsche Postleitzahlen mehr als 5 Ziffern aufnehmen, Buchstaben und Sonderzeichen erlauben und in der Datenbank 255 Zeichen speichern können? Damit sich der Entwickler keine Arbeit machen muss, wenn ein nicht-Deutscher sich verlaufen hat. ;O)

Bisschen ergoogelt (ext:sql dump blz|plz):

`plz` varchar(64)
…
`PLZ` int(11)
…
`plz` decimal(10,0)
…
`plz` varchar(255)
…
`blz` text
…
`blz` varchar(64)

Passend zu mehr Sicherheit in WP dies:
“Mehr Sicherheit für WordPress 2.8.5” (entwickler.de)

Da soll der Admin in Zukunft nur noch bestimmte Datei-Typen in die Mediathek hochladen können und ein gehackter Admin-Account von WordPress wird damit sicherer?!

entwickler.de bezieht die Info von Robert Wetzlmayr:
“Neu in WordPress 2.8.5: Sichere Mediathek” (talkpress.de)

Und auch der offizielle deutsche WordPress-Blog schreibt:
“Neue Sicherheitsbestimmung für die Mediathek in 2.8.5” (blog.wordpress-deutschland.org)

Was hindert den Hacker daran, der nun Admin ist, ein Plugin zu installieren, mit dem er die MIME-Typen der Whitelist wieder aufbohrt? Und was hindert ihn daran, einfach im Theme eine Datei zu editieren, um dort eine R57-Shell einzufügen?

Ich kann nur hoffen das die WP-Entwickler diese Änderung nicht wirklich als Beitrag zu mehr Sicherheit in WordPress einstufen.