[php] Session Handling

[Lutz Zetzsche]

Hi Ralf,


Am Samstag, 21. Oktober 2006 15:04 schrieb Ralf Eggert:
> ich wollte einmal in die Runde fragen, wie ihr das mit dem Session
> Handling so handhabt. Hier ein paar Aspekte:
>
> 1a) Der Session Cookie ist nur für Dauer der Sitzung gültig.
>
> 1b) Der Session Cookie ist auch nach dem Schließen des Browsers
>     weiterhin gültig.

ich wähle aus Datenschutzgründen grundsätzlich immer die Variante 1.a). 
Die Variante 1.b) halte ich für ein Sicherheitsrisiko, weil Du nicht 
wissen kannst, ob hier derselbe Benutzer auf die Daten zugreift, der 
vorher auf die Daten zugegriffen hat. Sollten auf diese Weise einmal 
personenbezogene Daten in die falsche Hände geraten, wird das mit 
Sicherheit dem Websitebetreiber als Sicherheitslücke und Verstoß gegen 
die Datenschutzbestimmungen angelastet, weil ein Session-Cookie ja ein 
Cookie für die Session ist und man als Anwender davon ausgehen können 
sollte und darf, daß die Session dann auch clientseitig beendet ist, 
wenn das Browserfenster geschlossen worden ist.


> 2a) Wenn der Session Cookie nicht akzeptiert wird, wird die Session
> ID an alle Links eurer Seite angehängt (IMHO großes
>     Sicherheitsproblem).
>
> 2b) Wenn der Session Cookie nicht akzeptiert wird, gibt es keine
>     Alternative. Zum Einloggen ist somit zwingend ein Cookie zu
>     akzeptieren

Variante 2.b) käme bei mir nur für sicherheitsunkritische Sessions in 
Frage, die niemals im Zusammenhang mit einem Benutzerlogin stehen und 
damit auf keinen Fall personenbezogen Daten enthalten können.

Da die angehängten Session-IDs nicht nur unsicherer als Cookies sind, 
sondern auch im Zusammenhang mit Suchmaschinen Ärger machen können, 
tendiere ich mittlerweile aber allgemein dazu, nur noch die Variante 
2.b) verwenden zu wollen.

Ob Session-ID oder Session-Cookie verwendet wird, macht ja aus 
Datensicht keinen Unterschied. Von daher müßte also ein Anwender, der 
den Cookie nicht akzeptieren will, auch die Session-ID ablehnen. Und 
die Session-ID schützt die Anwenderdaten deutlich schlechter als ein 
Session-Cookie. Von daher ist es auch im Interesse des Anwenders, den 
Cookie und nicht die ID zu verwenden.

Man kann natürlich argumentieren, daß der Anwender keinen Cookie 
aufgezwungen bekommen sollte, wenn er keinen möchte, aber ist es nicht 
auf der anderen Seite so, daß man dann mit einer Session-ID sein 
Selbstbestimmungsrecht aushebelt, weil man eben doch mit der Session-ID 
genau das macht, was man mit dem Session-Cookie gemacht hätte? Außerdem 
haben die Browser heute ein sehr ausgefeiltes Cookiemanagement. Die 
Zeiten, wo man entweder alle Cookies annehmen oder ablehnen konnte, 
sind ja vorbei. :-)


> 3a) Jeder Besucher der Seite bekommt immer einen Session Cookie
>     zugeteilt.
>
> 3b) Es werden nur Session Cookies verteilt, wenn sie wirklich
> notwendig sind. Ich nenne es mal den Ansatz der Cookie-Sparsamkeit.

Eindeutig ausschließlich Antwort 3.b). Cookies sind ja verpönt. Daher 
sollte man die Besucher nur dann mit Cookies "irritieren" ;-), wenn es 
wirklich Sinn macht. Wenn Du beispielsweise eine Website hast, die 
grundsätzlich überall den Einsatz eines Session-Cookies erfordert, dann 
kommt die Variante b) in der praktischen Umsetzung dann Variante a) 
gleich.


> Meiner Meinung nach ist eine Kombination aus 1a), 2b) und 3b) der
> beste Ansatz.

Das sehe ich genauso. Ich habe das früher etwas anders gesehen - da kam 
der Anwender im Programmierer zu sehr durch ;-) -, aber heute würde ich 
mich soweit aus dem Fenster hängen zu behaupten, daß aus Datenschutz-, 
Sicherheits- und Anwendersicht diese Kombination die einzig sinnvolle 
ist. Ich bin mit solch absoluten Aussagen in der Regel sehr vorsichtig, 
aber hier sehe ich das heute tatsächlich so. Wie gesagt, früher habe 
ich da bezüglich 2. etwas anders gedacht.


> Zwei Fragen hierzu:
>
> 1. Wie handhabt Ihr es mit den Sessions bei euren Projekten?

Immer 1.a); in der Regel 2.b), nur 1x 2.a) (bei der Suche auf meiner 
Website); immer 3.b).

> 2. Ist der Ansatz der Cookie-Sparsamkeit mit dem in PHP integrierten
>    Session Handling überhaupt realisierbar? Bei session_start() wird
>    ja immer eine Session erstellt und ohne session_start() kann nicht
>    auf $_SESSION zugegriffen werden.

Wenn Dein PHP so konfiguriert wäre, daß die Session auf Autostart 
gesetzt wäre, obwohl die Session gar nicht immer gebraucht wird, dann 
verstießest Du gegen die Session-Sparsamkeit. Es spricht aber nichts 
dagegen, eine Session zu starten, wenn sie benötigt wird, und es 
spricht auch nichts dagegen, in diesem Fall dann eben den 
Session-Cookie zu setzen und nicht die Session-Id zu verwenden. Im 
Bezug auf die Session geht es also nicht um Cookie-Sparsamkeit, sondern 
um Session-Sparsamkeit, wobei es allerdings so ist, daß ein 
Session-Cookie sparsamer ist, als die in der Session gespeicherten 
Informationen alternativ in mehreren Cookies zu speichern... ;-)

> 3. Gibt es Einschränkungen und Probleme bei der Verwendung vom in
>    PHP integrierten Session Handling, auf die man nicht unbedingt
>    sofort stößt.

Mir sind keine in meiner Praxis noch keine Einschränkungen und Probleme 
untergekommen. :-)


Viele Grüße
Lutz