nicht angemeldet
SessionID
hi,
ich habe gerade eben festgestellt, dass meine PHP-Anwendung, die mit session_start() beginnt, PHP-Version 5.3.0, eine SessionID annimmt, die initial vom UserAgent gesetzt wird beim ersten Request. Dabei wird nicht einmal auf die Länge geprüft, eine von UA vorgegebene SID=123, oder auch kürzer, wird für die Session verwendet.
Stellt das nicht ein gewisses Sicherheitsrisiko dar, vom UA vorgegebene SessionIDs anzunehmen?
Hotti
-
Tach!
Stellt das nicht ein gewisses Sicherheitsrisiko dar, vom UA vorgegebene SessionIDs anzunehmen?
Für wen ergibt sich dadurch welches Risiko?
dedlfix.
-
Moin,
Stellt das nicht ein gewisses Sicherheitsrisiko dar, vom UA vorgegebene SessionIDs anzunehmen?
Für wen ergibt sich dadurch welches Risiko?
Für den Betreiber eines Servers mit sensiblen Daten. Der Angreifer muss sich nicht die Mühe machen, im ersten Schritt zu diesem Server zu gehen um sich eine SID zu besorgen: Er kann 'gut aussehende' SessionIDs selbst festlegen und potentiellen Nutzern unterjubeln. Dann muss er nur noch abwarten, bis sich einer von den Nutzern anmeldet und dabei eine Session verwendet mit einer dem Angreifer bereits bekannten SID.
Hotti
-
Tach!
Stellt das nicht ein gewisses Sicherheitsrisiko dar, vom UA vorgegebene SessionIDs anzunehmen?
Für wen ergibt sich dadurch welches Risiko?
Für den Betreiber eines Servers mit sensiblen Daten. [Session-Fixation-Szenario].Bist du ein Service-Betreiber mit sensiblen Daten? Hast du dann in deinem System die Möglichkeit der ID-Übergabe per URL offen gelassen? Wenn ja warum?
Wenn du eine gute Begründung hast: session_regenerate_id() wurde ja schon von Sven angesprochen existiert. Mach einen ID-Wechsel beim Login.
dedlfix.
-
hi,
Bist du ein Service-Betreiber mit sensiblen Daten? Hast du dann in deinem System die Möglichkeit der ID-Übergabe per URL offen gelassen? Wenn ja warum?
Erstens ja, zweitens arbeite ich ausschließlich mit Cookie.
Wenn du eine gute Begründung hast: session_regenerate_id() wurde ja schon von Sven angesprochen existiert. Mach einen ID-Wechsel beim Login.
Es gibt mehrere Möglichkeiten, eine von denen habe ich auch genannt ;)
Hotti
-
-
-
-
Stellt das nicht ein gewisses Sicherheitsrisiko dar, vom UA vorgegebene SessionIDs anzunehmen?
Direkt auf die Frage bezogen: Nein. Nur auf die Länge. Es ist aber nicht gegeben, dass jeder UA so reagieren würde, also das Risiko wieder minimal wird.
-
Stellt das nicht ein gewisses Sicherheitsrisiko dar, vom UA vorgegebene SessionIDs anzunehmen?
Direkt auf die Frage bezogen: Nein. Nur auf die Länge.
Genau, je länger die SID ist, desto schwerer ist sie zu erraten. In meinem Perl-Framework prüfe ich die Länge auf \w{32}. In der mir vorliegenden PHP-Version wird nur auf "valid characters are a-z, A-Z, 0-9 and '-,'" geprüft, nicht jedoch die Länge der Zeichenkette, was mich etwas verwundert hat; möglicherweise ist das in neueren PHP-Versionen anders, vielleicht weiß das jemand.
Hotti
-
Tach!
Stellt das nicht ein gewisses Sicherheitsrisiko dar, vom UA vorgegebene SessionIDs anzunehmen?
Direkt auf die Frage bezogen: Nein. Nur auf die Länge.
Genau, je länger die SID ist, desto schwerer ist sie zu erraten.Und wer hat einen Nachteil davon, dass jemand seine Session-ID mutwillig erratbar macht? Noch jemand anderes als derjenige selbst? Der könnte auch seine Zugangsdaten weitergeben, was aufs Gleiche rauskommt und nicht mal vom Betreiber verhindert werden kann.
In meinem Perl-Framework prüfe ich die Länge auf \w{32}.
Hilft das gegen leicht erratbare Werte wie 32×X?
In der mir vorliegenden PHP-Version wird nur auf "valid characters are a-z, A-Z, 0-9 and '-,'" geprüft, nicht jedoch die Länge der Zeichenkette, was mich etwas verwundert hat; möglicherweise ist das in neueren PHP-Versionen anders, vielleicht weiß das jemand.
Das offizielle ChangeLog kennt alle Änderungen.
dedlfix.
-
hi,
Und wer hat einen Nachteil davon, dass jemand seine Session-ID mutwillig erratbar macht? Noch jemand anderes als derjenige selbst? Der könnte auch seine Zugangsdaten weitergeben, was aufs Gleiche rauskommt und nicht mal vom Betreiber verhindert werden kann.
Es gibt viel Geschriebenes über die Beschaffenheit einer SessionID. Es wäre schade ums Papier und um die Mühe derjenigen, die darüber schreiben, wenn Du das nicht ernst nimmst. Wer ein Framework baut, was eine SessionID=1 ermöglicht, kann sich derartige Lektüre ersparen und sich fürder dem Kartenspielen widmen.
Das offizielle ChangeLog kennt alle Änderungen.
Mein Handlungsbedarf besteht jetzt darin, dafür zu sorgen, dass eine SID nur dann gültig ist, wenn sie serverseitig erzeugt und nicht etwa vom UA vorgegeben wurde. Das vereinfacht auch die Prüfung.
Hotti
-
Tach!
Und wer hat einen Nachteil davon, dass jemand seine Session-ID mutwillig erratbar macht? Noch jemand anderes als derjenige selbst? Der könnte auch seine Zugangsdaten weitergeben, was aufs Gleiche rauskommt und nicht mal vom Betreiber verhindert werden kann.
Es gibt viel Geschriebenes über die Beschaffenheit einer SessionID. Es wäre schade ums Papier und um die Mühe derjenigen, die darüber schreiben, wenn Du das nicht ernst nimmst. Wer ein Framework baut, was eine SessionID=1 ermöglicht, kann sich derartige Lektüre ersparen und sich fürder dem Kartenspielen widmen.Ich nehme das Ernst, aber ich bin nicht dafür verantwortlich, wenn sich jemand vorsätzlich selbst schaden will. Für mich ist die Aufgabe erledigt, wenn das System die Session-IDs nach bestem Wissen und Gewissen vergibt und nicht mir als Serverbetreiber und den anderen Kunden (oder was auch immer) schadet.
Und wenn du meine Fragen Ernst nimmst, bitte ich dich, direkt darauf zu antworten.
dedlfix.
-
hi,
Und wenn du meine Fragen Ernst nimmst, bitte ich dich, direkt darauf zu antworten.
Hattest Du ne Frage? Tut mir leid, hab ich übersehen.
Hotti
-
-
-
-
-
-
Moin!
ich habe gerade eben festgestellt, dass meine PHP-Anwendung, die mit
session_start()beginnt, PHP-Version 5.3.0, eine SessionID annimmt, die initial vom UserAgent gesetzt wird beim ersten Request. Dabei wird nicht einmal auf die Länge geprüft, eine von UA vorgegebene SID=123, oder auch kürzer, wird für die Session verwendet.Stellt das nicht ein gewisses Sicherheitsrisiko dar, vom UA vorgegebene SessionIDs anzunehmen?
Ja, das stellt ein hohes Risiko dar, man nennt es "Session Fixation".
Die Gegenmaßnahme ist, bei jeder Erhöhung der Userrechte (also z.B. bei einem Login), aber gerne auch regelmäßig zwischendurch, die Session-ID mit session_regenerate_id() zu erneuern. Insbesondere dann, wenn die ID eben nicht via Cookie übergeben wurde.
PS: PHP 5.3.0 ist ja mal sowas von alt, da ist zwingend ein Update angesagt. Aktuell ist 5.3.20!
- Sven Rautenberg
-
Tach!
Stellt das nicht ein gewisses Sicherheitsrisiko dar, vom UA vorgegebene SessionIDs anzunehmen?
Ja, das stellt ein hohes Risiko dar, man nennt es "Session Fixation".Für wen konkret (und unter welchen Umständen/in welchen Szenarien)? Wenn hotti schon der Beantwortung dieser Frage ausweicht, vielleicht willst du sie ja beantworten.
dedlfix.
-
Moin!
Stellt das nicht ein gewisses Sicherheitsrisiko dar, vom UA vorgegebene SessionIDs anzunehmen?
Ja, das stellt ein hohes Risiko dar, man nennt es "Session Fixation".Für wen konkret (und unter welchen Umständen/in welchen Szenarien)? Wenn hotti schon der Beantwortung dieser Frage ausweicht, vielleicht willst du sie ja beantworten.
Wenn der Angreifer dem Opfer einen Link zuschickt, welcher eine dem Angreifer bekannte Session-ID enthält, und das Opfer dem Link folgt, weil er die Seite kennt und sich dort einloggen will, wird ohne Gegenmaßnahme durch das Opfer eine eingeloggte Session erzeugt, dessen ID dem Angreifer bekannt ist. Er kann dann also "mitsurfen".
Es gibt dagegen diverse Maßnahmen, von denen das Austauschen der bisher genutzten Session-ID beim Login eine universell wirksame ist, denn diese Änderung bekommt nur der Browser mit, der gerade eben die Login-Daten abgeschickt hat - in der Regel ist das nur der Browser des Opfers.
Andere Maßnahmen wären die Verschlüsselung der Session-Daten (umgesetzt z.B. durch die Suhosin-Extension), bei der in den Key Dinge wie der User-Agent des Browsers oder auch die IP bzw. ersten Oktette der IP einfließen. Solche Angaben sind recht individuell und würden erfordern, dass der Angreifer diese Werte exakt duplizieren kann. Gelingt ihm das nicht, wird die von im "vorgestartete" Session durch einen anderen Browser nicht korrekt entschlüsselt und damit wieder verworfen. Umgekehrt gilt dasselbe Prinzip.
Man kann natürlich auch einfach konfigurieren, dass Session-IDs nur über Cookies akzeptiert werden.
- Sven Rautenberg
-
Tach!
Wenn der Angreifer dem Opfer einen Link zuschickt, welcher eine dem Angreifer bekannte Session-ID enthält, und das Opfer dem Link folgt, weil er die Seite kennt und sich dort einloggen will, wird ohne Gegenmaßnahme durch das Opfer eine eingeloggte Session erzeugt, dessen ID dem Angreifer bekannt ist. Er kann dann also "mitsurfen".
Das setzt voraus, dass hotti in seinem Szenario die Session-ID über URL entgegennimmt. Dazu muss er aber eine gute Begründung haben. Wie zum Beispiel auch noch die letzten Kunden nicht zu vergraulen, die Cookies generell ablehnen. Ansonsten kann ihm dieses Szenario egal sein. Cookies vorsätzlich manipulieren geht zwar, aber das ist dann eine Sache desjenigen und kein von Dritten untergeschobener Angriff.
Es gibt dagegen diverse Maßnahmen, von denen das Austauschen der bisher genutzten Session-ID beim Login eine universell wirksame ist, denn diese Änderung bekommt nur der Browser mit, der gerade eben die Login-Daten abgeschickt hat - in der Regel ist das nur der Browser des Opfers.
regenerate_session_id() - sollte man nur nicht bei jedem Seitenaufruf machen, sonst hat es der Besucher beim Vor- und Zurücknavigieren schwerer als notwendig.
Man kann natürlich auch einfach konfigurieren, dass Session-IDs nur über Cookies akzeptiert werden.
Eben.
Das Unterschieben war auch das einzige Angriffsszenario, das mir einfiel, bei dem das Opfer nicht selbst schuld ist, das sich aber durch Only-Cookie vermeiden und durch session_regenerate_id() mildern oder verhindern lässt.
dedlfix.
-
-
-