Sicherheitslücken, wie schliessen?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Sicherheitslücken, wie schliessen?

    Hi Forum, ich mal wieder...

    Bin heute mal auf ein Tool gestoßen, das die Sicherheit von Webaplikationen prüft.
    Es nennt sich grendel scan. ( heise.de/security/tools/default.shtml?prg=117&l_sw=&l_aw= )

    Habe einen kompletten Check auf alle möglichen fehler durchlaufen lassen. Hatte anfangs 3 , als "high" eingestufe, Sicherheitslücken. Eine davon war XSS die ich mittlerweile gestopft habe.

    Meine seite besteht im Prinzip nur aus einer Index mit Login. Nach dem Login gibt es ein paar infos und 3 verschiedene Formulare, die Inhalte nachladen. Vor SQL-Injection bin ich sicher.

    zurück zum Thema, ich postet mal die restlichen zwei "high" Sicherheitslücken:

    Potential CSRF detected
    Severity: High
    URL: See description
    Description: One or more cross-site request forgery (CSRF) vulnerabilities may have been identified. CSRF allows an attacker to force a user to execute arbitrary commands against the vulnerable website. This is possible when the structure of the command is predictable. If the command can be requested as a GET, then a simple IMG tag on an attack website can force the browser to send the command. A POST request can be sent using some simple JavaScript. The browser will send any cookies or authentication credentials associated with the targeted attack, because it has no way of knowing that the request was not intentionally executed by the user.

    A list of queries that appear to be vulnerable to CSRF is below. A specific form may be found on multiple pages, but was only tested once.

    Action: localhost:80/inc/validateLogin.inc.php
    Parameter names: "username", "passwort", and "login"
    Original transaction: 53


    und 2.


    Authentication bypass detected
    Severity: High
    URL: localhost/test/ and others

    Description: An authentication bypass vulnerability may have been detected. Some authenticated requests were successfully executed without providing a session ID. The table below contains the relevant transactions:
    Original Transaction Unauthenticated transaction
    61 262
    146 566
    217 658
    53 186
    159 593
    168 533
    238 676
    133 606

    Impact: If the data presented to authenticated users is sensitive, it could be disclosed to an attacker.


    Ok die erste Lücke ist CSRF. Dazu hab ich mich schon schlau gemacht, habe aber nirgends Lösungsansätze zur behebung des Sicherheitsmangels gefunden. Da ollte ich fragen, kenn einer ne Seite (am besten auf deutsch, english geht aber auch), die das Thema ausführlich behandelt und auch Lösungsvorschläge beinhaltet?


    Ok zum 2. Fehler. Aus dem werd ich nicht ganz schlau. Das meine Sessions unsicher sind, das kann ich daraus lesen. Da ich mit Sessions leider weniger vertraut bin, kann ich nicht recht nachvollziehen warum. Vielleicht könnt ihr mir da helfen.

    Ich habe ein Login-Script geschrieben, namens "validatelogin.inc.php". Das setzt gaaanz am anfang $_SESSION['loggedIn'] = false;. Anschließend wird überprüft, sind alle eingaben gemacht. Sind alle Felder ausgefüllt, tu ich mit

    Quellcode

    1. $_POST['username'] = mysql_real_escape_string($_POST['username']);
    2. $_POST['passwort'] = mysql_real_escape_string($_POST['passwort']);
    4. $_POST['passwort'] = htmlspecialchars($_POST['passwort']);
    5. $_POST['username'] = htmlspecialchars($_POST['username']);

    hoffentlich möglichen Injections und XSS den gar ausmachen.
    Danach folgt die überprüfung der Daten aus der DB.
    Ist das ergebnis ungleich 1, kein Login. Ansonsten -> $_SESSION['loggedIn'] = true;
    Danach per header die weiterleitung zur ersten Internen seite.

    Diese macht zualler erst

    Quellcode

    1. include_once 'inc\checkLogin.inc.php';


    In der checkLogin.inc.php steht folgender Code:

    Quellcode

    1. /* Die Datei checkLogin.inc.php überprüft lediglich, ob die Variable loggedIn auf true gesetzt ist */
    2. session_start();
    4. //hier die gültigkeitsdauer angeben
    5. $dauer = 60*120;
    7. //session gültigkeitsdauer überschreitung prüfen
    8. if(!isset($_SESSION['timestamp']))
    9. {
    10. $_SESSION['timestamp'] = time();
    11. }else
    12. {
    13. if($_SESSION['timestamp']<(time()-$dauer))
    14. {
    15. session_destroy();
    16. }else
    17. {
    18. }
    19. }
    21. if( (!$_SESSION['loggedIn']) OR ($_SESSION['loggedIn'] != "true") )
    22. {
    23. header( 'Location: index.html' );
    24. exit();
    25. }
    Alles anzeigen


    Überprüft also lediglich ob $_SESSION['loggedIn'] auf true steht und ob die Session abgelaufen ist. Mehr mache ich nicht bezüglich der Sessions. Auf allen anderen Seiten wird dann auch immer zuerst die checklogin inclued.
    Wo liegt hier der Sicherheitsmangel?

    Möchte die Seite echt nich uppen, bevor ich die zwei Mängel beseitigt habe.

    vielen Dank schonmal!!

    edit:
    Natürlich ahbe ich auch eine Manuelle Logout funktion die folgendermaßen aussieht:

    Quellcode

    1. session_start();
    2. $_SESSION['loggedIn'] = false;
    3. session_unset();
    4. session_destroy();
    6. header( 'Location: index.html' );
    7. exit();


    grüße
    Timo
    ----[Blockierte Grafik: http://www.smilie-harvester.de/smilies/Alltag/putzen.gif] Nein ich bin nicht die Signatur, ich Putz hier nur ---

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

  • Hallo Timo,

    das was du da schreibst ist hoch interessant :) Ich bin zwar nicht so der Geek auf dem gebiet, aber ich versuchs mal. Bei der CSRF geschichte verweise ich dich mal ganz frech ins Wiki :) [wikipedia]http://de.wikipedia.org/wiki/Cross-Site_Request_Forgery[/wikipedia], da steht auch drinne wodurch das passieren kann und wie man es verhindert (ganz grob).

    Bei der Bypass geschichte ist vermutlich der Authentication Bypass gemein, der weniger mit deiner Session zu tun hat sondern ehr mit der Verschlüsselung. Wenn du SSL anschmeißt müsste das Problem gelöst sein.

    Das ist so mein stand.

    Ich hoffe ich konnte etwas licht ins dunkle bringen.

    so long
    jd
    Erst wenn der letzte FTP Server kostenpflichtig, der letzte GNU-Sourcecode verkauft, der letzte Algorithmus patentiert, der letzte Netzknoten kommerzialisiert, die letzte Newsgroup moderiert wird, werdet Ihr merken, dass man mit Geld allein nicht programmieren kann.

  • Hi JFox,

    danke für deine Antwort! Also das Wiki habe ich schon gelesen, bin aber nciht recht schlau daraus geworden. habe dazu noch viele andere Foreneinträge gelesen etc.

    Bin da viel über Foren und GB's gestoßen über <img> tags.. Ich habe das bisher so aufgefasst, das CSRF für mich ab dann ein Problem werden kann, sobald ich usern erlaube selbstständig Werte der DB hinzuzufügen (also Foren- oder Gästebucheinträge) und diese Werte dann auch noch HTML tags beinhalten dürfen.
    Auf diesem Wissensstand war ich zumindest bevor ich den "grendel-scan" durchlaufen lies... Ist das so korrekt?

    Der CSRF error hat mich dahingehen überrascht, dass ich auf der Seite nur ein einziges Insert bzw Update ausführe (anzahl der logins +1) und da auch keine useringaben übergeben werden.

    grüße
    Timo
    ----[Blockierte Grafik: http://www.smilie-harvester.de/smilies/Alltag/putzen.gif] Nein ich bin nicht die Signatur, ich Putz hier nur ---

  • Um ehrlich zu sein, so verstehe ich das auch. Ich denke mal das wir da garnicht mal so falsch liegen. Man sollte den Usern auch nicht erlauben HTML-Tags in die DB zu schreiben, Foren verhindern sowas mit so nem Code (Wiki Formatierung BBcode, gibts bestimmt nen Fachbefriff dafür :) ). Also das mit der DB ist sone Sache nen Gästebuch ohne INSERT ist etwas unrealistisch. Wobei ich keine Direkten Zugriff auf Tabellen bei mir hat. Ich habe vieles über Rules Function und Trigger gemacht (PostgreSQL). Ich weiß zwar nicht ob das was bringt, aber es macht die Apllikations-Entwicklung erheblich leichter. Hast du mal versucht via PDO Schnittstelle zu arbeiten?

    Ich weiß nicht ob das was bringt, ist nur so ein Gedanke:

    [wiki]Einführung in PDO[/wiki]
    Erst wenn der letzte FTP Server kostenpflichtig, der letzte GNU-Sourcecode verkauft, der letzte Algorithmus patentiert, der letzte Netzknoten kommerzialisiert, die letzte Newsgroup moderiert wird, werdet Ihr merken, dass man mit Geld allein nicht programmieren kann.

  • Ja hab ich schon angeschaut, ab dem nächsten "Projekt" werde ich PDO benutzen, ob das was bringt, kann ich dir auch nicht sagen :P

    Also bezüglich CSRF bin ich nun ein bisschen schlauer geworden. Würds gern versuchen zu erklären, bin da aber echt mies drin. Les dir mal das hier durch, wird hier recht anschaluich beschrieben. (Wiki ist mir persönlich oftmals zu umständlich formuliert :D ) cms-sicherheit.de/module-blog-viewpub-tid-1-pid-24.html

    Ein Schutz wird geboten wenn noch ein sog "token" (oh kenn das noch als sprechknochen im token ring *schauer, bibber*) übergeben, der am besten zufällig generiert werden sollte. Auf der zeite machen die nen md5hash aus der funktion time() was nicht so toll ist. Naja auf jedenfall denke ich mal das ich das mit CSRF in den griff bekomme, habe ja nun nen ansatz die Lücke zu schließen.

    Was mir allerdings größere sorgen macht ist der Authentication bypass detected error, da sich das Tool unberechtigt zugang verschafft hat, ohne eine gültige session
    Some authenticated requests were successfully executed without providing a session ID.


    grüße
    ----[Blockierte Grafik: http://www.smilie-harvester.de/smilies/Alltag/putzen.gif] Nein ich bin nicht die Signatur, ich Putz hier nur ---

  • Hallo, ich werde mich das mal anschauen, habe hier auch noch was zum Thema Authentication Bypass gefunden, da wird das relativ vernünftig erklärt worauf man achten muss.

    owasp.org/index.php/Testing_fo…ing_Authentication_Schema
    Erst wenn der letzte FTP Server kostenpflichtig, der letzte GNU-Sourcecode verkauft, der letzte Algorithmus patentiert, der letzte Netzknoten kommerzialisiert, die letzte Newsgroup moderiert wird, werdet Ihr merken, dass man mit Geld allein nicht programmieren kann.

  • Wie ist deine Seite unter localhost/test denn aufgebaut? Ist das eine reine Admin Umgebung? D.h. als nicht angemeldeter Benuter mit deaktivierten Cookies kannst du KEINE der Seiten aufrufen?
    Oder ist das ein Mischding.. das heißt manche Seiten kannst du aufrufen und manche Seiten nicht.

    Wenn du eine Seite ohne Login zur Verfügung stellst, denke ich nicht, dass das Tool erkennen kann, dass dies erlaubt ist und denkt daher, dass du zwar einen Login hast, aber andere Seiten, die womöglich hinter dem Login verlinkt sind, dennoch auch ohne Login erreichbar sind.

    Und ich habe einen andere Sicherheitsfehler gefunden.
    Stelle include_once auf require_once um... stell dir vor, dass aus irgendeinem Grund kann nicht auf die Datei zugegriffen werden kann. Dann wird eine Warnung ausgespuckt und du bist dennoch drin.