Sicherheitslücken, wie schliessen?

Intermediate

Tuesday, November 11th 2008, 2:32pm

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. ( http://www.heise.de/security/tools/defau…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:

Quoted

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: http://localhost:80/inc/validateLogin.inc.php
Parameter names: "username", "passwort", and "login"
Original transaction: 53

und 2.

Quoted

Authentication bypass detected
Severity: High
URL: http://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

PHP Quellcode

$_POST['username'] = mysql_real_escape_string($_POST['username']);
                 $_POST['passwort'] = mysql_real_escape_string($_POST['passwort']);
 
                 $_POST['passwort'] = htmlspecialchars($_POST['passwort']);
                 $_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

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

In der checkLogin.inc.php steht folgender Code:

PHP Quellcode

/* Die Datei checkLogin.inc.php überprüft lediglich, ob die Variable loggedIn auf true gesetzt ist */
         session_start();
 
         //hier die gültigkeitsdauer angeben
         $dauer = 60*120;
 
         //session gültigkeitsdauer überschreitung prüfen
         if(!isset($_SESSION['timestamp']))
         {
                 $_SESSION['timestamp'] = time();
         }else
         {
                 if($_SESSION['timestamp']<(time()-$dauer))
                 {
                         session_destroy();
                 }else
                 {
                 }
         }
 
         if( (!$_SESSION['loggedIn']) OR ($_SESSION['loggedIn'] != "true") )
         {
                 header( 'Location: index.html' );
                 exit();
         }

Ü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:

PHP Quellcode

session_start();
         $_SESSION['loggedIn'] = false;
         session_unset();
         session_destroy();
 
         header( 'Location: index.html' );
         exit();

grüße
Timo

This post has been edited 1 times, last edit by "eseL" (Nov 11th 2008, 2:50pm)

JFoX

Professional

Posts: 535

2

Tuesday, November 11th 2008, 3:13pm

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

Cross-Site Request Forgery, 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

eseL

Intermediate

Posts: 108

3

Tuesday, November 11th 2008, 3:23pm

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

JFoX

Professional

Posts: 535

4

Tuesday, November 11th 2008, 3:39pm

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:

Einführung in PDO

eseL

Intermediate

Posts: 108

5

Tuesday, November 11th 2008, 3:47pm

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

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

) http://www.cms-sicherheit.de/module-blog…d-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

Quoted

Some authenticated requests were successfully executed without providing a session ID.

grüße

JFoX

Professional

Posts: 535

6

Tuesday, November 11th 2008, 3:55pm

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.

http://www.owasp.org/index.php/Testing_f…tication_Schema

Torben Brodt

Administrator

Posts: 8,454

7

Saturday, November 15th 2008, 2:33pm

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.

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

eseL

Intermediate

Posts: 108

8

Monday, November 17th 2008, 4:08pm

d0nut du bist unser aller Held.. Hattest recht was deine Vermutung angeht!

und dein tip mit require_once hab ich zur kentniss genommen, werd gleich alles ändern

viele grüße
Timo

Coder Forum