Session hijacking verhindern

DrBonsai

Mitglied
N'Abend zusammen,

ich bin nicht gerade ein großer Experte, was Sicherheit in php angeht.

Habe mich heute aber mal ein bisschen mit SESSION-hijacking befasst.

Wenn ich es richtig verstanden habe, sollte man dies verhindern, indem man vor jeder Abfrage prüft, ob der ausführende client, auf dem die login-session existiert, der Gleiche ist, auf dem die session eröffnet wurde, richtig?

Mein Ansatz ist deshalb der Folgende:

beim login merke ich mir einige Informationen des Browsers:
PHP:
/*Wenn Loginformular korrekt ausgefüllt wurde:*/
session_regenerate_id(); /*verhindert session-fixation*/
$_SESSION['fingerprint'] = md5($_SERVER['HTTP_ACCEPT'].$_SERVER['HTTP_USER_AGENT']); /*Informationen über browser der eingeloggten Person*/
Danach prüfe ich bei jedem Seiten-Aufruf, ob ein Nutzer eingeloggt ist und wenn ja, ob der Fingerabdruck des Nutzers dem entspricht, der beim Einloggen erstellt wurde.

PHP:
/*SESSION Hijacking verhindern bei jedem Seitenaufruf:*/
if(isset($_SESSION['client_id']) or isset($_SESSION['dealer_id'])) /*Wenn jemand eingeloggt ist*/
	{
	if($_SESSION['fingerprint'] != md5($_SERVER['HTTP_ACCEPT'].$_SERVER['HTTP_USER_AGENT'])) /*Wenn der user nicht auf dem Browser ist, auf dem die Session erstellt wurde*/
		{
		session_destroy();
		session_unset();
		session_write_close();
		setcookie(session_name(),'',0,'/');
		session_regenerate_id(true);
		header("Location: ./");
		}
	}

Ist das einigermaßen sicher, oder ist das blöder Unsinn?

mfg,
David
 
Hi

daran ist Einiges (viel?) auszusetzen.

Wenn ein Angreifer durch mitsniffen etc. die Session-ID bekommt, warum sollte er nicht auch HTTP_USER_AGENT und HTTP_ACCEPT bekommen können? ...schon alles umsonst.

MD5 ist unsicher.

(Ja, MD5 ist unsicher.)

Wie bestimmt deiner Meinung nach HTTP_USER_AGENT einen User eindeutig?
Es gibt viele User mit dem selben Browser.

Das Selbe gilt für HTTP_ACCEPT. Viele User haben den selben Wert.

Mit Prüfung auf HTTP_USER_AGENT kannst du auch berechtigte User aussperren.
(Variable Agents einstellbar, eine Installation auf mehreren OS uw.)

Auch hier das Selbe für HTTP_ACCEPT (sogar noch schlimmer).
Der Browser kann bei jedem Request etwas anderes schicken
(und ja, das ist nicht nur Theorie. Kenne keinen Browser, der immer "*/*" usw. hat).

(Und MD5 ist unsicher. :rolleyes:)

Eine der ganz wenigen vernünftigen Gegenßnahmen
(die einzige, die mir spontan einfällt) ist eine komplett verschlüsselte Übertragung.
HTTPS usw.
 
Das hier ist zb. die User-Session aus meinem Script:

PHP:
orwSetUserSession ($userinfo, $row['uid'], $row['uname'], $row['pass'], $row['status'], $row['group'], $row['email'], $row['helpdesc']);

Das Password ist ein SHA512-Hash, der Key "userinfo" sind alle Keys der Session als Serialisierter Wert, stimmt nach einem Seitenaufruf also nur 1 Wert nicht mehr, wird die Session zerstört (session_destroy)
 
Wenn ein Angreifer durch mitsniffen etc. die Session-ID bekommt, warum sollte er nicht auch HTTP_USER_AGENT und HTTP_ACCEPT bekommen können? ...schon alles umsonst.
Wenn ein Angreifer sniffen kann, braucht er die Session-ID sowieso nicht - dann könnte er ja genauso gut einfach gleich Benutzername + Passwort mitsniffen.

Du solltest in jedem Fall die IP Adresse des Clients abgleichen. Die lässt sich bei TCP-basierten Protokollen (wie HTTP) nämlich nicht spoofen, da sonst keine Verbindung zustande kommt. Damit hast du den Client zwar auch noch nicht identifiziert, weil es ja mehrere Rechner geben kann, die sich hinter dem selben Router (mit NAT) befinden, aber damit ist jedenfalls der Kreis der potentiellen Angreifer schon deutlich eingeschränkt.
 
Jep, das nervt - hat mich aber auch nicht davon abgehalten erst nach Wochen die Einstellungen zu ändern ^^
 

Neue Beiträge

Zurück