Wie verhindert Ihr Sessionübernahmen?

[Mike]

Hi,

folgendes Szenario. Eine Firma oder Internetcafe, also alle ein IP und gleiche Konfiguration.

User-A befindet sich, nach Login-Prüfung, auf meiner Seite. Er hat ein Cookie mit dem aktuellen Sessesion auf seinem PC-Platz. Nun kopiert User-B das Cookie und begibt sich ebenfalls auf meine Seite, wo er ja dann als bereits eingeloggter USER-A identifiziert wird.

Wenn ich jetzt nicht einen groben Denkfehler habe ist dieses Szenario möglich?

Aber wenn dem so ist, habe ich mir einige komplizierte Lösungen dazu ausgedacht, wovon aber keine einzige 100% verlässlich wäre.

Wie schützt Ihr euch davor?

Mike

[Beat]

folgendes Szenario. Eine Firma oder Internetcafe, also alle ein IP und gleiche Konfiguration.
User-A befindet sich, nach Login-Prüfung, auf meiner Seite. Er hat ein Cookie mit dem aktuellen Sessesion auf seinem PC-Platz. Nun kopiert User-B das Cookie und begibt sich ebenfalls auf meine Seite, wo er ja dann als bereits eingeloggter USER-A identifiziert wird.
Wenn ich jetzt nicht einen groben Denkfehler habe ist dieses Szenario möglich?

Ja

Aber wenn dem so ist, habe ich mir einige komplizierte Lösungen dazu ausgedacht, wovon aber keine einzige 100% verlässlich wäre.

In BdE-Online durch OneTimeSessionIDs.

mfg Beat

[Dennis]

Hi Mike,

Wenn ich jetzt nicht einen groben Denkfehler habe ist dieses Szenario möglich?

Ja, aber: Wie kommt User-B (Angreifer) an das Session-Cookie bzw. die Session-ID von User-A?

Dafür fallen mir spontan zwei Möglichkeiten ein:

* Session Fixation
   Die Session-ID wird vom Angreifer festgelegt, indem dieser seinem Opfer z.B.
   einen manipulierten Link unterschiebt, der bereits eine Session-ID enthält.
   Um dies zu verhindern solltest du immer session_regenerate_id() verwenden
   wenn der User andere oder mehr Rechte erhält, in deinem Fall also beim Login.

* Durch Sniffen des Netzwerktraffics
   Verwende HTTPS statt HTTP

Viele Grüße,
  ~ Dennis.

[Mike]

Hi Dennis,

»» Wenn ich jetzt nicht einen groben Denkfehler habe ist dieses Szenario möglich?

Ja, aber: Wie kommt User-B (Angreifer) an das Session-Cookie bzw. die Session-ID von User-A?

da fallen mir auf Anhieb einige Möglichkeiten ein, der Internetcafe Betreiber/Angestellte, der Kollege in der Firma der angeblich nur mal eben etwas am Rechner nachschauen will, Remotecontrol.....

Um dies zu verhindern solltest du immer session_regenerate_id() verwenden

Ja so ähnlich sah auch eine Lösung bei mir aus, hat aber den Nachteil, dass bei Inaktivität von User-A, weil eben zb. zu viel zu lesen auf einer Seite, User-B genügend Zeit hat zu übernehmen.

* Durch Sniffen des Netzwerktraffics
   Verwende HTTPS statt HTTP

Muss leider zugeben, dass ich keine Ahnung von HTTPS habe, habe es bisher bewusst vermieden wegen diesem Sicherheitszertifikat, das der User dann immer akzeptieren muss.

Aber wenn du mir sagst, dass dann eine solche Übernahme nicht stattfinden kann(?), beschäftige ich mich sofort damit.

Mike

[hotti]

hi,

Aber wenn du mir sagst, dass dann eine solche Übernahme nicht stattfinden kann(?), beschäftige ich mich sofort damit.

HTTPs (Secure Socket Layer) verschlüsselt die Verbindung. D.h., ein Cookieklau durch Sniffer auf der Leitung ist nicht mehr möglich gegenüber einer unverschlüsselten Verbindung.

Der Klau eines Cookie kann jedoch auch an Anderer Stelle erfolgen wo das nicht mit SSL abgedeckt ist. An Uwes Rechner z.B.

Hotte

[Vinzenz Mai]

Hallo,

folgendes Szenario. Eine Firma oder Internetcafe, also alle ein IP und gleiche Konfiguration.

was verstehst Du unter "gleicher Konfiguration"?
Welche Rolle spielt die (öffentliche) IP-Adresse?

User-A befindet sich, nach Login-Prüfung, auf meiner Seite. Er hat ein Cookie mit dem aktuellen Sessesion auf seinem PC-Platz. Nun kopiert User-B das Cookie

wie denn? Benutzer B hat keinen Zugriff auf das Cookie von Benutzer A.

Wenn ich jetzt nicht einen groben Denkfehler habe ist dieses Szenario möglich?

es erscheint mir nicht besonders wahrscheinlich. Bei vernünftiger Rechnerkonfiguration sollte das von Dir skizzierte Szenario für normale Benutzer nicht möglich sein.

Freundliche Grüße

Vinzenz

[ChrisB]

Hi,

Welche Rolle spielt die (öffentliche) IP-Adresse?

Sie verhindert wohl das Einbeziehen der IP in die Überprüfung, ob es sich um den "selben" Nutzer handelt - wie sinnvoll auch immer man das überhaupt finden mag.

MfG ChrisB

[Mike]

Hi,

»» Welche Rolle spielt die (öffentliche) IP-Adresse?

Sie verhindert wohl das Einbeziehen der IP in die Überprüfung, ob es sich um den "selben" Nutzer handelt - wie sinnvoll auch immer man das überhaupt finden mag.

Mir war schon klar das Vincent darauf zielte und ich dachte darauf zu reagieren wäre unnötig. Aber nun denn...

Natürlich bietet eine IP keine "einzige" Möglichkeit der Überprüfung, und wenn mein Szenario genau  dieses Problematik einbezieht eben gleiche IP, frage ich mich warum Vincent trotzdem darauf anspringt wie ein Hund auf Knochen ;-)

Trotzdem ist die IP-Einbeziehung  gerade bei Session eine Überlegung wert, denn man kann zwar Proxys nutzen aber man kann selten, es sei denn wie in meinem Szenario, als Angreifer die IP des Opfers wählen.

Somit ist "if(ip_user != ip_angreifer)..." durchaus als Möglichkeit anzusehen. Der einzige Nachteil, der dabei passieren kann, sind wechselnde IP's innerhalb der einen Session. Da würden die User dann zum erneuten Einloggen aufgefordert.

Jetzt stellt sich nur die Frage wie oft kommt dieser Nachteil wirklich zum Tragen.

Mike

[Jens Holzkämper]

Tach,

Somit ist "if(ip_user != ip_angreifer)..." durchaus als Möglichkeit anzusehen. Der einzige Nachteil, der dabei passieren kann, sind wechselnde IP's innerhalb der einen Session. Da würden die User dann zum erneuten Einloggen aufgefordert.

Jetzt stellt sich nur die Frage wie oft kommt dieser Nachteil wirklich zum Tragen.

bei AOL meines wissens weiterhin dauerhaft, da läuft alles über transparente Proxies.

mfg
Woodfighter

[Tom]

Hello,

Jetzt stellt sich nur die Frage wie oft kommt dieser Nachteil wirklich zum Tragen.

bei AOL meines wissens weiterhin dauerhaft, da läuft alles über transparente Proxies.

Wie sieht es denn da mit $_SERVER['HTTP_FORWARDED'] aus? Wird das zur Verfügung gestellt und was steht drin?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Jetzt stellt sich nur die Frage wie oft kommt dieser Nachteil wirklich zum Tragen.

bei AOL meines wissens weiterhin dauerhaft, da läuft alles über transparente Proxies.

Wie sieht es denn da mit $_SERVER['HTTP_FORWARDED'] aus? Wird das zur Verfügung gestellt und was steht drin?

... oder $_SERVER['HTTP_X_FORWARDED_FOR']

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hi Tom,

»» Wie sieht es denn da mit $_SERVER['HTTP_FORWARDED'] aus? Wird das zur Verfügung gestellt und was steht drin?

... oder $_SERVER['HTTP_X_FORWARDED_FOR']

Die Variable HTTP_X_FORWARDED_FOR kann von einem Proxy-Server gesetzt sein.
Kann, muss jedoch nicht.

Die Proxies, die ich so verwende, machen das und geben auch ein
HTTP_VIA mit.

In der CGI-Umgebung hinter einem Proxy siehst Du also bspw.:
1.REMOTE_ADDR            217.237.148.103
2.HTTP_X_FORWARDED_FOR   217.233.172.64
3.HTTP_VIA               1.1 n-cw-a01.isp.t-ipnet.de:80 (squid/2.5.STABLE12)

1. ist die IP Addr vom ProxyServer
2. ist meine IP Addr vom Dial In (DSL-Provider)
zu 3. schauen wir mal in den DNS:

D:>nslookup
Standardserver:  s-lb-a01.isp.t-ipnet.de
Address:  217.237.151.142

n-cw-a01.isp.t-ipnet.de

Server:  s-lb-a01.isp.t-ipnet.de
Address:  217.237.151.142

Nicht autorisierte Antwort:
Name:    n-cw-a01.isp.t-ipnet.de
Address:  217.237.148.103

Nice Try, but no Cigar ;-)

Hotte

[Beat]

Trotzdem ist die IP-Einbeziehung  gerade bei Session eine Überlegung wert, denn man kann zwar Proxys nutzen aber man kann selten, es sei denn wie in meinem Szenario, als Angreifer die IP des Opfers wählen.
Somit ist "if(ip_user != ip_angreifer)..." durchaus als Möglichkeit anzusehen. Der einzige Nachteil, der dabei passieren kann, sind wechselnde IP's innerhalb der einen Session. Da würden die User dann zum erneuten Einloggen aufgefordert.

Ich möchte es so beurteilen.
Eine IP kann sich ändern während einer Session. Ich beobachte das bei mir und bei anderen. Selbst wenn ich die IP nur im IP/16 Bereich als zusätzliche Prüfung einbeziehe, kann dies den Unterbruch einer Session bedeuten.

Wir sind hier mehrere Leute, die über WLAN den gleichen Internetzugang verwenden. Hierbei werden meiner Beobachtung nach bis zu einem halben Dutzend IP/16 Bereiche verwendet, womöglich noch mehr. Es ist nicht ausgeschlossen, dass zwei Anwender hier den gleichen IP/16 Bereich zugewiesen erhalten.

Wenn du die IP also mitberücksichtigen willst, dann müsste dies ein vom User zusätzlich aktiviertes Feature sein, denn nur er kennt das Verhalten seiner IP.

Was die Problematik von Login via Internetcafe angeht, kann es keine Sicherheit geben, denn ein Passwort an dieser Stelle eingegeben kann per se durch einen Keylogger gespeichert werden.
Hier helfen nur sogenannte Wegwerf-Passworte (One-Time-Passwords).

mfg Beat

[hotti]

hi,

Wenn ich jetzt nicht einen groben Denkfehler habe ist dieses Szenario möglich?

Ja, das ist möglich und auch machbar.

Ein Cookie als Unterscheidungsmerkmal verschiedener PCs ist eben doch nicht atomar sondern teilbar.

Wie schützt Ihr euch davor?

Gar nicht, weils nichts gibt, sich davor zu schützen.
User-A wird in jedem Fall schuldig gesprochen und erschossen, basda.

Hotte

[Tom]

Hello,

Wenn ich jetzt nicht einen groben Denkfehler habe ist dieses Szenario möglich?

Ja, das ist möglich und auch machbar.

Ein Cookie als Unterscheidungsmerkmal verschiedener PCs ist eben doch nicht atomar sondern teilbar.

Ganz im Gegenteil: Ein Cookie als Unterscheidungsmerkmal verschiedener PCs ist atomar und doch nicht teilbar. Wenn es teilbar wäre, könnte die eine Hälfte gegen die andere verifiziert werden, was insbesondere beim Hinzutreten der Zeit für die Gültigkeitsdauern der Hälften als relativ sichere Methode (außer gegen direktes abhören) gerechnet werden kann.

Wenn nun zur einen Hälfte z.B. drei Mal die falsche andere Hälfte mitgeschickt wird, werden beide gesperrt. Das führt zwar auch zum logischen Verbindungsabbruch der führenden einen richtigen Hälfte oder sogar beiden, aber die können sich ja mittels ihrer passenden Teile sofort wieder anmelden und bekommen eine Warnung, dass ihre Verbindung gestört wurde.

Wenn man nun beide Hälften mit derselebn Anfrae auf unterschiedlichen Wegen transportieren lässt und diese erst im Ziel wieder montieren lässst, hat man die Sicherheit nochmals erhöht. Besser wäre dann noch Verschlüsselung für die Übermittlung.

Wie schützt Ihr euch davor?

Gar nicht, weils nichts gibt, sich davor zu schützen.
User-A wird in jedem Fall schuldig gesprochen und erschossen, basda.

Hotte

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg