Session-Angriffe – eine Analyse an PHP

Den vollständigen 1. Teil des Dokumentes unter Creative Common-Lizenz als PDF-Datei herunterladen:

• Analyse und Maßnahmen gegen Sicherheitsschwachstellen bei der Implementierung von Webanwendungen in PHP/MySQL (Teil 1)

Eine „Session“ ist eine Arbeitssitzung mit einer Software. Webanwendungen basieren auf dem HTTP-Protokoll, welches die Kommunikation zwischen Client (Webbrowser) und Server (Webanwendung) regelt. HTTP ist ein zustandsloses Protokoll. Mehrere Kommunikationsschritte eines Webbrowsers zu einem Server werden nicht als eine Arbeitssitzung, eine Session, zusammengefasst, sondern unabhängig voneinander betrachtet. Die Möglichkeit, den Zustand der Webanwendung während einer Arbeitssitzung zu speichern, macht jedoch dynamische Webseiten erst möglich. Dadurch wird beispielsweise ermöglicht, dass ein einmal identifizierter Nutzer die Webseite verwenden kann, ohne sich beispielsweise jedes Mal erneut identifizieren zu müssen. Darüber hinaus kann sich die Webanwendung anhand der Sitzung, Daten und Einstellungen zu einem bestimmten Nutzer merken.

Im Folgenden wird die PHP-interne Sessionverwaltung näher beleuchtet. Sie wurde mit PHP Version 4.0 eingeführt und ist in ihrer Handhabung so einfach, dass sie fast ausschließlich und ohne weitere Anpassungen verwendet wird.

1.4.1 Gefahreneinschätzung

Mit Hilfe von Sessions wird in den meisten Fällen eine Identifizierung und Autorisierung gegenüber der Software durchgeführt. Alle Angriffe, die diese Autorisierung zweckentfremden, klonen beziehungsweise kopieren oder umgehen können, haben Kontrolle über das zu schützende System samt seinen Daten und sind als höchst gefährlich zu betrachten.

1.4.2 Das Sessions-Mechanismus

Eine Session stellt eine Identifizierung eines Clients gegenüber einem Server dar. Dazu wird in einem frühen Stadium der Kommunikation ein Identifikationsschlüssel vom Server zum Client geschickt. Fortan sendet der Client bei jeder Anfrage den Schlüssel mit, der als Kurzzeit-Passwort verstanden werden kann. Der Schlüssel kann über URL-Parameter, in Formularen als verstecktes Feld sowie in Cookies gesendet werden. Das Setzen des Schlüssels in ein Cookie gestaltet sich für einen Anwendungsentwickler als einfach, da das HTTP-Protokoll die Aufgabe der Übermittlung zwischen Server und Client übernimmt.

Der Session-Schlüssel

Da die Authentifizierung des Clients an den Server alleine über den Schlüssel statt findet, darf dieser nicht erraten werden können. Wenn der Schlüssel erraten werden kann, so kann eine Identität gestohlen werden, indem der Angreifer den bekannten Schlüssel zur Kommunikation mit demselben Server verwendet. Jedoch erzeugt PHP den Schlüssel mit einer ausreichend hohen Zufallswahrscheinlichkeit und mit einer Länge von 32 Zeichen. Ein Erraten ist praktisch nicht möglich.

1.4.3 Session-Fixation

Session-Fixation ist ein Angriff auf den Sessionschlüssel, der zur Identifizierung bei der Webanwendung benötigt wird. Da der Angreifer diesen nicht erraten kann, versucht er ihn vorzugeben. Der Angriff ist erfolgreich, wenn er einen Nutzer dazu bewegen kann, diesen fixierten Sessionschlüssel zu verwenden.

Um die Schadenswirkung bei Kenntnis des Schlüssels verständlich zu machen, wird sich eines Beispiels bedient:

In einem Bahnhofsgebäude befinden sich Schließfächer. Ein Angreifer verwendet ein Schließfach, entnimmt den Schlüssel und fertigt eine Kopie an. Anschließend gibt er das Schließfach wieder frei. Verwendet ein Opfer anschließend dasselbe Schließfach, so besitzt der Angreifer bereits einen passenden Schlüssel dazu. Da an solche Schließfächer keine weiteren Kontrollen (Identitätskontrolle, einmaliger Zugangscode) stattfinden, genügt der Besitz des Schlüssels um an fremde Inhalte zu kommen.

In [Kol02] werden zwei Typen von Sessionsystemen beschrieben:

• permissiv
• strikt

Permissive Systeme sind solche, die jeden beliebigen Sessionschlüssel akzeptieren und für die laufende Sitzung verwenden. Dabei spielt es keine Rolle, ob dieser bestimmten Sicherheitsanforderungen genügt¹ oder ursprünglich auf dem Server auf dem er verwendet wird, generiert wurde.

Die Session-Fixation macht sich die permissive Eigenschaft der Sessionverwaltung in PHP zunutze. Findet diese einen alten Sessionschlüssel in der Kommunikation mit dem Client, so wird dieser als neuer Schlüssel akzeptiert, anstatt einen neuen zu generieren². Gelingt es also dem Angreifer, dem Nutzer seinen Schlüssel zu übertragen, so kann er mit demselben Schlüssel ebenfalls auf die Nutzerdaten zugreifen. Dabei kann der fremde Schlüssel in einem Link, einem Formular oder Cookie versteckt sein [Kol02, S. 5]. In manchen Fällen ist ein vorgelagerter XSS-Angriff notwendig um den vorbereiteten Sessionschlüssel beispielsweise direkt im Cookie des Opfers einzufügen.

Die offizielle Dokumentation zur PHP-Sessionverwaltung [PHPf] verwendet zur Veranschaulichung der Funktionsweise der Session folgendes Beispiel:

Abbildung 23: Codebeispiel der Sessionverwaltung in der offiziellen PHP-Dokumentation

Wird dieser Code aufgerufen, so startet die Funktion session_start() eine neue Sitzung und erzeugt einen eindeutigen Sitzungsschlüssel. Dieser wird als Cookie im Browser gespeichert.

Tabelle 1: Inhalt des Session-Cookies im Browser der Nutzer

Diese Daten sind jedem zugänglich, der ein Cookie von der betroffenen Seite empfängt. Dabei ist der Inhalt des Cookies der eigene Sitzungsschlüssel, der den Nutzer eindeutig identifiziert.

Angriffsvektor

Abbildung 25: Session-Fixation-Angriff. Quelle: eigene Darstellung.

1. Der Angreifer ruft die Anwendung als anonymer Nutzer auf.
2. Für die neue Session wird ein Cookie mit einer Sessionkennung erzeugt (123).
3. Das Cookie mit der Sessionkennung wird dem Angreifer gesendet.
4. Der Angreifer entnimmt dem Cookie die Kennung und gestaltet damit einen speziellen Link. Diesen lässt er dem Opfer zukommen.
5. Das Opfer verwendet den Link, um zur Anwendung zu gelangen. Dabei meldet es sich mit seinen Daten an.
6. Die Anwendung akzeptiert die Sessionkennung (123) und ordnet diese dem korrekt angemeldeten Nutzer „Müller“ zu.
7. Auch der legitimierte Nutzer bekommt ein Cookie zugeschickt.
8. Der Angreifer kann jetzt mit seinem eigenen Cookie die Anwendung aufrufen.
9. Da in der Zwischenzeit die Sessionkennung (123) des Angreifers dem Nutzer „Müller“ zugeordnet wurde, wird der Angreifer mit dieser Kennung als Nutzer „Müller“ von der Anwendung akzeptiert werden.

Der Angriff auf eine Webanwendung, die sich ausschließlich auf den gültigen Schlüssel verlässt, kann stattfinden durch:

• Link / Formular und
• Cookie-Änderung.

Das Setzen des Sitzungsschlüssels über Links oder Formulare bleibt ohne Auswirkung, wenn das Opfer bereits ein gültiges Cookie der Zielseite besitzt. Um den im Cookie gespeicherten Sitzungsschlüssel zu ändern, braucht der Angreifer eine XSS-Lücke in der Zielanwendung. Dann muss er das Opfer dazu verleiten, über einen präparierten Link oder Formular den Skriptcode in der Seite aufzurufen [Kol02].

Abbildung 26: Code zum Ändern des Cookie-Sitzungsschlüssels

Beide Beispiele ändern erfolgreich ein bereits gesetztes Cookie. Dabei ist der Aufruf in b) besonders heikel, denn er umgeht eine etwaige Filterung nach dem typischen XSS-Angriffs-Muster: „<script>“.

1.4.4 Session Hijack

Dieser Angriff beschreibt das Kopieren des Sitzungsschlüssels eines Nutzers durch den Angreifer. Dies kann geschehen durch:

• Mitlesen des Netzwerkverkehrs,
• Auslesen des Sitzungsschlüssels aus der Webseite und
• Auslesen des Sitzungsschlüssels aus der Sessionverwaltung.

Gegen ein Auslesen des Schlüssels aus dem Netzwerkverkehr hilft das Verwenden einer sicheren HTTP-Verbindung zwischen Client und Server (HTTPS).

Die einfachste und daher häufigste Angriffsart besteht darin, den Sitzungsschlüssel aus dem Cookie des Nutzers oder aus der betroffenen Webseite auszulesen. Voraussetzung dafür ist, dass zuvor ein erfolgreicher XSS-Angriff stattgefunden hat. Dabei fügt der Angreifer Skriptcode in die Seite ein, der beim Aufruf durch einen Nutzer dessen Cookie ausliest und die Daten an einen fremden Server sendet. Mit diesen Daten kann der Angreifer auf seinem Browser eine Kopie des Cookies erstellen und erlangt so die Identität und die Privilegien des angegriffenen Nutzers.

Abbildung 27: XSS-Code um den Cookie an einen Fremdserver zu senden

1.4.5 cookie replay attack

Hierbei handelt es sich um die Wiederverwendung eines gestohlenen Identifikations-Cookies. Dieser Angriff wird dadurch ermöglicht, weil einige Webanwendungen die Sitzungsdaten länger speichern, als der Nutzer diese tatsächlich verwendet. Auch nach dem Abmelden des Nutzers bei einer Webseite wird oft nur der Identifikations-Cookie des Nutzers gelöscht, nicht jedoch die dazugehörige Sitzung auf dem Server. Ein Angreifer kann so auf die in der Sitzung gespeicherten Daten zugreifen oder die Identität des Opfers annehmen.

1.4.6 Session Riding oder CSRF (Cross Site Request Forgery)

Dieser Angriff nutzt das Vertrauen einer Webanwendung gegenüber einem authentifizierten Nutzer aus. Bei den meisten Webanwendungen genügt eine einmalige Authentifizierung mit Nutzername und Passwort, um diesem Nutzer je nach seinen Rechten, weitergehende Aktionen zu erlauben. Der CSRF-Angriff nutzt diese Authentifizierung aus, indem er im Namen des Nutzers und mit seinen Privilegien eigene Befehle an die Anwendung absetzt.

Anhand der folgenden Abbildung soll ein solcher Angriff analysiert werden.

Abbildung 28: CSRF-Angriff. Quelle: eigene Darstellung.

1. Der Nutzer ruft eine Webanwendung auf und authentifiziert sich.
2. Es wird ein Cookie mit dem Sessionschlüssel zur Identifizierung erstellt.
3. Der Cookie wird dem Nutzer gesendet und bei diesem abgespeichert.
4. Der Nutzer besucht anschließend unwissentlich einen kompromittierten Server.
5. Die Antworten des Servers enthalten ein unsichtbares Element innerhalb der Seite.
6. Eine manipulierte Webseite wird dem Nutzer geschickt.
7. Beim Anzeigen der manipulierten Seite wird das unsichtbare Element darin aktiv.
8. Ein für den Nutzer unsichtbarer Befehl geht an den Bankserver und mit ihm automatisch auch der aktuelle, gültige Zugangs-Cookie des Nutzers. Damit hält der Bankserver den Befehl für authentifiziert und legitimiert und führt ihn aus.

Chris Shiflett [Shi07] demonstrierte in März 2007 eine SCRF-Schwachstelle in Amazons „1-Click“- Kaufsystem. Ein angemeldeter Amazon-Kunde der eine spezielle Beispielseite besuchte, hatte dann unerwartet Chris’ Buch³ in dem digitalen Einkaufswagen. Über ein Jahr nach der Bekanntmachung der Lücke war diese von Amazon noch nicht geschlossen worden.

---

Fußnoten

1. „Anforderungen an eine SessionID“ [BSI01, Kap. M210]
2. In der PHP-Konfiguration muss dazu die Einstellung „session.use_trans_sid“ eingeschaltet sein.
3. Vergleiche: [Shi04]

---

Literaturverzeichnis

[Kol02]	Kolšek, Mitja „Session Fixation Vulnerability in Web-based Applications“ http://www.acros.si/papers/session_fixation.pdf [letzter Besuch: 08.02.2008] Dezember 2002
[PHPf]	PHP- Manual „Sessions“ http://de.php.net/session [letzter Besuch: 08.02.2008]
[Shi07]	Shiflett, Chris „My Amazon Anniversary“ http://shiflett.org/blog/2007/mar/my-amazon-anniversary [letzter Besuch: 08.02.2008] 2007
[BSI01]	„Sicherheit von Webanwendungen, Maßnahmenkatalog und Best Practices“ http://www.bsi.de/literat/studien/websec/WebSec.pdf [letzter Besuch: 26.02.2008] 2001
[RFC2616]	Fielding, R.; UC Irvine; Gettys, J.; Compaq/W3C; Mogul, J.; Compaq; Frystyk, H.; W3C/MIT; Masinter, L.; Xerox; Leach, P.; Microsoft; Berners-Lee, T. „Hypertext Transfer Protocol — HTTP/1.1“ http://www.ietf.org/rfc/rfc2616.txt [letzter Besuch: 26.02.2008] 1999

---

Diese Arbeit wird im Rahmen der „Creative Commons“-Lizenz zur Verfügung gestellt.
Sie dürfen:

• das Werk vervielfältigen, verbreiten und öffentlich zugänglich machen
• Bearbeitungen des Werkes anfertigen

Zu den folgenden Bedingungen:

• Namensnennung. Sie müssen den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen (wodurch aber nicht der Eindruck entstehen darf, Sie oder die Nutzung des Werkes durch Sie würden entlohnt).
• Keine kommerzielle Nutzung. Dieses Werk darf nicht für kommerzielle Zwecke verwendet werden.

Vollständiger Lizenztext: http://creativecommons.org/licenses/by-nc/3.0/deed.de