Session Sicherheit

**Slava** · 09.05.2006, 01:54

<<Besser usernamen in Session speichern sobald dieser sich erfolgreich einloggt und anschließend jedesmal überprüfen ob ein Username in der Session existiert.>>

jedes mal Username überprüfen muss man nicht (mit Ausnahme, dass du sein Namen in einer Aktion brauchst), sonnst würde die Prüffung auf existenz beliebiger sessionvariable ausreichen, da du session erst bei erfolgreichem einloggen startest.

<< Bei einem erfolgreichen Login würde ich die Session zu einem User in die DB schreiben.>>

da kann ich leider keine direkte sicherheit erhöhung ansehen.
wenn du die sessiondaten unbedingt in db haben möchtest, dann kannst du die function session_set_save_handler für die speicherung session in db anzupassen.
eine regelmäßige session_regenerate_id würde vermutlich mehr Effekt bringen

<<ob ich besser über URL oder über Cookies mache? >>

ohne cookies hasst du mehr schanzen bei dennen die cookies deaktiviert haben.

Risiko:
1) wenn jemand direkt meine session_id sieht und in browser übergibt
( solange session noch Ihr lebensziklus hat, und das ist bei standarteinstellungen 15 minuten nach der letzter Aktion)
kann php das nicht mehr unterscheiden und liefert die gleiche ergebnise an den fremden.
siese situation kann vorkommen
1) wenn jemand dir direkt über den schulter guckt und in der lage ist ein 40stellige Zahl in Kopf zu behalten.

2)du sendest deinem bekanten ein link mit session_id per mail, und der folgt diesem link bevor dein session verfallen ist

3) jemand hat deine leitung gekoppelt oder einfach auf glück einen zahl eingetippt hat , der deiner session_id entspricht
in diesem fall ist eigentlich fast egal, ob es sich um coockis oder url- basierende session handelt

**yezariel** · 09.05.2006, 11:31

Den möchte ich sehen, der mir über die Schulter guckt und sich die Session-ID d7adb5a2414560e1c18eabeg03b0879a merken kann bevor ich den Browser schließe...

**TobiaZ** · 09.05.2006, 11:50

L

jedes mal Username überprüfen muss man nicht (mit Ausnahme, dass du sein Namen in einer Aktion brauchst), sonnst würde die Prüffung auf existenz beliebiger sessionvariable ausreichen, da du session erst bei erfolgreichem einloggen startest.

einer beliebigen var sicher nicht. Und sei es ein x beliebiges Counter-Script (wir hatten das thema gerade im Forum), das auf Sessions setzt. Schon wird jeder Besucher "eingeloggt". Die Prüfung auf Usernamen bietet sich da schon an. Besser noch die ID, die brauchst du mit 99,9%iger Sicherheit sowieso irgendwo in deinem Usermanagement.

da kann ich leider keine direkte sicherheit erhöhung ansehen.

Naja, alleine die Tatsache, dass es nur eine SID pro User gibt, könnte man als erhöhung oder zumindes verschärfung ansehen. Obs gewollt ist, ist dann natürlich die andere Frage. Nicht zu verachten sei an dieser Stelle die zusätzliche SQL-Query pro Seitenaufruf.

<<ob ich besser über URL oder über Cookies mache? >>

ohne cookies hasst du mehr schanzen bei dennen die cookies deaktiviert haben.

Frage und Antwort falsch! Erst Cookies und wenn das nicht geht, dann über URL.

**tStein** · 09.05.2006, 14:36

Du könntest zudem beim Einloggen die IP des Users als Sessionvariable speichern lassen und bei jedem Zugriff die verwendete und die gespeicherte IP vergleichen.
Das ist zwar bei weitem kein hundertprozentiger Schutz, verhindert aber in 99% der Fälle das "versehentliche" Session-Hijacking per URL-Weitergabe an einen Dritten (z.B. per ICQ oder Mail).

**jörgen** · 09.05.2006, 14:45

Vielen lieben Dank für die vielen Antworten.

Werde es nun so machen das ich den Username in der Session speichere und diesen immer überprüfe. Ich denke es ist so doch auch schneller wenn nicht jedes mal noch eine Datenbankabfrage ausgeführt werden muss.

Die Speicherung der Session ID werde ich dann über Cookies realisieren und auf der Startseite darauf hinweisen.

Muss jetzt nur noch den Login mit SSL irgendwie hinbekommen ...

Grüße, Jörgen

**Slava** · 09.05.2006, 14:46

Re: L

Original geschrieben von TobiaZ
einer beliebigen var sicher nicht. Und sei es ein x beliebiges Counter-Script (wir hatten das thema gerade im Forum),....

von Scht der Anwendug wäre es bei 99.9% Sinnvoll.
Aber die Frage war Sicherhet, und Vorraussätzung, dass session erst bei Einlogen gestartet wird.(Sieh oben)
Wenn session vor dem Einlogen andere Variablen gesetzt wurden, dann muss man sie natürlich auseinander halten und auf existenz einer session_variable, die erst bei erfolgsreichem Einlogen gesetzt wurde überprüfen.

Naja, alleine die Tatsache, dass es nur eine SID pro User gibt, könnte man als erhöhung oder zumindes verschärfung ansehen. Obs gewollt ist, ist dann natürlich die andere Frage. Nicht zu verachten sei an dieser Stelle die zusätzliche SQL-Query pro Seitenaufruf.

Ich sehe in keinem Fall aus der Sicht Sicherhet, die Eintragung von SID in die Tabelle , als Verschärfung von Sicherheit.
Weil SID in diesem Fall überhaupt keine Rolle spielt.
SID wird von system gegeben, und so lange es existiert, ist auch der User als aktiv gemeldet.
Was kann ich den mit SID in DB anfangen?(über Statistiken sprechen wir nicht)
Wie kann ich es zusätzlich benutzen um sicher zu stellen, dass es der Richtige User ist?
Und Warum muss ich das machen, wenn system das schon von alleine macht, und die variablen mit dazugehörigen SID selbstätig abspeichert?

wenn wir unbedingt die Werte von session dauerhaft abspeichern wollen, dann können wir das durch anpassung von session_set_save_handler machen, aber Sicherheit bleibt nach meinem Wissenstand kaum dadurch erhöht

Frage und Antwort falsch! Erst Cookies und wenn das nicht geht, dann über URL.

das ist natürlich eine profesionele Lösung, die alle fälle mit session abdeckt, aber auch ein zusätzlicher Aufwand und vermutlich besondere Server-konditionen fördert.
ini_set wird leider nicht von jedem Anbieter angeboten, obwohl die Problem sich auch durch output_add_rewrite_var vereinfacht lösen lässt
------------
sorry für mein deutsch

**jörgen** · 09.05.2006, 14:55

Re: Re: L

Original geschrieben von Slava
von Scht der Anwendug wäre es bei 99.9% Sinnvoll.
Aber die Frage war Sicherhet, und Vorraussätzung, dass session erst bei Einlogen gestartet wird.(Sieh oben)
Wenn session vor dem Einlogen andere Variablen gesetzt wurden, dann muss man sie natürlich auseinander halten und auf existenz einer session_variable, die erst bei erfolgsreichem Einlogen gesetzt wurde überprüfen.

Genau so mache ich es jetzt bzw will ich es jetzt machen. Die IP überprüfe ich zusätzlich wobei es natürlich nicht 100% Schutz (Proxys...) bietet.

Zudem schließe ich die Session nach 30min inaktivität.
session_regenerate_id kann ich dummerweise nicht verwenden da PHP 4.1.x im Einsatz ist.

**mrhappiness** · 09.05.2006, 15:02

Re: Re: Re: L

Original geschrieben von jörgen
session_regenerate_id kann ich dummerweise nicht verwenden da PHP 4.1.x im Einsatz ist.

Wenn du dir Gedanken über die Sicherheit deiner Anwendung(en) machst, solltest du da ansetzen und ein Update der PHP-Version anstreben

**Slava** · 09.05.2006, 15:04

mach mit ip keine Spielchen. ich habe schon in diesem forum erfahren, dass etwa 20 % von ip sich ständig dynamisch ändern.
Und ich glaube nicht, dass du 20% von deinen User in der mitte von deiner Anwendung absolvieren willst.
(ich wiederhole aber, dass 20% habe ich aus diesem Forum und nicht aus der offiziellen statistiken)

**jörgen** · 09.05.2006, 15:11

Re: Re: Re: Re: L

Original geschrieben von mrhappiness
Wenn du dir Gedanken über die Sicherheit deiner Anwendung(en) machst, solltest du da ansetzen und ein Update der PHP-Version anstreben

Ist leider nicht möglich da das ganze an meiner Hochschule eingesetzt wird

mach mit ip keine Spielchen. ich habe schon in diesem forum erfahren, dass etwa 20 % von ip sich ständig dynamisch ändern.

Vielen Dank für den Hinweis. Diese Gefahr war mir gar nicht bewusst. Die Homepage wird von vielen Informatiker benutzt werden. Könnte mir daher vorstellen das es evtl. auch einge gibt die ihre IP dynamisch ändern.

**tStein** · 09.05.2006, 15:26

20% ist aber eine extrem unrealistische Zahl (Quelle?)
OK, es gibt viele DSL-User mit Zwangstrennung, aber da passiert das nur alle 24 Stunden.
Die IP-Überprüfung könnte man allerdings auch nur auf die anwenden, bei denen die Session-ID mangels aktivierten Cookies per URL propagiert werden muss. Sie soll ja sowieso, wie oben bereits geschrieben, nur gegen das "versehentliche" Session-Hijacking schützen und ist bei Verwendung von Cookies daher überflüssig.

**mrhappiness** · 09.05.2006, 15:29

Ob DIe Session-ID per URL, Formular oder Cookie übertragen wird, wäre für einen Vergleichm it einer evtl. gespeicherten IP völlig irrelevant...

Aber mal ernsthaft:
Angenommen, es wäre sinnvoll, die IP zu berücksichtigen: Meint ihr nicht, die PHP-Entwickler hätten das mittlerweile eingebaut? Zumindest als eine Option der Art "session.compare_ip"?

Da sie es nicht haben:
Haben sie's vergessen?
Können sie's nicht?
Ist es nicht sinnvoll?

**wahsaga** · 09.05.2006, 15:36

Original geschrieben von mrhappiness
Angenommen, es wäre sinnvoll, die IP zu berücksichtigen: Meint ihr nicht, die PHP-Entwickler hätten das mittlerweile eingebaut? Zumindest als eine Option der Art "session.compare_ip"?

Na ja, sie haben sich ja auch nicht abhalten lassen, session.referer_check einzubauen - dessen Sinnhaftigkeit darf man ja wohl fast enauso stark bezweifeln.

**tStein** · 09.05.2006, 15:59

Original geschrieben von mrhappiness
Ob DIe Session-ID per URL, Formular oder Cookie übertragen wird, wäre für einen Vergleichm it einer evtl. gespeicherten IP völlig irrelevant...

Natürlich. Allerdings tritt das Problem dass die Session-ID in der URL steht bei Speicherung/Weitergabe über Cookies/Formular ja nicht auf. Und falls es wirklich das erwähnte Problem mit der hohen Anzahl der User mit sich schnell ändernder IP geben sollte (was ich bezweifle, allerdings hab ich auch keine Zahlen anzubieten) könnte man die Anzahl der Betroffenen so stark einschränken.

Btw: Hast du schonmal versucht einem "normalen" Nutzer zu erklären, warum sein Kumpel als er eingeloggt ist, nur weil er ihm nen Link zu irgendeiner Seite geschickt hat?

Session Sicherheit