Session Hijacking verhindern
Donnerstag, 22. Oktober 2009, 12:35 Uhr | Autor: ich
Ich möchte vorausschicken, ich bin kein studierter Informatiker, daher bitte ich um Nachsicht wenn das Geschriebene vollkommener Unsinn sein sollte.
Wie würde ich versuchen Session Hijacking zu unterbinden?
1.
Die häufigste Möglichkeit um an eine Session-ID zu gelangen ist Cross-Site Scripting in Verbindung mit JavaScript. Wenn ein mögliches Opfer also JavaScript im Browser aktiviert haben muss, um angreifbar zu sein, so gibt es auch die Möglichkeit, per JavaScript einen Fingerprint zu erstellen.
Für den möglichen JavaScript-Fingerprint benutzen wir Daten, die sich i.d.R. bei dem Besuch einer Website nicht ändern:
- screen.width
- screen.height
- navigator.plugins.length
- navigator.plugins[i].name
- navigator.plugins[i].description
- navigator.plugins[i].filename
- navigator.userAgent
Aus diesen Daten erzeugen wir einen Hash, der zu der Session-ID gespeichert wird. Während des Besuchs des Users wird ein Fingerprint-Hash live erzeugt und mit dem Hash aus der Session-ID verglichen. Sobald die Session-ID des legitimen Users und der Live-Fingerprint-Hash nicht mehr zueinander passen, wird von einem Angriff ausgegangen und die entprechende Maßnahme ergriffen.
Diese Art eines Schutzes gegen Session Hijacking wird auf verschiedenen Websites eingesetzt, welcher aber dazu führt, dass ein User nur mit einem Browser zur selben Zeit angemeldet sein kann, was u.U. für den User lästig ist.
Ein Angreifer könnte zudem genau die Daten die wir für den Fingerprint benutzen per XSS auslesen und dem Server senden, um doch erfolgreich zu sein.
2.
Eine weitere Information für einen Fingerprint ist die IP-Adresse des Besuchers. Auch hieraus können wir einen Hash erzeugen und der Session mit auf den Weg geben, um sie immer wieder zu überprüfen. Je nach Provider oder auch eigenen Sicherheitsmaßnahmen wie z.B. JonDonym (jondos.de) oder andere Proxys, kann dies aber zu unerwünschten Logouts führen. Ein User der immer wieder aus dem System fliegt, wird den Schutz abschalten. Also ist dies auch eine eher nicht so gute Maßnahme gegen Session Hijacking.
3.
In PHP gibt es mit session_regenerate_id(true) die Möglichkeit die Daten einer Session auf eine neue Session zu übertragen und dabei die alte Session-ID inkl. aller dazugehörigen Daten zu löschen. Von der Änderung der Session wird der legitime User nichts bemerken, aber ein Angreifer wird aus dem System geworfen. Wo und wie häufig man die Session wechselt, sollte man an das jeweilige System anpassen. Der Sessionwechsel muss schon recht häufig erfolgen, damit dieser Schutz wirklich greift.
4.
Bei dem ersten Besuch eines Users wird ihm eine Session-ID gegeben und in der Datenbank gespeichert. Sobald der User sich in das System einloggt, wird ihm eine neue Session-ID gegeben. Der Datensatz zu dem User besteht also aus:
- Session-ID: 123456 – noch nicht eingeloggt
- Session-ID: 789012 – als legitimer User eingeloggt
Ein möglicher Angreifer bekommt auch bei dem ersten Besuch eine Session-ID, die ebenfalls in der Datenbank gespeichert wird. Sollte er, durch welche Lücke auch immer, die aktuelle Session-ID seines Opfers ausspähen können und versuchen diese zu benutzen, so sieht sein Datensatz wie folgt aus:
- Session-ID: 345678 – noch nicht eingeloggt
- Session-ID: 789012 – ohne Login
Voraussetzung für den erfolgreichen Schutz ist natürlich, dass ein Angreifer die erste Session-ID nicht vorgeben kann, aber dies sollte eh nie möglich sein.
Wie man sieht gibt es verschiedene Ansätze um Session Hijacking zu unterbinden.
Update: 19.11.2009 – 22:15 Uhr
Punkt 4: Bullshit, so einfach ist es nun doch nicht, Session Hijacking zu verhindern :O)
Donnerstag, 22. Oktober 2009, 22:32 Uhr
Ohne mich hier zu sehr zu engagieren (Fachleute lesen mit), komme ich nicht umhin festzustellen, dass Du in Nr. 4 eine findbare (da stark frequentierte) Datenbank hast. Eine auf die täglich (vermutlich) zig tausendfach zugegriffen wird. Auch eine bei der der Nutzer zumindest für das ihn verwaltende System identifizierbar sein muss (fingerprint etc.?).
Ergo ist auch das angreifbar, richtig?
Freitag, 23. Oktober 2009, 10:06 Uhr
Sorry, aber ich weiß jetzt leider nicht was du meinst.
Was meinst du mit “findbare Datenbank”? Die Session-IDs werden im Cookie gespeichert und nicht in der URL übertragen.
“findbar” im Sinne von Google-Suche?
Oder meinst du die Last am Datenbankserver wird zu hoch?
Die erste Session-ID wird, nach dem Login, in der Datenbank gespeichert, wie auch z.B. die Nachrichten von anderen Usern, Timestamp des letzten Besuchs etc. Die zweite Session-ID wird im Cookie gespeichert. Mit beiden Session-IDs ist der User identifizierbar.
Wahrscheinlich meinst du etwas vollkommen anderes und ich verstehe es nur nicht… Deswegen der einleitende Satz. :O)
Freitag, 23. Oktober 2009, 17:09 Uhr
Nein, nein. Ist schon in Ordnung. Ich verfolgte einen anderen Ansatz. Unter der von dir genannten Prämisse sollte es gut funktionieren.
Es ist komplex
Freitag, 23. Oktober 2009, 17:10 Uhr
Ich meine übrigens nicht das man den Kram zwingend studiert haben muss. Ein Studium ändert nichts daran das wir hier über I/O reden. Nicht mehr, aber auch nicht weniger
Freitag, 23. Oktober 2009, 18:08 Uhr
Wenn du einen anderen Ansatz verfolgt hast, dann habe ich es nicht eindeutig genug erklärt, passiert mir leider immer wieder.
Wenn ich mir die Bekannten mit Informatik-Studium und z.T. Doktortitel anschaue… Ein solches Studium kann auch schädlich für das allgemeine IT-Verständnis sein. ;O)
Freitag, 23. Oktober 2009, 18:31 Uhr
Aarrrg….!
Grün, grün, grüner als grün!
Piiiiiieeep, britzel, knatter, knatter:
2
+
2
=
3,988795
Da können wir ja schon fast von 4 ausgehen.
Gut Müller, machen Sie es so!
Samstag, 24. Oktober 2009, 11:29 Uhr
zu 1: die idee ist nicht schlecht (obgleich etwas wacklig). die schwäche der methode nennst du ja selbst.
zu 2: bitte nicht – diese “sicherheitsmasznahme” wurde bereits x mal (in den foren dieser welt) diskutiert und als wertlos – da unpraktikabel – eingestuft.
zu 3: session_regenerate_id schützt NICHT gegen session hijacking. wer die serverseitige id-regen auslöst (legitimierter user oder angreifer) ist banane. als schutz gegen session Fixation allerdings gut zu gebrauchen; wird i.d.r. nach einem erfolgreichen user-login durchgeführt.
zu 4: interessant…
cx
Samstag, 24. Oktober 2009, 13:43 Uhr
Punkt 2 hatte ich nur für StudiVZ aufgelistet, da diese Methode dort, mit den bekannten Schwächen, im Einsatz ist. ;O)
Punkt 3 fand ich im Netz, welcher mich aber auch nicht so wirklich überzeugte, deswegen Punkt 4.
Mein Favorit ist bestimmt nicht neu, aber zumindest konnte ich dazu im Netz nichts finden.
Montag, 26. Oktober 2009, 10:59 Uhr
Punkt 4 check ich nicht. Ein Session-Hijacker wird doch versuchen sein Opfer so gut wie möglich zu imitieren, sprich all die geklauten Cookies an den Server schicken und doch keine die er vorher selber gesammelt hat. Wie erkennt man denn da, dass der Angreifer vorher die Session-ID 345678 gehabt hat?
Dienstag, 27. Oktober 2009, 10:15 Uhr
Da muss ich wohl noch einmal in mich gehen und ein PoC basteln, evtl. ist es ja doch unsinnig was ich da gedacht habe.
Dienstag, 27. Oktober 2009, 13:40 Uhr
hier ein link zum kapitel “session” in “php sicherheit” von s. esser: http://www.dpunkt.de/leseproben/3-89864-369-7/Kapitel_7.pdf
punkt 4 deiner liste erinnert mich nämlich ein bissel an das “page ticket system”… bin allerdings auch noch nicht dazu gekommen / habe nicht nochmal daran gedacht, deine idee zu überdenken .-
cx
Donnerstag, 29. Oktober 2009, 11:56 Uhr
Vielen Dank für diesen aufschlussreichen Post. Toll dass es durch Solche die Möglichkeit gibt, sich “passiv” weiterzubilden.
Sollte Ansatz 4 nicht den gewünschten Effekt haben wäre es gut, wenn der Post entsprechend geändert wird
Wie du schon richtig im StudiVZ-Post vermutest lesen nicht Alle die Kommentare mit.
Vielen Dank!
Florian
Donnerstag, 29. Oktober 2009, 12:38 Uhr
Leider hatte ich noch keine Zeit um meine Hirnwindungen zu entwirren, um den Punkt 4 einmal genau zu prüfen, sobald ich dies erledigt habe kommt natürlich das Kondensat dazu. :O)
Dienstag, 3. November 2009, 7:59 Uhr
habe nochmal über punkt 4 nachgedacht… die methode bringt imho nichts: ein user wird nach wie vor über eine eindeutige id identifiziert – bspw. das session-cookie. dies wäre dann auch die id des dazugehörigen datensatzes. mit der übernahme der session durch den angreifer wird also auch die session-id-history übernommen.
das grundlegende problem bleibt die (eindeutige) identifizierung des users auf grundlage einer session. es spielt keine rolle, was und wieviel ich drumherum baue… das ganze wird einfach nicht sicherer. um es mal mit esser’s worten auszudrücken: (siehe verlinkung in post 11): “das session-system von php kann mit einfachen mitteln sicherer gemacht werden, ein kompletter Schutz ist aber nahezu unmöglich.”
cx