Sicherheitslücken in unserem CMS

  • Sicherheitslücken in unserem CMS

    Hallo,

    ein Kumpel und ich basteln gerade an einem CMS. Da er mit dem Programmieren weiter war als ich, haben wir sein CMS genommen und bauen es gerade auf. Nun wurde sein CMS vor unseren Augen schritt für Schritt gehackt und inhalte der Webseite gelöscht. Er hat das CMS zum Download angeboten. Nunja, es gibt nunmal auch "böse" Menschen.

    Die Motivation am Projekt hat nun etwas Anteil verloren. Wenn wir nicht alle Sicherheitslücken erstmal geschlossen haben, werden wir das Projekt nicht releasen.

    Nun frage ich euch Experten.
    Welches sind die Bekanntesten Sicherheitslücken, und wie könnte man diese am besten fixen?

    Wir beide sind leider noch php Anfänger
    Hier ist das gehackte (nicht modifizierte Version unseres) CMS.
    cmsiroxport.rar ... at uploaded.to - Free File Hosting, Free Image Hosting, Free Music Hosting, Free Video Hosting, ...

    Ich habe etwas gegoogelt und das hier gefunden.
    SQL-Injection – Wikipedia
    Dies haben wir, zumindestens glauben wir mit intval() gefixt.

    Freuen uns auf jeden Tipp, wie man die Sicherheitslücken reproduzieren könnte.

  • Also SQL-Injection gehört wirklich zu den Standard-Angiffsmaßnahmen. Dementsprechend gibt es auch viel Doku. So findet man mit Google und den Suchbegriffen "PHP SQL-Injection" gleich als erstes den Wikipedia-Eintrag mit den Gegenmaßnahmen (hast du ja auch gefunden):
    de.wikipedia.org/wiki/SQL-Injection#PHP
    (PHP Data Objects sollte man allem Andren vorziehen, da sie genau dafür gedacht sind.)

    Hier kann man bei der TU-Chemnitz (speziell für PHP) Infos erhalten, um weitere Sicherheitslücken zu schließen.
    tu-chemnitz.de/urz/www/php/secure.html
    Wenn bei euch SQL-Injection funktioniert, werden sicherlich auch andere Sicherheitslücken existieren. Deswegen solltet ihr den Artikel GRÜNDLICH durchlesen.

  • Bestimmt findest du hier auch ein paar Anregungen: Präsentation zum Thema "Hacking"

    Ich habe mir eigentlich nur eine einzige Datei angeschaut...
    acp/nachrichten.php

    1. Ihr habt keine Login Abfrage. Jeder kann also alles aufrufen, wenn er die Dateinamen kennt.
    2. Die Variablen werden nicht escapet

    Quellcode

    1. $n_seite = $_GET['delete'];
    2. $loeschen = "DELETE FROM icms_nachrichten WHERE Bid = '".$n_seite."'";

  • Zumal bei eben diesem Quellcodeausschnitt wieder SQL-Injection möglich ist.
    Stell dir vor $n_seite hat den Wert:
    mirdochegal'; DROP TABLE icms_nachrichten; SELECT * FROM icms_nachrichten WHERE Bid = 'mirimmernochegal


    In diesem Fall hat der Angreifer sogar noch eine Rückmeldung ob sein Vorhaben geklappt hat, da in diesem Fall das SELECT-Statement fehlschlagen würde.

    Das ausspähen ob SQL-Injection möglich ist, ist übrigens sehr leicht. Einfach ein einzelnes ' übermitteln oder das Statement sonst irgendwie zum fehlschlagen bringen. Mit etwas Glück wird einem das komplette Statement in der Fehlermeldung angezeigt. Nun kann man es nach Wünschen verändern.

    Du bist im Übrigen auch bei POST-Variablen nicht davor gefeit. Ob POST oder GET, das ist dem Hacker völlig Schnuppe. Man kann bei jedem beliebigen Formular jeden übertragenen Wert (auch hidden fields) beliebig verändern. Das geht z.B. schon mit Tamper Data und das ist nicht mal ein Hacking-Tool sondern nur eine Firefox-Plugin für die Webentwicklung.

  • Naja, es macht keinen Sinn mehr Beispiele zu nennen. Die genannten Probleme gibt es fast in jeder Datei. Auch in Login und Co.

    Das kritischste Problem ist wohl, dass man durch direkten Aufruf der Dateien den Login umgehen kann.
    Alles datenbanktechnische solltest du auf das erwähnt PDO umstellen.
    Und Passwörter solltest du verschlüsselt speichern.

  • Eine Überlegung wäre es, den neuen Code nicht zu veröffentlichen.

    Du klingst ziemlich sicher, aber wenn ich mir die großen Foren und CMSysteme anschaue und da sehe, was für Lücken immer wieder gefunden werden, dann würde ich es mir dreimal überlegen, ob du es veröffentlichen solltest.
    Das ist definitv die größte Gefahr.

  • vince schrieb:

    Eine Überlegung wäre es, den neuen Code nicht zu veröffentlichen.

    Du klingst ziemlich sicher, aber wenn ich mir die großen Foren und CMSysteme anschaue und da sehe, was für Lücken immer wieder gefunden werden, dann würde ich es mir dreimal überlegen, ob du es veröffentlichen solltest.
    Das ist definitv die größte Gefahr.


    Jep, das sehe ich auch genau so.
    Ich mache mir die mühe und bring ein kleines CMS raus, und andere haben den Spaß dran es zu hacken -.-
    Ich werde meine PHP-Kenntnisse nun so erweitern, das ich ein CMS schreiben kann, was ich dann verkaufen könnte.

    ----------------------------------------------------------------------

    Würdet Ihr eingaben, wie zb. ein Kontaktformular (Name, Alter usw.) oder bei einen Bestellformular eher mit htmlspecialchars, htmlentities oder strip_tags filtern?
    Ich habe es nun mit htmlspecialchars gemacht.

    ----------------------------------------------------------------------

    Mit freundlichen Grüßen
    Jens Prangenberg

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von xe0n ()