Session-Hijacking
Das Session-Hijacking ist die wohl häufigste Form des Session-Angriffs, und so wie bei der Fixation ist man verwundbar, wenn man nur session_start() nutzt.
Anstelle sich um die Frage zu kümmern, wie man eine Session-ID daran hindern kann, gestohlen zu werden, soll hier mehr auf die Frage eingegangen werden, wie man vorgehen kann, um das Stehlen von Session-IDs nicht so problematisch sein zu lassen. Das Ziel ist es, die Personalisierung zu verkomplizieren - denn jede neue Schwierigkeitsstufe bedeutet ein klein wennig mehr Sicherheit.
Um dies durchzuführen, werden die Schritte zum erfolgreichen Hijacking einer Session durchgegangen. In jedem der folgenden Beispiele wird davon ausgegangen, dass die Session-ID bereits bekannt ist.
Solange der einfachste Session-Mechanismus zum Einsatz kommt ist die jeweilige Session-ID das einzige, was man als potentieller Angreifer benötigt.
Um dies nun auszubauen sollte ein Blick auf die http Requests
geworfen werden, um zu sehen, ob dort erweiterte Informationen zur
Verfügung stehen:
Ein typischer http Request:
In diesem Request ist nicht verwertbares, das einzige was benötigt wird ist der HOST. Wie auch immer, das was benötigt wird ist ein zusammengehöriger Zugriff, da erstmal nur ein komplizierterer Mechanismus interessiert. Stellt man sich nun vor, ein anderer Browser, mit anderem USER_AGENT greift auf die Seite zu, dies könnte so aussehen:
Es wurde der gleiche Cookie, mit der gleichen Session-ID präsentiert – ist es also auch der gleiche Nutzer? Es erscheint sehr unwahrscheinlich, dass ein Browser während seiner Zugriffe den USER-AGENT ändert. Hieran kann man anknüpfen und den Session-Mechanismus um einen zusätzlichen Prüfmechanismus erweitern:
Hiermit muss ein Angreifer nun nicht nur eine gültige Session-ID
sondern auch noch den mit ihr verknüpften USER-AGENT fälschen. Das macht
die Sache etwas komplizierter und auch etwas sicherer.
Kann dies nun ausgebaut werden? Man bedenke, dass die meisten
Wege um Cookies (mit Session-IDs) zu erlangen über unsichere Browser
führen. Diese Exploits verlangen gerade, dass der User die Seite des
Angreifers in irgendeiner Form aufruft - und somit auch seinen
USER_AGENT an den Angreifer übermittelt. Eine zusätzliche Prüfung ist
also nötig. Der einfachste Weg wäre sicherlich, ein zufälliges Element
dem Ganzen hinzuzufügen. Um das ganze Prüfsystem nun etwas auszubauen,
ohne viel Arbeit zu haben, wird ein zufälliges Element an den jeweiligen
USER_AGENT gehangen: