Für nicht zu umfangreiche WebSites benutze ich gerne das CMS Website Baker, da das Backend auch von Usern bedient werden kann, durch deren Adern keine Bits & Bytes fließen. ;O)

Einen Haken hat Website Baker: Wenn ein Menü verschachtelt ist, mit Sub- und SubSubMenüs, dann ist die eingebaute Funktion show_menu relativ unbrauchbar und das Modul show_menu2, welches man nachinstallieren kann, taugt leider auch nicht viel. Die Doku zu show_menu2 ist grottig und die Beispiele zeigen nicht das was ich haben möchte.

Mit der eingebauten show_menu-Funktion sieht ein Menü z.B. so aus:

Da diese Darstellung sehr unbefriedigend ist und immer nur der gerade aktive Menüpunkt hervorgehoben wird, habe ich an einer Systemdatei des CMS etwas rumgefingert und dann sieht das gleiche Menü folgendermaßen aus:

In die class.frontend.php von Website Baker 2.6.7 habe ich ab Zeile 367 (V 2.7: Zeile 381) folgendes eingefügt:

if (ROOT_PARENT==$page['page_id'] and $class==' class="menu_default"') {
$class = str_replace('menu_default"', 'menu_default level0"', $class);
} elseif (PARENT==$page['page_id'] and $class==' class="menu_default"') {
$class = str_replace('menu_default"', 'menu_default level1"', $class);
} elseif (LEVEL==0 and $class==' class="menu_current"') {
$class = str_replace('menu_current"', 'menu_current level0"', $class);
}

Und das CSS dazu enthält folgendes:

#menue { font-size: 0.8em; line-height: 25px;}
#menue ul { margin: 0; padding: 0; }
#menue ul li { list-style: none; display: inline; margin: 0; padding: 0;}
#menue ul li a { color: #222222; text-decoration: none; display: block; padding-left: 5px; background-image: url(../img/menu-bg.jpg); border-bottom: 1px solid #aeaeae; }
#menue ul li a:hover {background-color: #cccccc; }
#menue ul li a.menu_current { background-color: #cccccc; color: #000000; }
#menue ul ul li a {padding-left: 20px; background: #ebebeb; }
#menue ul ul ul li a { padding-left: 35px; }
#menue ul ul ul ul li a { padding-left: 45px; }
#menue ul li a.level0 { background-image: url(../img/menu-activ-bg.jpg); color: #FFF;}
#menue ul li a.level1 { background-color: #ebebeb; color: #066a38;}

Vielleicht bin ich auch nur zu dumm, um das Modul show_menu2 richtig zu benutzen, aber nach mehreren Stunden tüfteln, Googlesuche und Doku lesen, war es für mich sehr viel einfacher (und schneller) etwas am Website Baker Quellcode abzuändern, was nun genau das macht was ich will. Bei solchen Aktionen lernt man auch etwas über das Innenleben einer Open Source Software. :O)

Die Berichte über die Probleme mit den Supportforen haben hoffentlich auch die WP-Entwickler erreicht.

Das Problem von normalen/einfachen/ungesalzener MD5-Hashes sind die Rainbow Tables, also vorausberechnete Hashwerte. Wenn man als Passwort zum Beispiel “password” benutzt, so wird immer der gleiche MD5-Hash erzeugt:

md5(password) => 5f4dcc3b5aa765d61d8327deb882cf99

Google kennt z.Zt. 4630 Ergebnisse für diesen Hash und wenn man die Suche weiter einschränkt findet man auch SQL-Dumps, in denen dieser Hash vorkommt. Mit anderen Worten: Auch hier hilft Google dem Hacker und das zu geringe Sicherheitsbewußtsein der Softwareentwickler verstärkt das Problem enorm.

Fast jede Software benutzt MD5 zum Erzeugen von Hashwerten, WordPress ebenfalls. Im Quellcode von WP kommt zwar auch

»md5($data . $salt)« oder auch »md5( md5($password) )«

vor, aber der Passworthash in der wp_users ist nur ein einfacher MD5-Hash. Das heißt wer die Datenbank auslesen kann hat die Hashwerte für die Passworte der User. Da viele User immer wieder die gleichen Passworte benutzen… das Passwortproblem und User hatte ich bereits hier und hier erwähnt.

Der unberechtigte Zugriff auf die Datenbank kann durch verschiedene Probleme möglich sein. Ein Fehler in der Software selber, also z.B. per SQL-Injection das Adminpasswort überschreiben. Ist der Passworthash ein einfacher MD5-Hash so kann der Hacker ohne Probleme den Hash ersetzen, um Zugriff auf die Software zu erlangen. Der Hoster hat einen Fehler gemacht und plötzlich sind alle phpMyAdmins offen. Oder das Datenbanktool phpMyAdmin hat einen Bug, oder… oder… oder…

Also im WP-Quellcode gibt es 22 Dateien in denen md5() benutzt wird. Ich habe mal alle Vorkommen mit selfmd5() ersetzt und in der wp-config.php meine eigene MD5-Funktion eingefügt, da ich davon ausgehe das alle Dateien die auf die Datenbank zugreifen erst die Konfiguration, mit dem DB-Passwort, laden.

function selfmd5($klartext) {

$zurueckgeben = md5($klartext."test");

return $zurueckgeben;

}

Ich habe ersteinmal vor der Installation von WordPress die geänderten Dateien ausgetauscht. Die Installation war erfolgreich, ich konnte Beiträge schreiben, kommentieren, editieren, löschen, neue User anlegen, etc. etc. Dann habe ich in einem bereits installierten WordPress alle Dateien ausgetauscht und in der Datenbank den Passwort-Hash des Users auf den neuen Hash aktualisiert, wieder lief alles Problemlos.

Es wäre natürlich sehr viel besser wenn die WP-Entwickler eine eigene MD5-Funktion in den Quellcode einfügen und nicht das einfache MD5 verwenden würden, denn nach jedem WP-Update muß ich wieder alle Dateien auf meine MD5-Funktion umstellen.

Also, meine Bitte an die WP-Entwickler: Baut mal eine gesalzene MD5-Funktion in WordPress ein, dies erhöht die Sicherheit von WordPress enorm.