cms-sicherheit.de | php security guide

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:

Zitat

GET / HTTP/1.1
Host: example.org
User-Agent: Mozilla/5.0 Gecko
Accept: text/xml, image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234

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:

Zitat

GET / HTTP/1.1
Host: example.org
User-Agent: Mozilla Compatible (MSIE)
Accept: text/xml, image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234

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:

Zitat

<?php
session_start();
if (isset($_SESSION['HTTP_USER_AGENT']))
{
if ($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT']))
{
/* Prompt for password */
exit;
}
}
else
{
$_SESSION['HTTP_USER_AGENT'] = md5($_SERVER['HTTP_USER_AGENT']);
}
?>

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:

Zitat

<?php
$string = $_SERVER['HTTP_USER_AGENT'];
$string .= 'SHIFLETT';
/* Add any other data that is consistent */
$fingerprint = md5($string);
?>