Session Fixation

Akzeptiert die Webanwendung Session-IDs als Parameter eines HTTP-GET- oder -POST-Aufrufes, kann der Angreifer dem Opfer die Session-ID mit Hilfe einer manipulierten URL unterschieben. Eine solche manipulierte URL könnte wie folgt aussehen, wobei 30fz93 hier die Session-ID wäre:

http://www.example.com/login.asp?session=30fz93

Um den Inhalt und insbesondere die Parameter der URL zu verschleiern, könnte der Angreifer auch auf einen Kurz-URL-Dienst zurückgreifen. Die URL kann dem Opfer beispielsweise per E-Mail zugesendet oder sonst wie genannt werden oder sie kann als Link oder als Ziel eines HTML-Formulars auf einer Webseite hinterlegt werden. Bei dieser Methode des Unterschiebens ist der Angreifer aber immer darauf angewiesen, dass sein Opfer die URL öffnet bzw. ein Formular absendet. Wird die manipulierte URL aber beispielsweise als Quell-URL für ein in eine Webseite oder E-Mail eingebettetes Bild verwendet, wäre selbst dies nicht notwendig. Dies kann allerdings verhindert werden, indem ein vom Browser getrennter E-Mail-Client genutzt wird.

Ist die zu kompromittierende Webanwendung anfällig für einen Cross-Site-Scripting-Angriff und kann der Angreifer über diese Sicherheitslücke JavaScript-Code einführen, kann er hierüber auch eine zuvor generierte Session-ID unterschieben.

Ist der Browser des Opfers anfällig für einen Cross-Site-Cooking-Angriff, kann der Angreifer dem Opfer ein Cookie für die zu kompromittierende Webanwendung unterschieben, falls dieses eine völlig andere Webseite besucht, über die der Angreifer Kontrolle hat.

Hat der Angreifer physikalischen Zugriff auf den Rechner und das Benutzerkonto seines Opfers, kann er die Session-ID direkt in dem Browser seines Opfers hinterlegen. Alternativ kann er sich auch vom Rechner seines Opfers aus eine neue Session-ID ausstellen lassen und sich merken. Obwohl es sich dann strenggenommen nicht mehr um ein Unterschieben, sondern um ein Ausspähen der Session-ID handelt, gehört auch diese Methode noch zum Angriff der Session fixation. Ein physikalischer Zugriff ist nicht notwendig, wenn der Angreifer aus der Ferne die Kontrolle über den PC erlangen kann. Dies kann entweder über eine Sicherheitslücke in anderen Anwendungen oder dem Betriebssystem, über ein Benutzerkonto mit administrativen Rechten oder über ein Trojanisches Pferd geschehen.

Die folgenden Maßnahmen bieten keine absolute Sicherheit gegen Angriffe durch Session Fixation, heben jedoch die technischen Hürden für Angreifer.

• Internetnutzer sollten sich bei Webangeboten versichern, ob sie sich auf der richtigen Seite befinden und ob die Seite sichere Verschlüsselungsverfahren wie SSL unterstützt (wobei SSL, für sich genommen, Session-Fixation nicht verhindern kann).
• Internetnutzer sollten sich sicherheitshalber nach dem Besuch des Webdienstes immer ausloggen, damit fremde Personen die Internetseite nicht im Verlauf des Browsers wieder aufrufen können, um die Session-ID des Nutzers zu bekommen.
• Bei der Verwendung von Cookies nicht die oft angebotene Option „Anmeldung merken“ auswählen, da diese dann meist ein persistentes Cookie vergibt.
• Bei Verwendung von Basic/Digest Authentication den Browser und all seine Instanzen schließen (da Basic/Digest Auth kein Logout kennt).

• Zum Zeitpunkt des Logins eines Benutzers sollten keine früheren Informationen über die Identität des Benutzers übernommen werden. Das bedeutet, beim Login sollte immer eine neue Session zugewiesen werden. Nicht personenbezogene Daten zur schon existierenden Session können durchaus in die neue Session übernommen werden.
• Wenn nicht zwingend nötig, sollte einem nicht-eingeloggten Benutzer gar nicht erst eine Session zugewiesen werden.
• Weitere schon gegen das Session Hijacking nützliche Maßnahmen gelten auch hier:
  • Sessions sollten einen Timeout haben. Sowohl einen weichen, der bei Nicht-Benutzung greift, als auch einen harten, der die Session nach einer Maximalzeit verfallen lässt. Auch sollte die Session-ID nur eine begrenzte Gültigkeit haben und nach Ablauf durch eine neue Session-ID ersetzt werden.
  • Sessions sollten an eine IP-Adresse oder einen Fingerabdruck des Client (beispielsweise eine Kombination aus User-Agent-Kennung und anderen vom Client gesendete Header-Felder) gebunden sein. Wird versucht die Session von einem Computer mit einer anderen IP-Adresse oder einem anderen Fingerabdruck als dem ursprünglichen zu nutzen, sollte diesem eine neue Session zugewiesen werden.
• Die Webanwendung muss eine Logout-Möglichkeit bieten. Beim Logout muss dann sowohl die Session-ID zum Client (z. B. Cookie) als auch das Session-Objekt auf dem Server gelöscht werden.