[PHP] Session Hijacking (spez. Frage)

Aziz

Session Hijacking ist zwar ein Problem, aber bei PHP wird zusätzlich zu der SID auch noch ein Teil der IP gespeichert. Ein Teil deshalb, weil AOL hier ein verdammtes Problem darstellt. Denn bei AOL kann sich die IP während einer Session ändern, das ist gift für online-security

Das ist mir neu. Ich mein, das mit AOL weiß ich von diversen Texten im Internet, aber, dass PHP einen Teil der IP in Verbindung mit der SID speichert wusste ich nicht. Hast du dafür eine Quelle?

Session Hijacking kann ziemlich effektiv beschnitten werden, indem man nur Cookies verwendet. Denn die meisten Hijacking Situationen sind die: Jemand browst in einem Forum und gibt dann einen Link auf einen interessanten Beitrag im IRC weiter. Leider verwendet er keine Cookies sondern hat die SID in der URL -> Peng, jeder kennt seine SID.

Ganz genau. Ich setze bei meinem Loginsystem Cookies voraus, weil es ziemlich unschön aussieht wenn sich eine SID in der URL herumtummelt (selbst bei Gästen übergebe ich keine SID per URL). Ich will nämlich, dass der User die Links auf meiner Seite ohne die URL umständlich editieren zu müssen zu den Lesezeichen hinzufügen kann. Denkst, du dass es viele User gibt, die einfach darauf bestehen keine Cookies zu verwenden? Kann es dafür einen seriösen Grund geben? Außer man ist paranoid und will nicht, dass manche Seiten das eigene Surfverhalten verfolgen?

Das ist dank der IP Sperre kein kritisches Problem und kommt somit nur selten vor. ...
Einige Leute nehmen deswegen noch andere Daten des Users in die Session auf, zB User-Agent, was er alles Accpet'ed etc. Aber das ist riskant, weil sich das während der Session ändern kann... Also lieber die Finger davon.

Naja, ob sich der User-Agent String ändern kann, hängt stark vom Browser ab. Opera erlaubt ja einem zwischen den UAs Opera, Mozilla und IE zu wechseln. Aber wieviele User machen das schon während sie auf einer Seite eingeloggt sind und herumsurfen? Selbst wenn sie es tun würden, dann würde mein Auto-Login-System den User wieder automatisch einloggen (vorausgesetzt er/sie hat diese Option beim Einloggen gewählt).

**Gefährlicher ist (ich habe den Namen vergessen, uU Session Intrusion oder so). Hierbei geht es darum Cookies auszunutzen. Wenn ich hier im Forum per Cookie eingelogt bin, dann habe ich ein Cookie. Nun kann jemand anderes auf seiner Seite folgenden Link zB per JS öffnen, oder mich sonst irgendwie zu verleiten dem Link zu folgen: www.c-plusplus.net/forum/delete.php?action=delete_whole_forum

Da ich ein legales Cookie habe, wird sich das C++ Forum meiner Anweisung beugen, schließlich ist es eine legale Anfrage und ich habe die Rechte dazu (in dieser hypothätischen Situation) und Peng, das Forum ist weg.**

Was du beschreibst ist ja mehr oder weniger eine XSS-Attacke, nicht?

Und ein kleiner Merksatz am Ende:
Immer wenn es bei dem User eine Rechteänderung gab (zb hat sich eingeloggt etc.) -> NEUE SESSIONID GENERIEREN

Hehe, genau das mache ich bei meinem Login-Script. Damit lassen sich hervorragend Session-Fixation-Attacken vermeiden

**@SideWinder:
die meisten Session-Systeme sind aus einer Zeit wo PHP noch keine Sessions hatte, ...

Aber soetwas wie PHPBB ist sinnlos, es ist halt einfach altlast (so hoffe ich zumindest ;))**

Ich persönlich fand zwei Dinge an PHP Sessions unbefriedigend. Erstens: Man kann nicht nach Belieben neue Session-ID's generieren. Es gibt da zwar session_regenerate_id(), aber die Funktion geht nur während eine Session aktiv ist und außerdem sendet sie ein neues Cookie an den Client. Warum gibt's da nicht einfach sowas wie "string generate_new_sid()" (hab mir da eine Funktion von phpBB als workaround abgeschaut). Zweitens: PHP Sessions verwenden eine eigene Methode um das $_SESSION Array zu serialisieren. Da ich meine Sessions in einer MySQL Tabelle speichere, hätte ich mir gewünscht eine Möglichkeit zu haben Daten anzuhängen bevor ich sie in die Tabelle schreibe. Was mir da übrig bleibt ist, das Format der Serialisierung nachzuahmen (was bei normalen Strings nicht so schwierig ist).

Shade Of Mine

Kleine Anmerkung: bitte [ quote ] statt [ b ] fürs zitieren, danke

Aziz schrieb:

Das ist mir neu. Ich mein, das mit AOL weiß ich von diversen Texten im Internet, aber, dass PHP einen Teil der IP in Verbindung mit der SID speichert wusste ich nicht. Hast du dafür eine Quelle?

Ja, session.c in ext/session in der PHP source, zeile 630 und folgende Funktion: php_session_create_id.
Ich zitiere mal kurz (+erklärende Kommentare von mir):

//wenn vorhanden, wird remote_addr gesetzt
	if (zend_hash_find(&EG(symbol_table), "_SERVER",
				sizeof("_SERVER"), (void **) &array) == SUCCESS &&
			Z_TYPE_PP(array) == IS_ARRAY &&
			zend_hash_find(Z_ARRVAL_PP(array), "REMOTE_ADDR",
				sizeof("REMOTE_ADDR"), (void **) &token) == SUCCESS) {
		remote_addr = Z_STRVAL_PP(token);
	}

//...

//hier wird buf (scheiss name) zusammengesetzt, buf ist hier die rohe session id
	sprintf(buf, "%.15s%ld%ld%0.8f", remote_addr ? remote_addr : "", 
			tv.tv_sec, tv.tv_usec, php_combined_lcg(TSRMLS_C) * 10);

//...
//hier wird buf MD5 verschlüsselt
		PHP_MD5Init(&md5_context);
		PHP_MD5Update(&md5_context, buf, strlen(buf));
		digest_len = 16;
//...
//erklärt alles, oder?
	return buf;

Ganz genau. Ich setze bei meinem Loginsystem Cookies voraus, weil es ziemlich unschön aussieht wenn sich eine SID in der URL herumtummelt (selbst bei Gästen übergebe ich keine SID per URL). Ich will nämlich, dass der User die Links auf meiner Seite ohne die URL umständlich editieren zu müssen zu den Lesezeichen hinzufügen kann. Denkst, du dass es viele User gibt, die einfach darauf bestehen keine Cookies zu verwenden? Kann es dafür einen seriösen Grund geben? Außer man ist paranoid und will nicht, dass manche Seiten das eigene Surfverhalten verfolgen?

Ich verwende das PHP Prinzip: also Cookie wenn möglich, URL wenn keine Cookies vorhanden. Gäste bekommen keine Session. Wozu auch? Das schreckt ja nur Suchmaschinen ab...

Die Gefahr eines Session Hijacking besteht dank der IP Sperre ja eher nicht. Deshalb mache ich mir da keine so großen Sorgen. Zumal ich die essentiellen Funktionen ja noch zusätzlich sichere.

Es gibt aber viele Leute die aus den genannten Gründen nur Cookies verwenden... Also verstehe ich diese Entscheidung durchaus.

Naja, ob sich der User-Agent String ändern kann, hängt stark vom Browser ab. Opera erlaubt ja einem zwischen den UAs Opera, Mozilla und IE zu wechseln. Aber wieviele User machen das schon während sie auf einer Seite eingeloggt sind und herumsurfen? Selbst wenn sie es tun würden, dann würde mein Auto-Login-System den User wieder automatisch einloggen (vorausgesetzt er/sie hat diese Option beim Einloggen gewählt).

Auto-login ist ein eigenes Kapitel Da kann man auch viel falsch machen.

Aber das Problem mit User-Agent, etc. sind zu aggresive Webwasher. Diese sind natürlich doof und bringen keinen wirklichen Vorteil - aber viele Leute stehen darauf.

Und manchmal muss man den User-Agent wegen einer doofen seite ändern. Doch dann ändert er sich ja auch für die gute Seite, wo man eingeloggt bleiben will - dann fliegt man dauernd raus -> doof.

Was du beschreibst ist ja mehr oder weniger eine XSS-Attacke, nicht?

Nein, nicht ganz. XSS ist, wenn ich einen Fehler in der Seite ausnütze um zB die Cookie daten oder ähnliches auszulesen.

Bei dem was ich beschrieben habe (mir fällt der name immer nocht nicht ein *grml*) geht es darum, dass JEDE seite dafür anfällig ist. Weil ein User mit legalen Rechten dazu 'gelinkt' wird, etwas zu tun, was er garnicht will. Der Angreifer erfährt keine Daten über den User oder die Seite - es wird lediglich eine Aktion mit den Rechten des Opfers ausgeführt. Sinnvolle Sicherungen gibt es kaum (ausser jede wichtige aktion nochmal durch eine Form oA absichern).

Nimm zB folgendes Beispiel:
Wenn jemand im IRC einen Link zu unserem Moderatoren Forum postet - wir beiden klicken drauf. Du bekommst die "Zugriff verweigert"-Seite, ich bin aber drinnen. Das ist das selbe prinzip wie ich beschrieben habe -> wenn ich statt dem Forum-anzeigen jetzt einen Link auf topic-loschen hätte, dann würde ich versehentlich das Thema löschen, während du wieder ein zugriff verweigert bekommst. Der Angreifer hat aber keine Daten - was der Hauptpunkt bei XSS ist...

Nunja, aber im Prinzip sind sich diese Angriffe natürlich ähnlich. Nur schützt man sich komplett unterschiedlich dagegen. XSS ist leicht auszuschalten: Don't trust the User. Aber diese "Session Intrusion" (oder wie es auch immer heissen mag) ist doofer, denn ein "Don't trust the User" reicht nicht, weil es alles was passiert völlig legal und vorgesehen ist. zB ein Topic löschen. Ich habe die Rechte dazu und es soll auch so sein, dass ich Topics hin und wieder lösche. Das einzige was der unterschied zwischen einem Angriff und einem gewollten löschen ist, ist der dass es der User einmal absichtlich und einmal unabsichtlich macht -> keine chanze für den Admin feststellen ob das jetzt ein angriff war oder ob der User das wirklich wollte.

Hehe, genau das mache ich bei meinem Login-Script. Damit lassen sich hervorragend Session-Fixation-Attacken vermeiden

Hervorragend vielleicht nicht, aber dennoch ziemlich gut

Ich persönlich fand zwei Dinge an PHP Sessions unbefriedigend. Erstens: Man kann nicht nach Belieben neue Session-ID's generieren. Es gibt da zwar session_regenerate_id(), aber die Funktion geht nur während eine Session aktiv ist und außerdem sendet sie ein neues Cookie an den Client. Warum gibt's da nicht einfach sowas wie "string generate_new_sid()" (hab mir da eine Funktion von phpBB als workaround abgeschaut).

Was versprichst du dir davon?
Ich meine, du kannst die Session ID ja auch selber generieren wenn du unbedingt willst...
Aber wozu willst du die SID kennen ohne sie auf die Session anzuwenden? Ist mir momentan nicht ganz klar. Vielleicht übersehe ich ja etwas

Zweitens: PHP Sessions verwenden eine eigene Methode um das $_SESSION Array zu serialisieren. Da ich meine Sessions in einer MySQL Tabelle speichere, hätte ich mir gewünscht eine Möglichkeit zu haben Daten anzuhängen bevor ich sie in die Tabelle schreibe. Was mir da übrig bleibt ist, das Format der Serialisierung nachzuahmen (was bei normalen Strings nicht so schwierig ist).

Mhm? Das ist mir auch nicht klar.
Du hast die Daten von dem $_SESSION array - und was willst du dann mit denen noch machen? Daten anhängen? Welche und warum?

Zugegeben, ich habe schon öfters über ein intelligentes session system nachgedacht, dass nur die Daten ausliest, die diese Seite wirklich braucht - nur ist das performance mäßig nicht wirklich besser als die PHP methode, obwohl es technisch cooler ist Dieses System ist recht interessant als ergänzung zu den PHP Sessions, zB für Übersetzungen einer GUI -> nur die Daten werden geladen, die gebraucht werden.

Unix-Tom

Das Problem mit den NUR Cookies ist das gleiche vie mit Tabellenlayout oder JS.

Du sperrst einige User aus wenn du keine Alternative hast.
Es sei jedem selbst überlassen ob er das will.
Für Profiseiten ist es jedoch keine Lösung. Was wenn der User ohne Cookies gerade der Investor ist, welcher einen Millionenauftrag hat.

Manche sprechen hier nicht von Homepage sondern von Website.
Auf einer Homepage hat man oft nicht so wichtigen Content der geschützt werden muss und es kann einem egal sein ob ein User die Seite nutzen kann oder nicht.

flenders

Shade Of Mine schrieb:

Das einzige was der unterschied zwischen einem Angriff und einem gewollten löschen ist, ist der dass es der User einmal absichtlich und einmal unabsichtlich macht -> keine chanze für den Admin feststellen ob das jetzt ein angriff war oder ob der User das wirklich wollte.

Könnte man da nicht evtl. über Refferer (ggf. auch Serverseitig einfach in der Session mitprotokollieren, wo der User zuletzt war). Damit könnte man zumindest das Risiko etwas minimieren. Oder eben einfach nochmal eine zusätzliche Nachfrage Ja/Nein...

Aziz

Eine interessante Diskussion bisher. Ob ich nun Cookies zur Voraussetzung für die Anmeldung machen will, werde ich mir nochmal gründlich überlegen.

Es gibt ja wie besprochen Nachteile wenn man den User-Agent und vielleicht noch andere Client-Daten (komplette IP, HTTP_ACCEPT_LANGUAGE etc.) zur Sicherung der Session verwendet. Wäre es da aber keine gute Idee den User beim Loginformular entscheiden zu lassen, ob diese Art der Sicherung geschehen soll? Zumindest wäre dies für Websiteadmins eine Überlegung wert, weil der meistens mehr Verständnis vom Technikkram hat.
Eine Alternative wäre, diese Option im User-Profil zu speichern (vll. bei der Registrierung abfragen). Aber falls diese Option Probleme machen sollte, so dass bei jedem Seitenaufruf die Session für ungültig erklärt wird, dann hätte der User Schwierigkeiten diese Option wieder zu deaktivieren. Alles in allem scheint diese Funktion mehr Benutzerunfreundlichkeit als Nützlichkeit zur Konsequenz zu haben, jedoch denke ich, dass es vll. für höhergestellte Mitglieder der Webseite (wie Admins, Mods etc.) eine interessante Möglichkeit zur Sicherung der Sessions darstellen könnte.

Nunja, aber im Prinzip sind sich diese Angriffe natürlich ähnlich. Nur schützt man sich komplett unterschiedlich dagegen. XSS ist leicht auszuschalten: Don't trust the User. Aber diese "Session Intrusion" (oder wie es auch immer heissen mag) ist doofer, denn ein "Don't trust the User" reicht nicht, weil es alles was passiert völlig legal und vorgesehen ist. zB ein Topic löschen. Ich habe die Rechte dazu und es soll auch so sein, dass ich Topics hin und wieder lösche. Das einzige was der unterschied zwischen einem Angriff und einem gewollten löschen ist, ist der dass es der User einmal absichtlich und einmal unabsichtlich macht -> keine chanze für den Admin feststellen ob das jetzt ein angriff war oder ob der User das wirklich wollte.

Ich hab mir Gedanken darüber gemacht, wie man solche ungewollten Aktionen seitens der Admins/Mods abwehren könnte. Im Prinzip würde ein Skript (das gegen solche Angriffe verwundbar wäre) z.B. zum Löschen von Threads folgendermaßen ablaufen:

//Pseudocode
if( User ist authorisiert Threads zu löschen )
{
  Thread mit der ID $_GET['thread_id'] löschen;
}
else
{
  echo Zugriff verweigert;
}

Wäre es im Allgemeinen nicht klug bevor solche kritischen Operationen ausgeführt werden eine Abfrage durchzuführen "ob der Admin/Mod sich sicher sei, den Thread zu löschen"? Meiner Meinung nach ermöglicht gerade, der GET-Parameter solche Angriffe. Würde das Skript die ID des Threads nur per POST-Methode akzeptieren, dann würde es keine Auswirkungen haben, falls ein Admin/Mod unabsichtlich auf so einen bösen Link klicken würde. Der Nachteil dieser Sichherheitsmaßnahme ist natürlich, dass man alle Edit/Delete/Close- etc. Links (mit GET-Parametern) in Formulare mit hidden-fields umwandeln müsste. Lohnt sich der Aufwand? Oder irre ich mich gewaltig in Bezug auf die Sicherheit meiner Variante?
Ich bin übrigens dankbar, dass du mich auf dieses Sicherheitsrisiko aufmerksam gemacht hast. Noch bevor ich ein Admin-Interface auf meiner Seite gestaltet habe

Hervorragend vielleicht nicht, aber dennoch ziemlich gut

Gibt es deiner Meinung nach eine bessere Alternative um Session-Fixation-Attacken abzuwehren?

Ich erspar mir lieber eine Antwort auf deine letzten Kommentare zu geben. Es sollte genügen wenn ich sage, dass ich eine eigene Sessionklasse habe, die nicht nur die PHP-Sessions kapselt (Stichwort: session_set_save_handler()), sondern auch dazu dient die Session-ID's in der MySQL DB derart zu speichern, so dass ich mit einer einzigen Query herausfinden kann welche Gäste und Mitglieder in den letzten 20 Minuten aktiv waren. Nun ist es ja so (jetzt gebe ich doch eine Erklärung ab, lol), dass wenn PHP die Session schließen will die Funktion function _write($ses_id, $data) in meiner Sessionklasse aufgerufen wird. Leider ist die Variable $data bereits die serialisierte Version des _SESSION Arrays, aber genau zu dem Zeitpunkt würde ich gerne den User-Agent String und die momentan besuchte Seite abspeichern. Wahrscheinlich ist das Design meiner Sessionklasse und der Klassen die von dieser Verwendung machen, noch nicht so gut durchdacht, aber ich bin zuversichtlich, dass ich da eine Lösung finden werde...

flenders

Aziz schrieb:

Wäre es im Allgemeinen nicht klug bevor solche kritischen Operationen ausgeführt werden eine Abfrage durchzuführen "ob der Admin/Mod sich sicher sei, den Thread zu löschen"?

Nur wenn du dann nach diesem Schritt überprüfst, ob er zuvor auch auf der Seite war, die diese Nachfrage zur Folge hat.

Aziz schrieb:

Meiner Meinung nach ermöglicht gerade, der GET-Parameter solche Angriffe. Würde das Skript die ID des Threads nur per POST-Methode akzeptieren, dann würde es keine Auswirkungen haben, falls ein Admin/Mod unabsichtlich auf so einen bösen Link klicken würde.

Über GET geschieht dies natürlich leichter, aber auch über POST bist du dagegen nicht geschützt, dann man muss dann nur auf seiner Homepage ein Formular ablegen, das dann entsprechend nach Klick abgeschickt wird.

Aziz schrieb:

Leider ist die Variable $data bereits die serialisierte Version des _SESSION Arrays, aber genau zu dem Zeitpunkt würde ich gerne den User-Agent String und die momentan besuchte Seite abspeichern.

Bin mir gerade nicht sicher, in welchem Format die Daten genau vorliegen und die Variante ist auch nicht wirklich effizient: unserialize -> Daten hinzufügen -> serialize

Shade Of Mine

flenders schrieb:

Könnte man da nicht evtl. über Refferer (ggf. auch Serverseitig einfach in der Session mitprotokollieren, wo der User zuletzt war). Damit könnte man zumindest das Risiko etwas minimieren. Oder eben einfach nochmal eine zusätzliche Nachfrage Ja/Nein...

Zusaetzliches Ja/Nein per Ticket System ist das einfachste.

Mit protokollieren wo der User gerade ist, ist schwer, weil er ja mehrere Fenster offen haben kann. Wir muessten also mit timeouts arbeiten - was wieder eine kleine Unsicherheit hineinbringt, aber dennoch mehr sicherheit. nachteil ist der _enorme_ server load.

Referer ist immer kritisch, wegen zu aggressiven Webwashern. Oder auch Proxies. Die schnappen dir den Referer weg ehe du piep sagen kannst. Allerdings gibt es einige Downloadservices die mit referer arbeiten damit du nicht um die Werbung kommst und somit zu direkte links blocken...

Ich wuerde das Ticket System empfehlen, denn es schuetzt und ist simpel. Erzeugt ausserdem nur load wenn es gebraucht wird und kein User wird ausgesperrt. Und einmal mehr Ja klicken ist nicht so fatal (auch wenn mir jetzt die Usability-Experten jetzt den kopf abhacken (clicks sind heilig) - aber die zusaetzliche sicherheit ist diese unbquemlichkeit IMHO wert.

Aziz schrieb:

Eine interessante Diskussion bisher. Ob ich nun Cookies zur Voraussetzung für die Anmeldung machen will, werde ich mir nochmal gründlich überlegen.

Es kommt hier auch auf die Anwendung an. Wenn du zB Intranets fuer Firmen entwickelst, dann kannst du getrost Cookies verlangen. Wenn es eine allerweltsseite ist wie zB dieses Forum, wuerde ich abraten.

Es gibt ja wie besprochen Nachteile wenn man den User-Agent und vielleicht noch andere Client-Daten (komplette IP, HTTP_ACCEPT_LANGUAGE etc.) zur Sicherung der Session verwendet.

NIE NIE NIE die ACCEPT sachen. Language geht uU noch, aber bedenke: ein Plugin Installiert, eine Sicherheitsstufe geaendert, Proxy gewechselt, etc. und schon haben sich die ACCEPT sachen geaendert.

Wäre es da aber keine gute Idee den User beim Loginformular entscheiden zu lassen, ob diese Art der Sicherung geschehen soll? Zumindest wäre dies für Websiteadmins eine Überlegung wert, weil der meistens mehr Verständnis vom Technikkram hat.

Fuer technisch versierte User ist das aufjedenfall eine moeglichkeit. dh, zB bei diesem Forum hier, koennte man das implementieren.
Wenn es aber um Barbie-Puppen-Frisuren geht, dann werden die 12 jaehrigen Maedchen dadurch nur verwirrt sein und die Standard Variante nehmen (falls es ihnen ueberhaupt auffaellt).

idR will man dem User sowenig Entscheidungen wie moeglich andrehen... Aber 2gleisig fahren mag durchaus ok sein, ist halt nur mehr arbeit und man muss darauf achtgeben was man dem user zumuten kann.

Ich hab mir Gedanken darüber gemacht, wie man solche ungewollten Aktionen seitens der Admins/Mods abwehren könnte. Im Prinzip würde ein Skript (das gegen solche Angriffe verwundbar wäre) z.B. zum Löschen von Threads folgendermaßen ablaufen:
//Pseudocode
if( User ist authorisiert Threads zu löschen )
{
  Thread mit der ID $_GET['thread_id'] löschen;
}
else
{
  echo Zugriff verweigert;
}
Wäre es im Allgemeinen nicht klug bevor solche kritischen Operationen ausgeführt werden eine Abfrage durchzuführen "ob der Admin/Mod sich sicher sei, den Thread zu löschen"?

Ja, das ist genau das, was ich mit Ticket System meine.
Du hast dort eine Form, die per Ticket System gesichert ist. Die Form sieht aber nur der, der zugriff auf die Seite hat. Somit kann man keine Tickets bekommen ohne rechte zu haben.

Die Form macht dann eine Ja/Nein abfrage und alles ist paletti. Ich weiss nciht wie es technisch beim phpBB aussieht, aber diese Ja/Nein seite gibt es beim loeschen. Ich hoffe mal, dass sie gut gesichert ist

Meiner Meinung nach ermöglicht gerade, der GET-Parameter solche Angriffe. Würde das Skript die ID des Threads nur per POST-Methode akzeptieren, dann würde es keine Auswirkungen haben, falls ein Admin/Mod unabsichtlich auf so einen bösen Link klicken würde.

Man kann per JS eine Form submitten. Ein POST erhoeht die sicherheit nur minimal. Denn forms per JS submitten (zB wenn ich auf einen link klicke) ist nicht wirklich ein problem.

Ich bin übrigens dankbar, dass du mich auf dieses Sicherheitsrisiko aufmerksam gemacht hast. Noch bevor ich ein Admin-Interface auf meiner Seite gestaltet habe

Man tut was man kann

Gibt es deiner Meinung nach eine bessere Alternative um Session-Fixation-Attacken abzuwehren?

Bessere Sachen gibt es, aber die Methode ist simpel und effizient. zB kannst du absolute Session-Timeouts einstellen, aber das ist wieder ein horror fuer die Usability...

Effizient ist es auch, eine SID an eine User ID zu binden. Sprich wenn ein user sich neu einloggt werden alle noch aktiven Sessions des Users zerstoert.

Ich erspar mir lieber eine Antwort auf deine letzten Kommentare zu geben. Es sollte genügen wenn ich sage, dass ich eine eigene Sessionklasse habe, die nicht nur die PHP-Sessions kapselt (Stichwort: session_set_save_handler()), sondern auch dazu dient die Session-ID's in der MySQL DB derart zu speichern, so dass ich mit einer einzigen Query herausfinden kann welche Gäste und Mitglieder in den letzten 20 Minuten aktiv waren. Nun ist es ja so (jetzt gebe ich doch eine Erklärung ab, lol), dass wenn PHP die Session schließen will die Funktion function _write($ses_id, $data) in meiner Sessionklasse aufgerufen wird. Leider ist die Variable $data bereits die serialisierte Version des _SESSION Arrays, aber genau zu dem Zeitpunkt würde ich gerne den User-Agent String und die momentan besuchte Seite abspeichern. Wahrscheinlich ist das Design meiner Sessionklasse und der Klassen die von dieser Verwendung machen, noch nicht so gut durchdacht, aber ich bin zuversichtlich, dass ich da eine Lösung finden werde...

Aeh, vielleicht uebersehe ich etwas, aber was ist mit folgendem:

Die Tabelle hat hat neben SID und Data noch das feld last_update (timestamp) und additionalData. Nun schreibst du die serialisierten Daten brutal in Data rein, machst ein update auf last_update (mit der aktuellen zeit) und schreibst zusaetzliche infos in das additionalData feld rein. Nachteil: du hast additionalData in nicht $_SESSION stehen - Vorteil: du hast das normale PHP Session management effizient genutzt.

Vermutlich habe ich etwas uebersehen - aber was?

Aziz

flenders schrieb:

Bin mir gerade nicht sicher, in welchem Format die Daten genau vorliegen und die Variante ist auch nicht wirklich effizient: unserialize -> Daten hinzufügen -> serialize

Diese Funktionen habe ich schon in Betracht gezogen, aber leider ist das Format das serialize produziert inkompatibel zum Format, in dem PHP seine Session-Daten speichert.

Serialized $_SESSION using serialize():
a:4:{s:7:"user_id";s:1:"2";s:8:"username";s:4:"aziz";s:8:"password";s:32:"9dca5e87630b9185169af2d17f5c11f4";s:10:"login_hash";s:32:"45ea05577deefefb06745210a38fbcdc";}

Session echoed from function _write:
user_id|s:1:"2";username|s:4:"aziz";password|s:32:"9dca5e87630b9185169af2d17f5c11f4";login_hash|s:32:"45ea05577deefefb06745210a38fbcdc";

Aziz

Shade Of Mine schrieb:

Ich wuerde das Ticket System empfehlen, denn es schuetzt und ist simpel. Erzeugt ausserdem nur load wenn es gebraucht wird und kein User wird ausgesperrt. Und einmal mehr Ja klicken ist nicht so fatal (auch wenn mir jetzt die Usability-Experten jetzt den kopf abhacken (clicks sind heilig) - aber die zusaetzliche sicherheit ist diese unbquemlichkeit IMHO wert.

Scheint eine akzeptable Lösung zu sein. Sofern ich das System mit Tickets verstanden habe, wird einem Formular eine einzigartige ID (MD5 Hash?) angehängt (Hidden-Field?), die auf der nächsten Seite dann auf Gültigkeit überprüft wird, bevor ein UPDATE/INSERT/DELETE in der Datenbank erfolgt. Es ist aber garantiert nicht möglich, so ein Ticket zu faken, genauso wie es unmöglich ist eine aktive Session ID durch Probieren herauszufinden, oder?

Shade Of Mine schrieb:

NIE NIE NIE die ACCEPT sachen. Language geht uU noch, aber bedenke: ein Plugin Installiert, eine Sicherheitsstufe geaendert, Proxy gewechselt, etc. und schon haben sich die ACCEPT sachen geaendert.

Das ist mir schon klar. Es gibt aber Proxies mit unterschiedlichem Anonymitätsgrad; manche senden die IP des echten Clients in der HTTP_X_FORWARDED_FOR Variable mit, und manche erlauben es einem überhaupt nicht festzustellen, ob ein User ein Proxy verwendet...

Gibt es deiner Meinung nach eine bessere Alternative um Session-Fixation-Attacken abzuwehren?

Bessere Sachen gibt es, aber die Methode ist simpel und effizient. zB kannst du absolute Session-Timeouts einstellen, aber das ist wieder ein horror fuer die Usability...

Effizient ist es auch, eine SID an eine User ID zu binden. Sprich wenn ein user sich neu einloggt werden alle noch aktiven Sessions des Users zerstoert.

Das würde aber verhindern, dass sich ein User mehrmals von verschiedenen Browsern aus einloggen kann. Ich frag mich aber sowieso ob es eine gute Idee ist, das zu erlauben... Bei vBulletin und phpBB geht das jedenfalls...

Shade Of Mine schrieb:

Aeh, vielleicht uebersehe ich etwas, aber was ist mit folgendem:

Die Tabelle hat hat neben SID und Data noch das feld last_update (timestamp) und additionalData. Nun schreibst du die serialisierten Daten brutal in Data rein, machst ein update auf last_update (mit der aktuellen zeit) und schreibst zusaetzliche infos in das additionalData feld rein. Nachteil: du hast additionalData in nicht $_SESSION stehen - Vorteil: du hast das normale PHP Session management effizient genutzt.

Vermutlich habe ich etwas uebersehen - aber was?

Sowas in der Richtung hab ich mir auch schon gedacht. Aber bevor ich eine neue Spalte für Extra-Daten erzeuge, da kann ich doch gleich die Extra-Daten an die Session-Daten anhängen (und da hat man auch die Daten im globalen $_SESSION Array). Das Format ist überhaupt nicht kompliziert, wenn man nur Strings anhängen will...

Shade Of Mine

Aziz schrieb:

Scheint eine akzeptable Lösung zu sein. Sofern ich das System mit Tickets verstanden habe, wird einem Formular eine einzigartige ID (MD5 Hash?) angehängt (Hidden-Field?), die auf der nächsten Seite dann auf Gültigkeit überprüft wird, bevor ein UPDATE/INSERT/DELETE in der Datenbank erfolgt. Es ist aber garantiert nicht möglich, so ein Ticket zu faken, genauso wie es unmöglich ist eine aktive Session ID durch Probieren herauszufinden, oder?

Genau. Das unmöglich natürlich in anführungszeichen - denn möglich ist alles - nur verdammt unwahrscheinlich

Genau genommen ist ein Ticket System sogar sicherer als die SID

Aber Achtung: ein Ticket System ist kein garant für sicherheit. Wenn ich als böser User nämlich an ein Ticket komme, kann ich alles machen was ich will.

Beispiel: einige Internetseiten, zB Linklisten wie auf c++.de verwenden ein Ticket System um bots zu blocken dass sie keinen Spam eintragen können. Nun ist es aber simpel sich erst das Ticket zu holen und dann die Form abzusenden. Also immer daran denken: ein TicketSystem wo jeder Tickets bekommen kann ist nur minimal sicher.

Bei unserem Beispiel ist dies aber nicht der Fall, weil ja nur der autorisierte User ein Ticket bekommt und ein Angreifer nicht. Deshalb kann der Angreifer den User nicht dazu bringen die aktion ohne bestätigung durchzuführen, weil ja erstmal ein Ticket her muss...

Das würde aber verhindern, dass sich ein User mehrmals von verschiedenen Browsern aus einloggen kann. Ich frag mich aber sowieso ob es eine gute Idee ist, das zu erlauben... Bei vBulletin und phpBB geht das jedenfalls...

Ja, das ist ein Problem. Aber IMHO hier kein schweres. Denn warum sollte ein User 2mal online sein?

Problematischer ist es bei einem auto-login. Wenn man dieses Prinzip nämlich auf ein auto-login überträgt, kann der User sich nur von einem PC automatisch einloggen, während es von allen anderen nicht geht. Hier muss man abstriche machen, was das auto-login feature relativ gefährlich macht

Hier suche ich immer noch nach einer guten möglichkeit...

Das Format ist überhaupt nicht kompliziert, wenn man nur Strings anhängen will...

Die Frage ist nur: wird sich das Format vielleicht irgendwann mal ändern? Aber klar, wenn du damit zufrieden bist, dann passt es schon.

SideWinder

Der Thread enthält inzwischen soviel nützliches Wissen, dass er unbedingt in die FAQ muss

MfG SideWinder

Sa*n*dman

Bevor Du das Ding in die FAQ schiebst, erstmal ne kleine Richtigstellung:

PHP speichert die IP nicht in der Session, sondern es zieht sie als Teil des Initialwertes für den Session-Hash heran. Dabei kommt übrigens die gesammte IP zum Einsatz, und nicht nur ein Teil.

Hintergrund dafür ist, daß der Hash nur einmal generiert wird, aber nie mehr überprüft wird, ob die Session noch von einer identischen IP abgefragt wurde. Wäre ja schließlich auch garnicht möglich, da ja auch die microtime() mit herangezogen wird, und an die kommst Du nie wieder ran, wenn die Session einmal "läuft".

Gruß Jens