Sonntag, 1. Januar 2012


Topthema

Donnerstag, 22. Mai 2008 | Topthema

About Security #156: Schwachstellensuche: Session Hijacking verhindern

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

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

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

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.

About Security: Die komplette Serie

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.

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