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.

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.

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.

Carsten Eilers

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

• About Security #149: Schwachstellensuche: Zustandsinformationen
• About Security #150: Schwachstellensuche: Zustandsinformationen 2
• About Security #151: Schwachstellensuche: Cookie Poisoning
• About Security #152: Schwachstellensuche: Contra Cookie Poisoning
• About Security #153: Schwachstellensuche: URL Jumping
• About Security #154: Schwachstellensuche: Der Referer Header
• About Security #155: Schwachstellensuche: Session Hijacking
• About Security #156: Schwachstellensuche: Session Hijacking verhindern
• About Security #157: Schwachstellensuche: Session Fixation