Wie kann das in About Security #155 vorgestellte Session Hijacking verhindert werden? Um mögliche Gegenmaßnahmen entwickeln zu können, müssen zuerst die möglichen Angriffe bekannt sein. In diesem Fall lautet die entscheidende Frage: Wie gelangt ein Angreifer an Session IDs? Ist das bekannt, können diese Möglichkeiten der Reihe nach versperrt oder zumindest erschwert werden.

Session ID ermitteln

Um eine Session ID auszuspähen oder zu ermitteln, hat der Angreifer mehrere Möglichkeiten:

• Cross-Site Scripting: Das Ausspähen eines Session Cookies ist einer der Standardangriffe über Cross-Site Scripting.
• Netzwerkverkehr belauschen: Kann der Angreifer den Netzwerkverkehr zwischen einem Benutzer und einer Webanwendung belauschen, kann er versuchen, darin die Session ID zu erkennen.
• Logfiles durchsuchen: Hat der Angreifer Zugriff auf die Logfiles des Webservers, kann er darin nach über GET-Requests übertragenen Session IDs suchen.
• Brute Force: Der Angreifer versucht, das Format der Session-IDs zu erraten, indem er verschiedene Kombinationen ausprobiert, bis er eine passende ID erraten hat.
• Fuzzing: Weiß der Angreifer, das Session IDs einen bestimmten Aufbau haben oder aus einem bestimmten Zahlenbereich stammen, kann er entsprechende Muster ausprobieren, bis er eine gültige ID gefunden hat.

Session Hijacking verhindern

Da man den Angreifer nicht davon abhalten kann, statt seiner eigenen eine andere Session ID an den Webserver zu senden, muss verhindert werden, dass er überhaupt an eine andere, gültige Session ID gelangt. Für die oben vorgestellten Angriffe gibt es die folgenden Gegenmaßnahmen:

• Das Ausspähen der Session ID über eine Cross-Site-Scripting-Schwachstelle kann man verhindern, indem man keine Cross-Site-Scripting-Schwachstellen in seiner Anwendung hat. Leider gibt es auch immer wieder entsprechende Schwachstellen in den verschiedenen Webbrowsern. Diesen Schwachstellen ist man als Betreiber einer Webanwendung schutzlos ausgeliefert, da man schlicht keine Möglichkeit hat, auf den verwendeten Browser Einfluss zu nehmen. Zwar könnte man theoretisch den verwendeten Browser sehr genau anhand des User Agent Headers erkennen und bei unerwünschten Browsern eine entsprechende Meldung statt der Seiten der Webanwendung ausgeben, praktisch führt das aber nur dazu, die Benutzer zu verärgern. Außerdem wird der User Agent Header vom Client geliefert, mit anderen Worten: Ihm darf nicht vertraut werden.
• Um ein Belauschen des Netzwerkverkehrs zu verhindern, kann die Kommunikation über das verschlüsselte HTTPS-Protokoll statt des ungeschützten HTTP-Protokolls erfolgen.
• Um das Ausspähen der Session-IDs aus Logfiles zu verhindern, sollten Session IDs wenn möglich nicht in der URL gespeichert werden. Generell besteht bei allen über GET-Requests übertragenen Daten die Gefahr, dass sie in Logfiles ausgespäht werden. Bei POST-Requests besteht diese Gefahr nicht, da die Daten dann im Request Body übertragen werden, der nicht in Logfiles erscheint.
• Generell sollten Session ID zufällig erzeugt werden, um das Vorhersagen einer gültigen ID zu verhindern.

Wird eine Session nicht ausschließlich über die Session ID, sondern zusätzlich über die IP-Adresse des Benutzers identifiziert, erschwert dies das Session Hijacking. Jedoch sollte man dabei berücksichtigen, dass manche Internetprovider mehrere Proxies verwenden, sodass sich die IP-Adresse durchaus auch bei einer normalen Benutzung zwischendurch ändern kann. Und wird nur ein Proxy verwendet, haben viele Benutzer die gleiche IP-Adresse, können sich also untereinander die Sessions entführen, ohne dass die zusätzliche Schutzfunktion es bemerkt.

Statt der IP-Adresse könnte auch z.B. der User Agent Header des Browsers des Benutzers als zusätzliches Erkennungsmerkmal dienen. Den kann der Angreifer aber bei Bedarf nach seinen Vorstellungen manipulieren. Hat er also erst einmal erkannt, dass eine Session außer an die Session ID auch an den User Agent Header gebunden ist, kann er sie wieder entführen. Da er dafür aber auch den User Agent Header des Benutzers ermitteln muss, wird der Angriff schwieriger.

Um die Folgen von Session Hijacking zu minimieren, sollten Sessions nach einer bestimmten Zeit beendet und die zugehörigen Session IDs für ungültig erklärt werden. Damit steigt die Wahrscheinlichkeit, dass ein Angreifer eine inzwischen ungültige Session ID ausspäht. Dabei sollte es sowohl ein hartes Timeout (nach einer bestimmten festen Zeitdauer wird die Session beendet) als auch ein weiches Timeout (nach einer bestimmten Zeit der Inaktivität wird die Session beendet) geben. Außerdem sollten die Benutzer immer die Möglichkeit haben, ihre Session selbst zu beenden, z.B. indem sie sich ausloggen.

Statt 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 in der nächsten Folge.

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