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:

1. Session-ID: 123456 – noch nicht eingeloggt
2. 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:

1. Session-ID: 345678 – noch nicht eingeloggt
2. 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. Mein letztes Beispiel scheint mir am effektivsten zu sein, da es wohl kaum auszuhebeln ist.


Update: 19.11.2009 – 22:15 Uhr

Punkt 4: Bullshit, so einfach ist es nun doch nicht, Session Hijacking zu verhindern :O)

Mein “schöner Blödsinn”, wie jemand so eloquent meinte, hat nun wohl dazu geführt, das studiVZ einen IP-Schutz in den Loginvorgang eingebaut hat,

welcher aber wieder nur ein weiterer Eimer unter ein undichtes Dach bedeutet.

Einen Schutz einzubauen, der nur alleine auf die IP-Adresse abgerichtet ist, ist viel zu kurz gedacht.

Bleiben wir mal bei dem Beispiel studiVZ. Wer meldet sich dort an? Es werden wohl am häufigsten Studenten sein. Hat jeder Student eine eigene Wohnung mit eigenem DSL-Zugang? Ich bin zwar schon lange aus diesem Alter raus, aber ich nehme doch mal an, dass viele Studenten in Wohngemeinschaften oder Studentenwohnheimen leben, die nur über einen DSL-Zugang bzw. über eine IP-Adresse ins Netz gehen. Was machen nun diese Studenten? Ja, sie müssen den Schutz abschalten.

Update: 13:00 Uhr
Ich hebe den Kommentar mal nach oben, für die die nicht bis zu den Kommentaren lesen, denn diese Info scheint mir wichtig zu sein:

Nein, niemand muss den Schutz abschalten. Nur falls sein Ausgang ins Netz die IPs wechselt (NAT, Proxy-Farmen). Ansonsten funktioniert das Feature wie gewollt und erhöht die Sicherheit.

Ich hatte Probleme mit gleicher IP-Adresse bei verschiedenen Accounts, deswegen meine Annahme.

Hätten die Jungs von studiVZ nur 30 Sekunden ihre mitgelieferten grauen Zellen benutzt und weitere 30 Sekunden für die Implementierung, dann könnten sich auch die Studenten, die nur über einen Gemeinschaftsanschluss im Internet surfen können, über einen weiteren Schutz freuen.