Samstag, 28. Januar 2012


Topthema

Donnerstag, 29. Mai 2008 | Topthema

About Security #157: Schwachstellensuche: Session Fixation

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/043332)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Statt beim Session Hijacking die Session ID eines Benutzers auszusp�hen, kann ein Angreifer ihm auch seine eigene Session ID unterschieben und authentifizieren lassen. Ein solcher Angriff wird als Session Fixation bezeichnet. Wie so ein Angriff funktioniert und wie Sie ihn verhindern k�nnen, erfahren Sie dieser Folge.

Schritt 4f: Session Fixation

Als Session Fixation (dt. etwa "Sitzungsbindung") wird ein Angriff bezeichnet, bei dem der Angreifer eine eigene Session erstellt und deren ID dann von einem anderen Benutzer authentifizieren l�sst. Im Folgenden wird der Angriff gleich anhand eines Beispiels beschrieben.

  1. Zuerst erzeugt der Angreifer eine eigene Session, z.B. indem er die Webanwendung einfach nur aufruft:
    login.asp
  2. Die Webanwendung vergibt dann automatisch eine neue Session ID, die z.B. als URL-Parameter �bertragen wird:
    login.asp?session=34fgfash6f4fss3
  3. Die dem Angreifer zugewiesene Session ID wird dem Opfer dann untergeschoben, z.B. in einer E-Mail:
    login.asp?session=34fgfash6f4fss3 dem Benutzer unterschieben
  4. Der Benutzer authentifiziert sich mit dieser Session ID gegen�ber der Webanwendung:
    login.asp?session=34fgfash6f4fss3&name=ich&pass=geh31m
  5. Die Anwendung akzeptiert die g�ltigen Zugangsdaten des Benutzers und gew�hrt ihm Zugang:
    drin.asp?session=34fgfash6f4fss3
  6. Der Angreifer kann nun die Identit�t des Benutzers annehmen und Aktionen in seinem Namen durchf�hren:
    tuwas.asp?session=34fgfash6f4fss3

Session unterschieben

Der kritische Punkt dabei ist das Unterschieben der vorbereiteten Session. Je nachdem, wie die Webanwendung die Session IDs speichert, gibt es daf�r zwei gebr�uchliche Methoden:

  • Wird die Session ID als URL-Parameter �bertragen, z.B. in der Form http://www.beispiel.example/login.cgi?session=..., kann der Angreifer dem Benutzer diesen URL z.B. in einer E-Mail zuschicken und ihn �ber Social Engineering dazu verleiten, diesen URL anzuklicken.
  • Wird die Session ID als Cookie oder verstecktes Formularfeld �bertragen, muss der Angreifer eine weitere Schwachstelle, z.B. eine Cross-Site-Scripting-Schwachstelle, ausnutzen, um seine vorbereitete Session einem Benutzer unterzuschieben.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

Ein gutes Ziel f�r Session-Fixation-Angriffe sind Webmail-Anwendungen. Aber nicht nur Webanwendungen, die eine Authentifizierung erfordern, k�nnen �ber Session Fixation angegriffen werden. Z.B. k�nnte eine Anwendung die Eingabe sensitiver Informationen erfordern, die auf einer �bersichtsseite zusammengefasst werden. Im Beispiel aus About Security #153 w�re das die Abschlussseite http://www.shop.example/abschluss.cgi mit der Zusammenfassung der Bestellung samt Zahlungsinformationen. Ein Angreifer k�nnte nach einem Session-Fixation-Angriff diese Seite aufrufen und die Informationen aussp�hen.

Schwachstellen finden und testen

Wie beim Session Hijacking muss ein Angreifer die Session ID identifizieren, bevor er den Angriff durchf�hrt. Entsprechend gilt hier dasselbe wie in About Security #155 beschrieben. Ob die Anwendung �ber Session Fixation angreifbar ist, ergibt ein einfacher Test: Wie verh�lt sich die Anwendung, wenn man sie mit einer vorhandenen Session ID aufruft? Beginnt die Nutzung der Webanwendung normalerweise durch den Aufruf von http://www.beispiel.example/, woraufhin die Webanwendung mit http://www.beispiel.example/index.php?session=[g�ltige ID] antwortet, beginnt man nun direkt mit dem Aufruf eines URL mit g�ltiger Session ID. �bernimmt die Anwendung diese ID, besteht Gefahr. Um sicher zu gehen, meldet man sich nun bei der Webanwendung an. Wird die anfangs �bergebene Session ID beibehalten, ist ein Angriff in der Tat m�glich.

Session Fixation verhindern

Um Session Fixation zu verhindern, muss jedes Mal, wenn sich ein Benutzer authentifiziert, eine neue, zuf�llig erzeugte Session ID vergeben werden. Dasselbe gilt, wenn ein anonymer Benutzer das erste Mal pers�nliche Daten oder sensitive Informationen eingegeben hat.

About Security: Die komplette Serie

Manche Anwendungen akzeptieren beliebige Session IDs � auch solche, die sie nicht ausgegeben haben. F�r den Angreifer entf�llt damit der Schritt, sich eine g�ltige Session ID beschaffen zu m�ssen. Stattdessen kann er dem Benutzer gleich eine beliebige Session ID unterschieben, was den Angriff noch etwas erleichtert. Daher sollten nur selbst ausgegebene Session IDs akzeptiert werden. Bei einem Zugriff mit einer nicht von der Anwendung erzeugten Session ID muss die Session ID verworfen und der Session eine neu erzeugte ID zugewiesen werden.

Ebenso unsicher ist die M�glichkeit mancher Webanwendungen, eine abgelaufene Session mit bekannter Session ID zu reaktivieren. Stattdessen muss eine neue Session mit neuer Session ID und dem gespeicherten Zustand erzeugt werden. Sonst k�nnte ein Angreifer g�ltige Session IDs sammeln und diese sp�ter reaktivieren.

Verwenden mehrere Benutzer die gleiche Session ID, kann das �ber den Referer Header erkannt werden: Stimmt die beobachtete Reihenfolge der URL-Aufrufe nicht mit der normalen Reihenfolge �berein, findet entweder ein URL-Jumping-Angriff statt (siehe About Security #153), oder ein anderer Benutzer verwendet die gleiche ID.

Mit der Session Fixation endet die Suche nach zustandsbasierten Angriffen. Ab der n�chsten Folge geht es um Angriffe �ber vom Benutzer gelieferte Daten. Zuerst erfahren Sie, wie Sie Cross-Site-Scripting-Schwachstellen finden.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "Schwachstellensuche � II. Zustandsbasierte Angriffe"

Kommentare

Folgende Links könnten Sie auch interessieren