Sicherheit ...

[Peter.Bickel]

Hallo Leute,

immer wieder liest man in Foren (z.B. im Typo3-Forum), dass Administratoren aus Angst vor Hackerabgriffen den Typo3-Copyright-Hinweis im Quellcode entfernen, damit man nicht erkennen kann, mit welchem CMS die Site läuft (was albern ist, denn den von Typo3 erzeugten Quellcode erkennt ein Fachmann leicht). Erfolgversprechender wäre da eher, das Admin-Verzeichnis umzubenennen, aber das geht bei neueren Typo3-Versionen auch nicht mehr (und bei Redaxo auch nicht, soviel ich weiß.)

Worauf ich nun hinaus will: Viele von uns entwickeln ja auch kommerzielle Websites für Unternehmen, für die ein erfolgreicher Hackerangriff ein schwerer wirtschaftlicher Schaden wäre (vom Imageschaden gar nicht zu sprechen). Und da drängen sich die Frage auf:
Wie sicher ist ein CMS im allgemeinen und Redaxo im besonderen?
Was kann man tun, um die Sicherheit ggf. zu verbessern (gute Passwörter vorausgesetzt)?
Musste sich jemand von Euch schon mal mit Eindringlingen auseinandersetzen?

Bin gespannt auf Eure Meinungen/Erfahrungen?

Viele Grüße,
Peter.

[nik]

Schade, dass sich niemand von den Entwicklern hier dazu äußert. Ich würde auch gern etwas darüber lesen.

1/ Die - anscheinend grundlegende - Verwendung von eval wirft da z.B. Fragen bei mir auf. Gerade bei der Verwendung fremdprogrammierter Module, Templates etc. ist das wohl Unsicherheitsfaktor No. 1

2/ bin ich durch Zufall auf diesen Thread gestoßen und habe mir daraufhin mal Datenbankescaping und Parametercasting angesehen. Beides finde ich einigermaßen fragwürdig:

• addslashes wird hier als Allheilmittel verwendet, aber eigentlich bietet es eine trügerische Sicherheit. Nicht umsonst verschwindet magic quotes aus den aktuellen PHP Versionen. Und hier wird es künstlich wieder eingebaut?
• wie auch im oben verlinkten Thread geschrieben: NEIN! Slash Escapes sind kein ausreichender Ersatz für mysql_real_escape_string! Deshalb standen mir hier auch die Haare zu Berge (live aus der 4.1 DB Klasse):

  // Da Werte via POST/GET schon mit magic_quotes escaped werden,
  // brauchen wir hier nicht mehr escapen

  Im Gegenteil! magic quotes etc. führen unter Umständen in Kombination mit mres zu negativen Seiteneffekten! Da kann ich nur das aus dem PHP Manual entgegenhalten:

  Note: If magic_quotes_gpc is enabled, first apply stripslashes() to the data. Using this function on data which has already been escaped will escape the data twice.
  
  Note: If this function is not used to escape data, the query is vulnerable to SQL Injection Attacks.

  Ich bezweifele stark, dass die meisten Modulprogrammierer daran denken.

• (!is_numeric($value))

  scheint mir auch ein Angriffsvektor im DB Escapeing. PHP erkennt bspw. x012 als einwandfreien (hex-)numerischen Wert. Hexadezimale in SQL werden aber kontextbezogen als String oder als INT ausgewertet. Zudem vertragen auch numerische Werte durchaus einen Delimiter in SQL. Die Methode solltet Ihr dringend umbauen.

Wäre schön, wenn dies mal eine kleine Diskussion anfachen könnte...

3/ Die Verwndung von register globals ist der nächste Knackpunkt.
Redaxo verwendet extract auf die gängigen Superglobalen, so dass quasi rg nachgebildet wird. Damit öffnet sich bspw. dieser Angriffsvektor (Bsp aus dem php Manual):

Code: Alles auswählen

<?php
if ($username) {  // kann vom User mit get/post/cookies übermittelt werden
    $good_login = 1;
}

if ($good_login == 1) { // kann vom User mit get/post/cookies übermittelt werden
    fpassthru ("/highly/sensitive/data/index.html");
}
?>

[nik]

4/ Fehlerunterdrückung. Fehler müssen abgefangen, am besten natürlich vermieden, und wenn alles nicht hilft: sauber verarbeitet und protokolliert werden. Ein @ spart jede Menge Ärger. Aber nur auf den ersten Blick. Daraus entstehende Folgefehler sind nicht absehbar.

1 Zusatz/ Zudem ist es nahezu unmöglich, PHP Templates zu debuggen, weil Fehlermeldungen immer nur auf den eval'd Code bezogen sind und immer obskure Zeilennummern anzeigen.

[Koala]

4/ Fehlerunterdrückung. Fehler müssen abgefangen, am besten natürlich vermieden, und wenn alles nicht hilft: sauber verarbeitet und protokolliert werden. Ein @ spart jede Menge Ärger. Aber nur auf den ersten Blick. Daraus entstehende Folgefehler sind nicht absehbar.

Wenn ich mich recht entsinne gibt es aber auch Funktionen die immer eine Fehlermeldung produzieren und die nicht abgefangen werden können.
Ich meine das war bei irgend einer Dateiverarbeitung (lesen/schreiben what ever) so gewesen ... kann aber grad nicht weiter nachschauen.
Ein Beispiel von dem auf was du dich beziehst wäre evtl. hilfreich.

[Markus.Staab]

Hi zusammen,

ihr werdet niemals einen Entwickler finden, der von seinem Programm sagt, dass es schlecht ist, oder dass es Sicherheitslücken enthält,..

Daher ist diese Frage natürlich niemals befriedigend für euch zu beantworten.
Uns sind keine Sicherheitslücken bekannt und daher sehen wir keinen Handlungsbedarf.

Falls welche bekannte werden, sind wir natürlich bestrebt diese in kürze zu beheben..

@nik:
Bitte setze dich erstmal mit dem System selbst auseinander, bevor du irgendwelche mini-details kritisierst. Vieles davon hat seinen Sinn und ist von uns so gewollt..

Grüße, Markus

[nik]

Bitte setze dich erstmal mit dem System selbst auseinander, bevor du irgendwelche mini-details kritisierst. Vieles davon hat seinen Sinn und ist von uns so gewollt..

Hmm, also meine Kritik ist ja eben, dass Ihr die Dinge bewußt umsetzt. Also bspw. magic quotes oder register globals. Und das sind keine Minidetails, das sind sogar ganz entscheidend! Das kann ich aus eigener Erfahrung aus dem PHP Forum sagen, wo wir seit Jahren versuchen, die Leute von den ganze globals Beispielen aus veralteten PHP Lehrbüchern wegzubekommen.

Oben habe ich bereits einen Angriffsvektor dargestellt, der bei Einsteigern sehr oft vorkommt und erst durch register globals oder vergleichbare Mechanismen möglich wird.

Es geht auch nicht zwingend um Sicherheit alleine. Bspw. dürfte den wenigsten klar sein, dass der nachfolgende Code aus Redaxo die automatisch importierten Parameter aus der URL oder einem Formular mit gleichnamigen Session Daten überschreibt.

Code: Alles auswählen

if (!ini_get('register_globals'))
{
        // register_globals = off;
        ...
        if (isset($_GET) and $_GET) extract($_GET);
        if (isset($_POST) and $_POST) extract($_POST);
        ...
        if (isset($_SESSION) and $_SESSION) extract($_SESSION);
}

Für Spracheinsteiger ärgerlich im Quadrat!

Dass die addslashes unter bestimmten Bedingungen mysql_real_escape_string unterläuft kann man auch als Sicherheitslücke einstufen.

Mein Hauptkritikpunkt aber bleibt, dass man $_POST & Co nicht mal verwenden kann, ohne vorher wieder stripslashes drüberlaufen zu lassen. Dafür hätten doch rex_get und Co ausgereicht.

@Koala: Ja, bspw. fopen auf nicht lesbare Ressourcen. Allerdings kann man solche Fälle mit Exceptions abfangen.

Beispiel. Naja, das eben:

Code: Alles auswählen

foreach(OOAddon::getAvailableAddons() as $addonName)
{
  // Warnungen unterdrücken ist schneller als ein file_exists
  @include $REX['INCLUDE_PATH'].'/addons/'.$addonName.'/config.inc.php';
}

[Markus.Staab]

Hi,

ein paar deiner Anregungen hab ich jetzt mal umgesetzt..
Allerdings sind auch ein paar Sachen dabei die man nicht von jetzt auf gleich machen kann, da sonst die Rückwärtskompatibilität nicht mehr gewährleistet ist bzw addons/templates/module nicht mehr funktionieren würden..

Viele Grüße,
Markus

[nik]

Cool, super. Wenn ich mal etwas mehr Zeit habe schaue ich mal ins Repository.