session.class.php

[Jens-A. Koch]

Session.class.php Anforderungen:

1. Die Sessions sollen in der Db abgelegt werden, dementsprechend wird der Sessionhandler modifiziert. Der Session-Table der Db dient dann auch zum Lookup, wer & wo & wann online ist.

2. 2 Wege müssen unterstützt werden:

A. Beim User sind Cookies aktiviert
In diesem Fall wird ein Session-Cookie gesetzt.
Dieses wird nach dem Session-Namen benannt und mit der sessionid gefüllt.

Beim Seitenwechsel wird geprüft, ob ein solches Cookie existiert.
Wenn ja, erfolgt eine Prüfung ob SessionId aus dem Cookie mit der SessionId aus der Db übereinstimmt.

Im Anschluß erfolgen dann Sicherungsprüfungen, z.B. ob der username oder user_id in der Db-Session auch den Werten des Cookies entspricht.

Es ergeben sich für diesen Weg die folgenden Einstellungen:

Code:

ini_set("session.use_cookies","1"); // cookies benutzen
ini_set("session.use_only_cookies","1"); // nur cookies erlauben, SID in URL wird nicht beachtet
ini_set("session.use_trans_sid","0"); // sichergehen das sid nicht automatisch angehängt wird

Stichwort Cookie-Lifetimes?
Insbesondere für das Remember-Me Feature
todo: prüfen!
session.cookie_lifetime
session.cookie_expire

B. Beim User sind Cookies deaktiviert

Für den Fall das Cookies deaktiviert sind, muß die SessionID von Seite zu Seite übergeben werden, d.h. es muß die SessionID an die URL angefügt werden.

Fest steht also:  ini_set("session.use_cookies","0");
   
Einerseits ist es möglich manuell alle Links um .php?".sessionname()."=".sessionid()." zu ergänzen.

Desweiteren kann durch die ini_set("url_rewriter.tags","tags....") angegeben werden, bei welchen Tags automatisch um die SessionId ergänzt werden soll.
Das Problem scheint hier zu sein, daß es vom XHTML-Standard abweicht.
Demnach ist ini_set("url_rewriter.tags",""); zu setzen.

Andererseits kann durch die ini_set-Einstellung session.use_trans_sid = 1 eine Transparenz bzw. Unsichtbarkeit der Session eingestellt werden. Das Anhängen erfolgt auf 2 Arten:
1. wenn ein <form> field gegeben ist, wird die SID als Hidden Field im POST übertragen
2. ansonsten wird die SID einfach die URL angehängt.
Ein Sicherheitsproblem ergibt sich nicht, da die SID nur bei relative Links angefügt wird, und relative Links können nur auf die Herkunfts-Domain aufgelöst werden.

Demnach folgende Settings:

Code:

ini_set("session.use_cookies","0"); // cookies nicht benutzen
ini_set("session.use_only_cookies","0"); // SID in URL wird beachtet
ini_set("session.use_trans_sid","1"); // sichergehen das sid automatisch angehängt wird
ini_set("url_rewriter.tags",""); // jedoch nicht per url_rewriting

3. Sicherungen:

A. Session-Timeout, d.h. das Zeitfenster der Session wird begrenzt.

session.gc_maxlifetime gibt an wann die Session in den Müll kommt, also aus der Db rausfällt.

B. ... IP, referer - gegenprüfung ?? Sinnvoll?
Siehe Ausführungen im anderen Thread bezüglich der Sicherungsvorschläge.

IP: Problem AOL User mit wechselnder IP
REFERER: in session ablegen bzw. session.referer_check
BROWSER: in session ablegen , viele verwenden gleiche Systeme/Software
XP+Firefox ... Kennung wäre identisch

[xsign.dll]

jo...
is drin hab da heut mal ein wenig mit cookies gearbeitet und schlagartig in nem forum wo ich aktiv bin nen xss-exploit gebastelt *lol*
bb-code + javascript ist einfach nur ein fest

aber nochmal zu sessions:
solln bei aktivierten cookies die session gespeichert werden? mir prinzipiell egal, sieht halt a bissl sinnlos aus weil der cookie is ja genau das, was die db+sessionid inne hat.

also wie gesagt: das sind nur 2 zeilen code...
apropo...
beim klicken auf einen link, soll sich dann die nächste angehängte session_id ändern? somit kann man sozusagen eine seite nur solang aufrufen, bis jmd. weiter klickt. -> weniger risiko bei copy'n'paste (falls ip/hostname/referrer ausfallen...). Wird dann aber schwierig mit dem "Zurück" Button... der könnte dann nichtmehr funktionieren... hmmm.. ok eher dagegen...

[Jens-A. Koch]

Die Verwendung von Cookies erfolgt so, daß du eine neue Seite aufrufst:

1. deine Session erstellt und in der Db abgelegt wird
2. ein SessionCookie auf deine Platte gesetzt wird

wechselst du nun die Seite, wird geprüft ob, der SessionCookie existiert.
Das kann zB ein Hash sein mit user_id|sessionid.
Die entsprechende Session wird anhand dieser sessionid aus der Db geholt.
Der Cookie ist als nur der Zeiger auf die Session in der Db.

Löscht nun der User den Cookie auf der Platte, dann fällt der Zeiger weg und die Session ist futsch. Die entsprechende SessionId in der Db wird nach einiger Zeit durch inaktivität gelöscht.

---
Beim klicken auf einen Link soll sich die angehängte session_id natürlich nicht ändern.
Sonst würde die Session ja nicht fortgesetzt, sondern eine neue begonnen.
Sinn der Session ist ja gerade diese über mehrere Seiten mit nehmen zu können (Warenkorb, etc.). Daher auch das Angehänge für die nächste Seite.

[xsign.dll]

k - got it
schreib mich mal an, falls du das irgedwie liest

[hajo]

streich session use trans sid von der liste, es ist eine veraltete und enorm unsichere version, zudem erscheinen die sessions dann sogar überall angehängt und sind einfach für hacker "ablesbar".

zudem bin ich dafür 1. nur session cookies zu benutzen und diese 2. zu erzwingen und 3. eine warnung für den fehlerfall auszugeben damit der user bescheid weiß das er cookie mäßig im browser etwas erlauben bzw. aktivieren muss!

[xsign.dll]

nö - cookies only is nicht drin... wir programmiern hier doch schon ein bissl auf kompatibilität und stabilität.
ich kenn gute möglichkeiten, da abhilfe zu schaffen.
Es geht schlichtweg darum, dass die User auch auf Arbeit oder von einem entfernten PC ins CMS kommen. Das hat auch was mit gutem Programmierstil zu tun...
Angehängte Sessions via $_GET ist die standard Variante - und selbst bei nem copy'n'paste kommt man damit nicht weiter, da sich die ip, der hostname und der user-agent ändert.

[Jens-A. Koch]

Das Session-Handling ohne Cookies dient dazu die Nutzer nicht vom System auszuschließen.
Der Regelfall für angemeldete User ist sicher die Verwendung von Cookies.

Sicher sind beide Varianten nicht. Aber man kann sie relativ absichern.

[hajo]

klar kann man basis features wie sprach wechsel oder zeitzonen einstellungen und so weiter für gäste über sessions ohne cookie lösen, allerdings für user logins würde ich cookies erzwingen, es ist einfach die sicherste variante und erspart einige zusätzliche absicherungen.

GET-Übermittlung der Session-ID kommt für mich auf garkeinen fall in frage bei user logins und eine POST-Weitergabe wie es vor paar jahren noch beliebt war erst recht nicht.

[xsign.dll]

@hajo:
lies dir bitte mal das hier durch
http://www.datenschutzverein.de/Pressemitteilungen/2001_schwarzeliste.pdf

oder das hier:
http://www.datenschutzverein.de/schwarze_liste.html

und analog dazu nochmal dieser thread:
http://www.flashforum.de/forum/showthread.php?t=205574

es gibt sogar ganze vereine, die das erzwingen von cookies boykottieren...
Ein Sicherheitsrisiko stellt beides, Cookies als auch GET, dar - das kannste drehn und wenden wie du willst =)

/edit:
Dabei fällt mir grad was ein - wir wäre es denn, wenn wir sogenannte "Sicherheitsprofile" erstellen? 3 Stufen, "Hoch", "Mittel", "Low".
Der Webmaster kann dann immer zwischen den 3 Stufen switchen im ACP. Bei "Hoch" gibt es halt keine $_GET Sessions, bei Mittel gibt es $_GET + $_COOKIE etc.
Das lässt sich auf andere Themenbereiche auch sehr gut abstrahieren und erspart uns solche Diskussion über Sinn und Unsinn von Kleinkram... Ist natürlich nen Mehraufwand, aber ein sehr sehr geiles Feature...

[hajo]

Was JavaScript und vor allem Active-X angeht stimme ich den Infos dort zu, allerdings ist die Liste von 2001 und Cookies sind inzwischen das normalste auf der Welt.

Wäre ne Maßnahme dein Vorschlag das man Intern als Admin einstellen kann ob bei Logins ein Cookie erzwungen werden soll oder es auch ohne geht.

[xsign.dll]

die infos auf datenschutzverein.de sind nicht von 2001... nur der eine artikel dort... dasgleiche steht nochmal in den infos zur schwarzen liste, welche immer aktualisiert wird...

[Jens-A. Koch]

Um die Diskussion zu beruhigen: Das ist doch einstellbar, ob Cookies only oder Cookies und URL.