O'Reilly logo

PHP-Sicherheit: PHP/MySQL-Webanwendungen sicher programmieren by Stefan Esser, Christopher Kunz

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

7 Sessions182
7.8 Session Fixation
Session Fixation beschreibt ein Verfahren, bei dem der Angreifer einem
legitimen Benutzer einer Webanwendung eine bereits vorher erstellte
Session-ID unterschiebt. Das bedeutet, dass der Angreifer sich eine Ses-
sion-ID ausdenkt, die der User beglaubigt, indem er sich mit eben die-
ser Session-ID einloggt. Damit hat der Angreifer Zugriff auf eine Ses-
sion, da er die Session-ID bereits kennt.
Session-ID durch einen
Benutzer gültig machen
lassen
Diese gefälschte Session-ID schickt er, an einen Link angehängt, an
einen privilegierten Benutzer. Der Benutzer klickt nun auf den Link
und meldet sich eventuell in einem geschützten Bereich an. Der Angrei-
fer kann nun die Session übernehmen und somit die Persönlichkeit des
Benutzers annehmen.
Dem Entwickler stehen einige Wege offen, Session Fixation zu
verhindern bzw. die möglichen Folgen zu mildern:
Wenn sich ein Benutzer an einem Session-basierten System anmel-
det, sollte stets eine neue Session-ID generiert werden. Dafür steht
die Funktion
session_regenerate_id() in PHP zur Verfügung.
Bei jeder »wichtigen« Aktion, wie etwa Bestell- oder Bezahlvor-
gängen sowie Passwortänderungen, sollte eine erneute Authentifi-
zierung stattfinden. Ein gutes Beispiel hierfür sind der Onlinebuch-
händler »Amazon« oder auch beliebige Onlinebanken, die trotz
gültiger Session stets eine erneute Authentifizierung verlangen,
bevor Transaktionen durchgeführt werden können.
7.9 Zusätzliche Abwehrmethoden
Für die Verhinderung von Session-Angriffen gibt es einige theoretische
Ansätze. Es gibt leider noch keine zufriedenstellende, frei verfügbare
Umsetzung dieser Ansätze.
7.9.1 Page-Ticket-System
Dieser Ansatz geht von einem Session-unabhängigen, weiteren Spei-
chermedium aus. Es wird ein Pool an langen Zufallszahlen auf dem
Server generiert und auch dort gespeichert. Zusätzlich wird das Ses-
sion-System von PHP verwendet. Somit existiert eine Session-ID für
den Benutzer und eine Zahl aus dem Zufallszahlenpool. Die Session-
ID identifiziert den Benutzer, und die Zufallszahl identifiziert jede ein-
zelne Seite.
5>5B95B5>(95 >13859>5=5B6?<7B59385>!?79>59>5>5E5(5CC9?>TB
LG938D975K;D9?>5>9CD59>55B>5ED5ED85>D969J95BE>75B6?B45B<938
1837.9 Zusätzliche Abwehrmethoden
Zusätzliche Zufallszahlen
auf dem Server speichern
Diese Zufallszahl wird in der Session gespeichert und an die URL
angehängt. Nach der Anforderung einer weiteren Seite wird die
Zufallszahl aus dem Zahlenpool gelöscht und eine neue ausgelesen.
Diese Zahl wird dann auch wieder in die Session geschrieben. Diese
Zufallszahl muss natürlich an alle Links auf der Seite angehängt wer-
den. Eine Session kann dann nur so lange übernommen werden, wie
der Benutzer auf einer Seite verweilt. Im Falle, dass die Zufallszahl in
der URL fehlt, muss die Session ungültig gemacht werden, ebenso
wenn die Zufallszahl nicht mehr im Zahlenpool enthalten ist.
Hier sehen Sie eine vereinfachte Ablaufbeschreibung:
1. Der Benutzer fordert Seite index.php an.
2. Der Server erstellt eine Session-ID »abcdefg« und erzeugt einen
Pool an Zufallszahlen, falls dieser noch nicht existiert. Dieser wird
unter dem Namen der Session gespeichert.
3. Aus diesem Pool von Zufallszahlen wird die Zahl 10 genommen.
4. Die Zahl »10« wird in der Session gespeichert.
5. Alle Links auf der Seite index.php werden um ein ?token=10 er-
weitert.
6. Der Benutzer fordert nun die Seite index2.php?token=10 an.
7. Auf dem Server wird überprüft, ob der URL-Parameter »token«
einen Wert enthält und mit dem in der Session gespeicherten Wert
übereinstimmt.
8. Ist das der Fall, wird die Zufallszahl »10« aus dem Pool gelöscht
und eine neue ausgelesen. Diese wird wieder an die URL aller
Links auf index2.php angehängt. Außerdem wird am Ende wieder
eine neue Zahl in den Pool eingefügt.
9. Stimmen die Zahlen nicht überein, ist die Zahl nicht mehr im Pool
enthalten, fehlt der Pool auf dem Server oder ist der Parameter
»token« leer, so wird die Session beendet und alle Daten gelöscht.
10. Ein Cronjob oder eine Funktion des Page-Ticket-Systems sorgt da-
für, dass alle Pools, die älter als 10 Minuten sind, vom Server ge-
löscht werden.
Dieser Ansatz verspricht ein Plus an Sicherheit, schützt aber nicht
vollständig vor Session Hijacking. Session Fixation ist mit dieser Maß-
nahme nur noch 10 Minuten lang möglich. Denn der Angreifer benö-
tigt immer die Zufallszahl, die in der Session gespeichert ist. Außerdem
muss der Pool an Zufallszahlen auf dem Server existieren. Dieser wird
ja nach 10 Minuten Untätigkeit gelöscht.
Ein großer Nachteil dieses Ansatzes ist es, dass die »Back«-
Funktionalität des Browsers nicht mehr korrekt funktioniert. Beim
Zurückspringen auf eine Seite in der Historie des Browsers ist die
Zufallszahl bereits ungültig.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required