>> register_globals

Nun hat es sie also getroffen: Der Joomla-Server, Heimat des freien Content-Management-Systems, war heute morgen nur noch rudimentär sichtbar. Mit einem netten neuen Begrüßungsscreen hatten sich Script-Kiddies auf der Seite verewigt. Was zunächst nur als eine neue Inkarnation des digitalen Vandalismus schien hat allerdings einen schalen Beigeschmack: Vermutlich waren die Sicherheitseinstellungen unzureichend. …

Natürlich mal wieder Kinderkrams, möchte man meinen – aber die Gerüchte besagen, dass das Defacement der Seite zum einen durch die laxe Handhabung der PHP-Variable REGISTER_GLOBAL verursacht und zum zweiten durch das Fehlen eines Verzeichnisschutzes via .htaccess erst ermöglicht wurde.

Anfängerfehler beim freien CMS? Systemsicherheit Fehlanzeige? Das Team beschäftigt mit dem Grabenkrieg um die Wahl der OpenSource-Lizenz? Wie dem auch sei, es wirft kein gutes Licht auf Joomla, dass sich auf die Fahnen geschrieben hat, mit benutzerInnenfreundlichem Interface Content einfach zu managen.

Ohne Häme fragt sich die moderne Internautin, ob sie solch einem System ihre Daten anvertrauen möchte – oder wie ist das zu verstehen, wenn von dem aus Mambo entstandenen Projekt noch nicht einmal die Sicherheit des eigenen Servers zu gewährleisten ist? Wie mag es dann um diverse Funktionen des eigentlichen CMS bestellt sein?

Ohnehin befindet sich Joomla in Turbulenzen. Nicht nur, dass die lang erwartete Version 1.5, die mit vielen Sicherheitslücken aufräumen soll, nocht immer nicht das Beta-Stadium verlassen hat: Gleichzeitig toben Streitereien um die zukünftige Lizenz. Does open source really matter?

3 Thoughts.

  1. zum einen durch die laxe Handhabung der PHP-Variable REGISTER_GLOBAL verursacht und zum zweiten durch das Fehlen eines Verzeichnisschutzes via .htaccess erst ermöglicht wurde.

    Wie kann mann nur so dumm sein.

    Typisch PHPler. Aus Faulheit nicht in die php.ini schauen. Aua!
    In jeder php.ini steht drin:

    ; - register_globals = Off         [Security, Performance]
    ;     Global variables are no longer registered for input data (POST, GET, cookies,
    ;     environment and other server variables).  Instead of using $foo, you must use
    ;     you can use $_REQUEST["foo"] (includes any variable that arrives through the
    ;     request, namely, POST, GET and cookie variables), or use one of the specific
    ;     $_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or $_FILES["foo"], depending
    ;     on where the input originates.  Also, you can look at the
    ;     import_request_variables() function.
    ;     Note that register_globals is going to be depracated (i.e., turned off by
    ;     default) in the next version of PHP, because it often leads to security bugs.
    ;     Read http://php.net/manual/en/security.registerglobals.php for further
    ;     information.

    Das Wort Security kennt dort wohl niemand.

    Und fehlende .htacces? Setzen Note 6.

    Und das wohlgemerkt nicht auf irgendeiner Popelwebsite, sondern bei Joomla.
    Das erzeugt bei mir schon ein arges Schütteln der Schuppenpanzers und Schlagen des Schwanzes.

    Natürlich frage ich mich dann auch, was für arge Sicherheitslöcher bei deren Hosting vorhanden sind oder gar in der OpenSourcelösung Joomla.

    PS: Denen ist das so peinlich, dass noch nicht einmal ein Wort zum Defacement auf deren Website ist. 8-0

  2. Was es bedenklich macht;

    >> […] Joomla has got their own servers at Rochen. […]

    >> […] It isn't sure yet how joomla.org got hacked. They're
    >> it as we speak. It's most likely joomla.org was running
    >> 10.0.13 […]

    >> […] We are indeed running version 1.0.13 on joomla.org. […]

    (fünf Stunden später):

    >> […] Joomla Help Site hacked. […]

    >> […] These idiots (who call themselves "turkish crackers") have
    >> replaced the file "helpsites-15.xlm" at help.joomla.org.
    >> This file is downloaded whenever the help languages file is
    >> refreshed, which does not seem to always require a user
    >> intervention. The problem is that it can't be parsed, and
    >> the config menu becomes inaccessible after the file is
    >> replaced. This little hack may soon spread everywhere… […]

    >> […] found the hole at file permissions, i guess […]

    >> […] dev.joomla.org is suffering from the same problem,
    >> seems it's a different hacker though […]

    (noch später):

    >> I think the safest joomla site is forum.joomla.org
    >> because forums are SMF, not bridged to joomla, and
    >> this server only operates SMF forum

    Ein Armutszeugnis, das.

    Nachzulesen auf:
    http://forum.joomla.org/index.php/topic,203000.30.html
    http://forum.joomla.org/index.php/topic,203290.0.html
    http://forum.joomla.org/index.php/topic,203291.0.html

Deine Meinung?