SESSION-Dateien löschen

[Bobby]

Moin

Ich habe mal ne Frage. Ich versuche eine Session sicher zu machen. Dazu habe ich folegndes Vereinbart:

• Nur Cookie, keine Übergabe per URL
• Maximale Geltungsdauer 60 Minuten
• HTTP-Only für das Sessioncookie
• GarbageCollector angepasst
• SANITY-KEY eingeführt
• session_regenerate_id() integriert

Allerdings beim letzten Punkt gibt es Schwierigkeiten. Ich habe den optionalen Parameter nicht auf TRUE gesetzt, da es einige probleme damit gab. Wenn man beispielsweise eine Webseite mit dem gesetzten Parameter in 2 Tabs öffnet oder einen Link 2 mal kurz hintereinander klickt, wurde die alte Session nicht mehr erkannt, da diese jedes mal regeneriert wurde.

Nun habe ich das TRUE entfernt und die alten Session Dateien sind somit noch auf dem Server.

Ich wollte nun die aktuelle Session-ID speichern und dann, wenn das Regenerieren erfolgreich war, diese datei auf dem Server löschen. Ich habe leider keinen Ansatz dafür. Gibt es eine andere Lösung um vielleicht den Parameter bei session_regenerate_id() auf true setzen und es funktioniert wie gewünscht ?

Gruß Bobby

[1UnitedPower]

Meine Herren,

Gibt es eine andere Lösung um vielleicht den Parameter bei session_regenerate_id() auf true setzen und es funktioniert wie gewünscht ?

Hast du mit session_destroy() die selbe Problematik?

[Bobby]

Moin

Meine Herren,

Gibt es eine andere Lösung um vielleicht den Parameter bei session_regenerate_id() auf true setzen und es funktioniert wie gewünscht ?

Hast du mit session_destroy() die selbe Problematik?

Ich möchte die session ja aber nicht zerstören sondern nur die Session ID regenerieren. Und wenn die Regeneriert ist, dann die alte Session löschen.

Wie meinst du das mit dem destroy?

Gruß Bobby

[dedlfix]

Tach!

• Maximale Geltungsdauer 60 Minuten
• GarbageCollector angepasst

Hast du auch bedacht, den session_save_path in ein separates Verzeichnis zu verbiegen, nicht dass dir andere Anwendungen mit ihren Einstellungen die Sessions löschen. Beispielsweise ist der Default-Wert für die Session-Dauer 24 Minuten. Die anderen räumen dir sonst die Daten eher weg.

Und warum nimmst du solch einen hohen Wert von 60 Minuten? Oder meinst du gar nicht einen Inaktivitätszähler, sondern die Zeit seit dem ersten Start?

• SANITY-KEY eingeführt

Was verstehst du darunter?

• session_regenerate_id() integriert
  Allerdings beim letzten Punkt gibt es Schwierigkeiten. Ich habe den optionalen Parameter nicht auf TRUE gesetzt, da es einige probleme damit gab. Wenn man beispielsweise eine Webseite mit dem gesetzten Parameter in 2 Tabs öffnet oder einen Link 2 mal kurz hintereinander klickt, wurde die alte Session nicht mehr erkannt, da diese jedes mal regeneriert wurde.

Was genau willst du eigentlich erreichen? Willst du, dass man sich nur vorwärts in Einzelschritten durch eine Prozedur bewegen kann? Dann ist es sinnvoll, das Holzbrett hinter sich wegzunehmen und nach vorn zu versetzen und das bei jedem Schritt *). Aber du willst anscheinend dem User ein mehrfaches Angemeldetsein erlauben. Das beißt sich dann mit der Einzelschrittidee. session_regenerate_id() ist dann kontraproduktiv und erhöht auch nicht die Sicherheit bei dieser nicht ganz so strengen Anforderung. Das Doppelklicken jedenfalls könnte man mit ein wenig Javascript unterbinden.

Gibt es eine andere Lösung um vielleicht den Parameter bei session_regenerate_id() auf true setzen und es funktioniert wie gewünscht ?

Hast du einen guten Grund für diesen Aufwand, der sich nicht mit der Erlaubnis eines zweiten Tabs beißt?

*) Kindergeburtstagsspiel. Man muss eine Strecke zurücklegen, darf aber den Boden nicht mit den Füßen berühren, sondern bekommt zwei Bretter. Vorwärts kommt man, indem man immer das hintere Brett nach vorn legt und dann einen Schritt weiterkommt.

dedlfix.

[Bobby]

Moin

Tach!

• Maximale Geltungsdauer 60 Minuten
• GarbageCollector angepasst

Hast du auch bedacht, den session_save_path in ein separates Verzeichnis zu verbiegen, nicht dass dir andere Anwendungen mit ihren Einstellungen die Sessions löschen. Beispielsweise ist der Default-Wert für die Session-Dauer 24 Minuten. Die anderen räumen dir sonst die Daten eher weg.

Oha, das habe ich nicht bedacht. Danke. Die Zeit von 24 Minuten hatte ich umgestellt über iniset und den ganzen GC-Parametern

Und warum nimmst du solch einen hohen Wert von 60 Minuten? Oder meinst du gar nicht einen Inaktivitätszähler, sondern die Zeit seit dem ersten Start?

Ich möchte das ein User nach 60 Minuten inaktivität automatisch ausgeloggt wird.

• SANITY-KEY eingeführt

Was verstehst du darunter?

Ein eindeutiger Schlüssel der verglichen wird aus verscheidenen Parametern.

• session_regenerate_id() integriert
  Allerdings beim letzten Punkt gibt es Schwierigkeiten. Ich habe den optionalen Parameter nicht auf TRUE gesetzt, da es einige probleme damit gab. Wenn man beispielsweise eine Webseite mit dem gesetzten Parameter in 2 Tabs öffnet oder einen Link 2 mal kurz hintereinander klickt, wurde die alte Session nicht mehr erkannt, da diese jedes mal regeneriert wurde.

Was genau willst du eigentlich erreichen? Willst du, dass man sich nur vorwärts in Einzelschritten durch eine Prozedur bewegen kann? Dann ist es sinnvoll, das Holzbrett hinter sich wegzunehmen und nach vorn zu versetzen und das bei jedem Schritt *). Aber du willst anscheinend dem User ein mehrfaches Angemeldetsein erlauben. Das beißt sich dann mit der Einzelschrittidee. session_regenerate_id() ist dann kontraproduktiv und erhöht auch nicht die Sicherheit bei dieser nicht ganz so strengen Anforderung. Das Doppelklicken jedenfalls könnte man mit ein wenig Javascript unterbinden.

ich möchte SESSION-HiJacking verhindern. DAs heißt das eine ID niemals für 2 Aufrufe gleichzeitig gelten soll. sondern bei jedem Aufruf regeneriert werden soll, damit, wenn ein potentieller Angreifer die ID in die Hände bekommt, diese ungültig ist, da eine neue gesetzt wurde. Dazu gehört natürlich auch das Löschen der altem temporären Session-DAten auf dem Server. Dies ist natürlich auch das problem bei 2 Tabs offen oder schnell hintereinander ausgeführten HTTP-Requests ohne auf die Antwort zu warten.

Gibt es eine andere Lösung um vielleicht den Parameter bei session_regenerate_id() auf true setzen und es funktioniert wie gewünscht ?

Hast du einen guten Grund für diesen Aufwand, der sich nicht mit der Erlaubnis eines zweiten Tabs beißt?

Verhinderung von SESSION-HiJacking

Gruß Bobby

[dedlfix]

Tach!

Hast du auch bedacht, den session_save_path in ein separates Verzeichnis zu verbiegen, nicht dass dir andere Anwendungen mit ihren Einstellungen die Sessions löschen.
Oha, das habe ich nicht bedacht. Danke. Die Zeit von 24 Minuten hatte ich umgestellt über iniset und den ganzen GC-Parametern

Das gilt immer nur für den GC des aktuellen Script, nicht für die GCs der anderen Scripts, die in dasselbe Verzeichnis ihre Daten ablegen. Session-Dateien sind Session-Dateien, die werden nicht nach Anwendung oder gar Scriptnamen unterschieden.

Ich möchte das ein User nach 60 Minuten inaktivität automatisch ausgeloggt wird.

Ganz schön lang im Verhältnis zu den anderen "Paranoia"-Werten.

ich möchte SESSION-HiJacking verhindern. DAs heißt das eine ID niemals für 2 Aufrufe gleichzeitig gelten soll.

Dann kannst du beruhigt session_regenerate_id(true) verwenden, denn alles andere darf dann nicht funktionieren. Gegen das versehentliche Doppelklicken hilft, wie gesagt, Javascript. Zwei Tabs dürfen dann einfach nicht sein.

Hast du einen guten Grund für diesen Aufwand, der sich nicht mit der Erlaubnis eines zweiten Tabs beißt?
Verhinderung von SESSION-HiJacking

Das ist mir zu allgemein formuliert. Je nachdem, was man mit einer gehijackten Session für Schaden anrichten kann oder auch nicht, sollte man das Paranoia-Level ausrichten. Zu viel des Guten ist auch ungesund.

dedlfix.

[Bobby]

Moin

Das gilt immer nur für den GC des aktuellen Script, nicht für die GCs der anderen Scripts, die in dasselbe Verzeichnis ihre Daten ablegen. Session-Dateien sind Session-Dateien, die werden nicht nach Anwendung oder gar Scriptnamen unterschieden.

Ich möchte das ein User nach 60 Minuten inaktivität automatisch ausgeloggt wird.

Ganz schön lang im Verhältnis zu den anderen "Paranoia"-Werten.

Naja, es sollen uploads möglich sein, die auch schonmal länger dauern können

Dann kannst du beruhigt session_regenerate_id(true) verwenden, denn alles andere darf dann nicht funktionieren. Gegen das versehentliche Doppelklicken hilft, wie gesagt, Javascript. Zwei Tabs dürfen dann einfach nicht sein.

Leider gibt es hier das Problem des DAU. Und auf solch einen bin ich bei meinem Kunden gestossen. Es soll sicher sein und doch 2 Tabs gleichzeitig geöffnet, oder auch 3 oder 4

Hast du einen guten Grund für diesen Aufwand, der sich nicht mit der Erlaubnis eines zweiten Tabs beißt?
Verhinderung von SESSION-HiJacking

Das ist mir zu allgemein formuliert. Je nachdem, was man mit einer gehijackten Session für Schaden anrichten kann oder auch nicht, sollte man das Paranoia-Level ausrichten. Zu viel des Guten ist auch ungesund.

Na gut. Es ist sicherlich ganz schön viel "Sicherheit". Teile der eingegebenen Daten sind direkt auf der Seite (natürlich unter Beachtung diverser Sicherheitsmaßnahmen) zu sehen. Außerdem sind persönliche Daten in den Profilen hinterlegt. Und hier soll ein "Diebstahl" der Idendität eben ausgeschlossen werden.

Kann ich nicht irgendwie sagen, wenn die neue Session erfolgreich war, dass die alte Session-Datei gelöscht wird? Ich habe schon versucht ein 2. Zeitverzögertes session_regenerate_id(TRUE) zu setzen. Das Ergebnis bleibt das gleiche. Leider.

Gruß Bobby

[Bobby]

Moin

Sorry für mein Kauderwelsch am Ende. Ich denke manchmal schneller als ich schreibe. ;)

Gruß Bobby

[dedlfix]

Tach!

Na gut. Es ist sicherlich ganz schön viel "Sicherheit".
Kann ich nicht irgendwie sagen, wenn die neue Session erfolgreich war, dass die alte Session-Datei gelöscht wird?

Das Wiedereröffnen der alten Session-Datei dürfte nicht das Problem an sich sein. Da steht immer noch ein PHP-Script dazwischen, das den Zugriff auf die Session-Daten gewährt oder auch nicht (vorausgesetzt, der Angreifer kommt nicht über das Dateisystem ran, aber dann hilft auch kein Session-ID-Handling mehr). Ich würde mir überlegen, ob nicht generell solche Sicherheitsmaßnahmen etwas anwenderfreundlich gelockert werden können und nur bei den kritischen Stellen das Paranoia-Level hochgedreht wird. Wenn der Anwender solche Funktionen ausführt, ist die Session eben weg/regeneriert, auch in anderen Tabs, und ansonsten bleibt sie da. Alternativ könnten diese kritischen Funktionen vielleicht auch über zusätzliche Einmal-Keys abgesichert werden. Oder man muss erneut das Passwort angeben, um auf diese sensiblen Funktionalitäten zugreifen zu können. Oder beides.

dedlfix.

[Bobby]

Moin

Alternativ könnten diese kritischen Funktionen vielleicht auch über zusätzliche Einmal-Keys abgesichert werden. Oder man muss erneut das Passwort angeben, um auf diese sensiblen Funktionalitäten zugreifen zu können. Oder beides.

Na das ist mal ein guter Tipp. Ich lasse dies mit der Regeneration jetzt so wie es ist und sichere sensible Bereiche wie von dir beschrieben extra ab.

Gruß Bobby

[Matthias Apsel]

Om nah hoo pez nyeetz, dedlfix!

*) Kindergeburtstagsspiel. Man muss eine Strecke zurücklegen, darf aber den Boden nicht mit den Füßen berühren, sondern bekommt zwei Bretter.

Mit Dosen ist es spannender

Matthias