Ich kenne nur eine, und die sichert man ab, indem man die Sesson-ID nicht über die URL übertägt (bzw. durch PHP übertragen lässt). Allerdings sind dann Cookies voraussetzung, in dem Fall ist eine Speicherung der Session in der DB sinnvoll.

Wenn du mehr Lücken kennst, solltest du uns an deinem Wissen teilhaben lassen.

__________________
“My software never has bugs. It just develops random features ...”

» DevShack - die Website des freien Webentwicklers Boris Bojic

Es gab in der Vergangenheit genug Lücken und es wird immer neue geben um an Cookies zu kommen. Auch wenn es eigentlich Schwachstellen des Systems oder der Tatsache sind, dass man über ein ungeschütztes WLAN surft, sollte man meiner Meinung nach diese simple Prüfung machen. Hundertprozentige Sicherheit kann man dadurch nicht gewährleisten, es ist nur eine Hürde mehr für einen möglichen Angreifer.

Ich beziehe mich nicht auf spezielle Informationen, sondern mache das einfach nur vorbeugend. Vorsicht ist besser als Nachsicht

(Wenn du magst, google nach "Cookies" und "Sicherheitslücke" oder ähnlichem, da finden sich genug Treffer.)

Der Session, oder der Session-Id? Ich verstehe nicht, was ihr damit prüft. Doch nur die Zugehörigkeit der Session zu einem Account, oder?
Dieser Zusammenhang wird bei mir über den Inhalt der Session (z.B. Loginname als Sessionvariable) hergestellt. Da beides auf dem Server liegt und von außen nicht erreichbar ist, läuft das aufs gleiche raus, oder?

Indem ich den Benutzernamen auch darin einpacke, mir merke wann die letzte
Aktion stattfand und das alles vergleiche. Keine Chance ...

__________________
Grüße aus dem Spessart, Joe

{ table-layout: biertischistbesser; }
Der Mausinator

Selbst wenn Benutzername und der Zeitpunkt der letzten Aktion in der Sitzung gespeichert werden, hindert es nicht daran, die Sitzung zu entführen, wenn lediglich die Sitzungs-ID als Identifizierungsmerkmal benötigt wird.

Wird jedoch zusätzlich die User-Agent-Kennung (und gegebenenfalls IP-Adresse) zur Identifikation verwendet, wird es schon schwieriger. Zudem kann die Sitzungs-ID regelmäßig gewechselt werden, sodass sie nur für eine geringe Dauer gültig ist (beispielsweise fünf Minuten), um zusätzlich die Sicherheit zu erhöhen.

__________________
Markus Wulftange

Ich habe gelesen, dass einige Internet Provider, wie z.B. wohl auch AOL, fast bei jedem Seitenaufruf Ihren Kunden eine neue IP zuweisen.. Also wird die zusätzliche Erkennung des "wahren" Users über die IP Adresse für solche Internet User zum Stolperstein, oder nicht?

Ich kenne nur einen wirklich guten Grund, Sessions in einer DB abzuspeichern. Und zwar der, wenn der Server gemeinsam von mehreren Leute genutzt wird; also alle den gleichen Zugriff auf den SessionSavePath haben. Dann macht es wohl Sinn, dass ganze in ne Table zu stopfen, da man da in der Regel nur "selber" ran kommt.


Oder liege ich Grundlegend falsch?

__________________
CSS-FAQ beantwortet die meisten Fragen | Retro coding gegen Divitis | Code validieren & posten für Hilfe

Mir ist bzw. war nicht bewusst, dass sowas unsinniges gemacht wird. In dem Fall ist das natürlich ungünstig, da könnte man die Prüfung auf die Browserkennung reduzieren, was allerdings wieder mehr Möglichkeiten für Angreifer eröffnet. Evtl. reicht es auch die IP auf die ersten 2-3 Blöcke zu reduzieren.

Der Name der Session (die Session-ID) wird in einem Cookie gespeichert auf dem Rechner des Users.

Mit der Authentifizierung übertreibt ihr es aber nach meiner Meinung, sofern ihr die eingebauten PHP Session Funktionen nutzt - die Session wird ja hier nicht nach irgendwelchen Zufällen generiert und zugewiesen, sondern pro User (=IP) und auch Browser. Sicherheitslücken gibt es natürlich immer und überall, aber in PHP selbst wurden schon einige Vorkehrungen getroffen.

Versucht mal, euch in ein System mit Firefox einzuloggen und benutzt die Session dann zeitgleich im IE - es wird nicht funktionieren.

__________________
“My software never has bugs. It just develops random features ...”

» DevShack - die Website des freien Webentwicklers Boris Bojic

PHP selbst bringt keine solche Sicherheitsmechanismen mit, die müssten nachträglich implementiert werden. Bei PHP dient allein die Sitzungs-ID der Identifikation eines Computers mit einer Sitzung.
Ein ähnlicher Hinweis ist übrigens auch im PHP-Handbuch im Abschnitt Sessions und Sicherheit zu lesen.

__________________
Markus Wulftange

Das liegt allein daran, dass das Cookie nur in dem Browser gesetzt wird den du gerade nutzt.

Eben - allein deswegen kann niemand anderes mit der Session etwas anfangen, da das Cookie fehlt.

Das klappt natürlich nur dann, wenn man die SessionID in einem Cookie speichern lässt und nicht z.B. via URL überträgt. Das kann man via PHP oder .htaccess (je nach Server) so einstellen:

php_flag session.use_trans_sid 0
php_flag session.use_only_cookies 1

Zu den Sicherheitsmechanismen - es gibt massig Diskussionen darüber, wie man "sicherstellen" kann, dass es ein und der selbe User ist. IPs kann man vergessen, da sie entweder ständig dynamisch sind (AOL) oder durch eine Firewall garnicht erst übermittelt werden können. Browserkennung? Kann man faken oder auch nicht übertragen.

__________________
“My software never has bugs. It just develops random features ...”

» DevShack - die Website des freien Webentwicklers Boris Bojic