Benutzer:Raf-dat/Penetration Testing/Session Hijacking
Als Session Hijacking wird das Übernehmen einer Internet-Session verstanden.
Exkurs: Sessions[Bearbeiten]
Dynamische Seiten wie Internetforen, Blogs, CMS etc. verwenden Sessions, damit man z. B. immer noch eingeloggt ist, wenn man zwischendurch auf eine andere Seite geht. Erst wenn man sich offiziell ausloggt, wird die Session zerstört.
Wenn eine Session gestartet wird, bekommt der Client vom Server eine eindeutige, 26-stellige, alphanumerische ID. Diese wird in einem Cookie unter dem (Standard)Namen PHPSESSID gespeichert, oder (wenn Cookies deaktiviert sind) der URL als GET-Parameter angehängt. Der Server legt in einem bestimmten Verzeichnis kleine Dateien an, in denen die Informationen über die Session gespeichert sind. Eine Sitzung mit Sessions könnte etwa so aussehen:
<?php session_start(); $_SESSION["username"] = $_POST["username"]; $_SESSION["pass_hash"] = md5($_POST["passwort"]); ... ?>
Damit wurde eine Session angelegt, in der der Benutzername und der Hash (Fingerabdruck) der Passwortes gespeichert ist. Der Benutzer kann diese Daten nicht sehen, denn sie werden auf dem Server gespeichert, aber die ID wird zur eindeutigen Identifizierung benötigt. Ein weiteres Dokument könnte folgendermassen aussehen:
<?php
session_start(); // Die Session muss in jeder Seite neu initialisiert werden, aber die Dateien auf dem Server bleiben erhalten
if($_SESSION["username"] == $username && $_SESSION["pass_hash"] == $passwort) {
...
} else {
...
}
?>
Zuerst werden die Session-Dateien mit anderen Werten verglichen, die vorher z. B. aus einer MySQL-Tabelle entnommen wurden, verglichen (schlechtes Beispiel, aber zur Veranschaulichung genügt es). Wenn die Daten korrekt sind, kann man in den geschützten Bereich, sonst nicht. Die Session muss speziell beendet werden, da sonst die Dateien auf dem Server bleiben (nach einer bestimmten Zeit werden sie automatisch gelöscht).
<?php session_start(); $_SESSION = array(); // Die Session wird neu initialisiert, d. h. geleert session_destroy(); // Die Session wird beendet ?>
XSS und Session Hijacking[Bearbeiten]
Man könnte sich nun fragen, was das soll. Aber wenn man weiter denkt und das Wissen aus der letzten Lektion anwendet (besonders die Hinweise mit dem Link verschicken), könnte einem ein Licht aufgehen.
Zuerst: Session Hijacking ist nur möglich, wenn man eine XSS-Lücke gefunden hat.
Nun zur Theorie: Die PHPSESSID wird als Cookie gespeichert, welche mit dem JavaScript-Befehl document.cookie ausgelesen und gesetzt werden können. Wenn man nun eine XSS-Lücke hat, kann man den Code einfügen, der einen Cookie schreibt (das ist nämlich mit PHP und JavaScript möglich), welcher PHPSESSID heisst und eine 26 Zeichen lange, zufällig generierte ID enthält. Man kann nun den manipulierten Link zum Beispiel dem Administrator der Homepage schicken. Mit ein wenig Glück ruft er ihn auf, die Cookies werden geändert und wenn er sich das nächste mal in sein Admin-Control-Panel einloggt, wird eine Session mit der ID erstellt, die man selbst kennt. Man ändert nun die eigene ID auf die generierte (mit Firefox-Addons wie Cookies Manager+) und kann sich (weil die IDs identisch sind) unter dem Account des Administrators einloggen.
Dies funktioniert nur auf der Seite selbst, da man keine Cookies für andere Domains generieren kann. Ausserdem ist diese Methode nur für Reflected XSS geeignet, da sonst jeder Besucher der Webseite die selbe ID bekommt, was nicht unbedingt von Vorteil ist.
Dies funktioniert nur, wenn der Name der Session entweder dem Standard PHPSESSID entspricht, oder der geänderte Name bekannt ist.
Absicherung gegen Session Hijacking[Bearbeiten]
Am besten ist es, wenn man keine XSS-Lücke in der Webanwendung hat, dann ist kein Session Hijacking möglich. Weiterhin kann man mit Zertifikaten oder anderen Techniken arbeiten, die eine eindeutige Identifikation des Benutzers erlauben.