nicht angemeldet
Session-Daten in DB?
Hallo forum!
Ich habe da mal eine Frage bezüglich Sessions in PHP, die bei mir mittels Cookies und NICHT über einen zusätzlichen get-Parameter realisiert werden sollen. Mir stellt sich jetzt jedoch die Frage, wie ich das ganze möglichst sicher gestalte. Bisher habe ich das immer so gehandhabt, das wenn die authorisierung erfolgreihc war, ein session gestartet wurde und die Variable $_SESSION['login'] auf true gesetzt wurde.
Was haltet ihr nun vor der Möglichkeit stattdessen, in einer existierenden Usertabelle noch zusätzlich die Felder 'lastLogin' und 'code' hinzuzufügen, wobei bei erfolgreicher anmeldung, in $_SESSION['code'] und das TabellenFeld mittels uniqid ein code reingeschrieben wird. Wenn diese dann nicht zusammenstimmen, muss man sich eben neu authentifizieren. In lastlogin kommen eben die zeit des letzten Aufrufs und diese wiederum mehr als eine Stunde, etc. zurückliegt, fliegt der User ebenfalls raus.
Was haltet ihr von dieser Geschichte oder gibt es noch etwas besseres, um das so sicher wie möglich zu handhaben.
Danke schonmal, waterloo
-
hi,
Was haltet ihr nun vor der Möglichkeit stattdessen, in einer existierenden Usertabelle noch zusätzlich die Felder 'lastLogin' und 'code' hinzuzufügen, wobei bei erfolgreicher anmeldung, in $_SESSION['code'] und das TabellenFeld mittels uniqid ein code reingeschrieben wird. Wenn diese dann nicht zusammenstimmen, muss man sich eben neu authentifizieren.
und was an diesem prozedere soll die sicherheit gegenüber der anderen methode erhöhen?
In lastlogin kommen eben die zeit des letzten Aufrufs und diese wiederum mehr als eine Stunde, etc. zurückliegt, fliegt der User ebenfalls raus.
kannst du genauso gut machen, in dem du den timestamp in der session ablegst. und per default läuft die gültigkeit einer session sowieso nach 24 minuten nichtbenutzung ab.
Was haltet ihr von dieser Geschichte
du scheinst zu glauben, die sicherheit erhöhen zu können, in dem du möglichst viele techniken (seesions von PHP, datenbank, ...) einsetzt - ist aber quatsch. da könntest du genauso gut den server grün anstreichen, erhöht die sicherheit auch nicht weiter.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
hallo wahsaga!
kannst du genauso gut machen, in dem du den timestamp in der session ablegst. und per default läuft die gültigkeit einer session sowieso nach 24 minuten nichtbenutzung ab.
Wo steht das denn?? Im PHP-Maual habe ich da nichts gefunden.
Was haltet ihr von dieser Geschichte
du scheinst zu glauben, die sicherheit erhöhen zu können, in dem du möglichst viele techniken (seesions von PHP, datenbank, ...) einsetzt - ist aber quatsch. da könntest du genauso gut den server grün anstreichen, erhöht die sicherheit auch nicht weiter.
heißt das also, man kann nichts weiter machen, um sessions sicherer zu gestalten? manche tragen da ja noch eine IP ein, aber das gibt doch oftmals Probleme oder?
mfg
-
Hi waterloo,
heißt das also, man kann nichts weiter machen, um sessions sicherer zu gestalten? manche tragen da ja noch eine IP ein, aber das gibt doch oftmals Probleme oder?
Was willst du an einem (weitgehenst) sicheren System noch verbessern?
Und ja, die IP ist eine schlechte Idee - da gibt es eben keine eindeutige Zuordnung, mehrere Leute können sich eine IP teilen, ein Besucher kann aber auch ständig mit einer anderen IP kommen (ist z.B. bei AOL der Fall, ständig wechselnde Proxyserver).
MfG, Dennis.
--
Mein SelfCode: ie:{ fl:( br:> va:) ls:[ fo:) rl:( n4:# ss:) de:] js:| ch:{ sh:| mo:} zu:|
Das Leben ist kein Warenhaus - es nimmt nichts zurück. (Anette Louisan) -
Hello,
heißt das also, man kann nichts weiter machen, um sessions sicherer zu gestalten? manche tragen da ja noch eine IP ein, aber das gibt doch oftmals Probleme oder?
man sollte auf einem typischen shared-Hoster-System auf jeden Fall den session.safe_path in ein Verzeichnis innerhalb seines basedirs verlegen. Das hat natürlich nur sinn, wenn open_basedir überhaupt gesetzt ist für _alle_ User des Systems. Das gleiche gilt für upload_tmp_dir.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
hallo nochmal!
heißt das also es reicht, wie unter http://aktuell.de.selfhtml.org/tippstricks/php/loginsystem/ beschrieben es zu machen? warum wird hier die session schon gestartet bevor überhaupt eine authenifizierung stattgefunden hat?
mfg waterloo
-
Hi waterloo,
heißt das also es reicht, wie unter http://aktuell.de.selfhtml.org/tippstricks/php/loginsystem/ beschrieben es zu machen?
du meinst http://aktuell.de.selfhtml.org/tippstricks/php/loginsystem/ - ja, das dürfte für den Anfang doch mal ganz gut für dich sein.
warum wird hier die session schon gestartet bevor überhaupt eine authenifizierung stattgefunden hat?
Was verstehst du unter "Authentifizierung"? Das Vergleichen der Zugangsdaten?
Und warum soll die Session erst danach gestartet werden? So ein Gemurks habe ich früher auch mal ausprobiert: Nur eingeloggte User haben eine Session, wer keine Session hat ist auch nicht eingeloggt, wer eine hat ist aber eingeloggt. Das ist IHMO viel zu kompliziert.
Du kannst einfach in jedem PHP Script oben session_start() verwenden, dann wird wenn möglich eine alte Session aufgegriffen oder sonst eine neue angelegt. So kannst du auch bequem für jeden User Daten ablegen und auf einer anderen Seite wieder aufrufen. Ein Schalter in dem du festhälst ob der Besucher nun eingeloggt ist oder nicht, ist dann allerdings praktisch.
MfG, Dennis.
--
Mein SelfCode: ie:{ fl:( br:> va:) ls:[ fo:) rl:( n4:# ss:) de:] js:| ch:{ sh:| mo:} zu:|
Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher. (Albert Einstein) -
Hi,
warum wird hier die session schon gestartet bevor überhaupt eine authenifizierung stattgefunden hat?
da das nun erklaertermassen eine der wenigen Sachen innerhalb des Bereichs der IT ist, die ich vollstaendig verstanden habe, moechte ich da nun doch ein paar Worte der Diskussion beifuegen.
Wir haben um Sicherheit zu implementieren in aller Regel die Entitaeten 'Sitzungen', 'Nutzer' und 'Rechte'. Wobei wir in aller Regel zwischen 'Sitzungen' und 'Nutzer' eine "1:n"-Beziehung und zwischen 'Nutzer' und 'Rechte' ebenfalls eine "1:n"-Beziehung zu pflegen haben (ja, ich weiss, es kaeme bei letzterer Beziehung auch eine "n:m"-Beziehung in Frage).
In der Folge wollen wir nun versuchen zu verstehen, welche Wesen hinter den o.g. Entitaeten stehen.
'Sitzungen':
Eine Sitzung ist so zu sagen die Identifikationsschicht und entsteht dann, wenn ein Client sich mit einem System erfolgreich verbunden hat. (Da wir hier, wie eigentlich immer, einen Nachbau der Realitaet zu bearbeiten haben, stellen wir uns den o.g. Sachverhalt einfach wie einen Begin einer sozialen Beziehung vor.)'Nutzer':
Ist eine Sitzung gegeben, so entsteht naturgemaess oft das Beduerfnis den Kooperationspartner kennen zu lernen. Zu diesem Zweck gibt es oft eine Tabelle, die es erlaubt bestimmte Nutzer einem System gegenueber erkennbar zu machen. ("Hallo, Herr Mueller", sagt die Frau im Geschaeft, nachdem sie denselben anhand einer Gesichtsprobe zu erkennen glaubte. Im Bereich der IT erfolgt die Authentifizierung aber sicherer bspw. ueber Angabe eines Namens und eines kennworts, oder "noch sicherer" ueber Smartcards und so)'Rechte':
Ist der Nutzer nun authentifiziert und meldet sich dieser zukuenftig ueber einen Verweis auf eine authentifierte Verbindung, so liegt es nahe diesen der Anforderungslage entsprechend zu berechtigen. Dafuer haben wir das Wesen 'Rechte'. Bei jedem Datenzugriff sollte also nun ueberprueft werden a) welcher Nutzer auf der gemeldeten Verbindung "sitzt" und b) welche Rechte dieser Nutzer hat und ob diese in Bezug auf den angeforderten Datenzugriff ausreichend sind.
Das nennt sich dann Autorisierung ("Identifikation+Authentifikation+Autorisierung==Sicherheit").Nunmehr sollte also die o.g. Frage beantwortet sein. Uebrigens solltest Du mit "modernen" Verschluesselungsverfahren sicherstellen, dass o.g. Kommunikation nicht "abgehoert" werden kann.
Gruss,
Ludger-
Hello,
'Rechte':
Ist der Nutzer nun authentifiziert und meldet sich dieser zukuenftig ueber einen Verweis auf eine authentifierte Verbindung, so liegt es nahe diesen der Anforderungslage entsprechend zu berechtigen. Dafuer haben wir das Wesen 'Rechte'. Bei jedem Datenzugriff sollte also nun ueberprueft werden a) welcher Nutzer auf der gemeldeten Verbindung "sitzt" und b) welche Rechte dieser Nutzer hat und ob diese in Bezug auf den angeforderten Datenzugriff ausreichend sind.
Das nennt sich dann Autorisierung ("Identifikation+Authentifikation+Autorisierung==Sicherheit").'Rechtegültigkeit'
Rechte können entweder festgestellt werden, wenn ein Nutzer sich authentifiziert und in die Session (Sitzung) zurückgetragen werden (dort eingetragen werden) oder aber bei jeder Anfrage erneut festgestellt werden und _nicht_ in die Session eingetragen werden. Zweiteres Verfahren halte ich für besser, da man so bei langanhaltenden Sessions die Rechte auch während der Sitzung verändern kann. Die Auswirkungen bei gekürzten Rechten könnten dann aber sogar wieder bis auf die Sessiongültigkeit zurückschlagen.Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi,
'Rechtegültigkeit'
Du versuchst doch nicht etwa eine vierte Entitaet dem Konzept beizufuegen?
Rechte können entweder festgestellt werden, wenn ein Nutzer sich authentifiziert und in die Session (Sitzung) zurückgetragen werden (dort eingetragen werden) oder aber bei jeder Anfrage erneut festgestellt werden und _nicht_ in die Session eingetragen werden. Zweiteres Verfahren halte ich für besser, da man so bei langanhaltenden Sessions die Rechte auch während der Sitzung verändern kann.
Zweites Verfahren ist wesentlich besser. (Ist ja genauso mit dem Session-Timeout, das auch nicht in die Session selbst geschrieben werden sollte. Stattdessen sollte beim Datenzugriff ueberprueft werden, ob die Sitzung ausgetimt ist.)
Die Auswirkungen bei gekürzten Rechten könnten dann aber sogar wieder bis auf die Sessiongültigkeit zurückschlagen.
Wie meinst Du das?
Gruss,
Ludger-
Hello,
Die Auswirkungen bei gekürzten Rechten könnten dann aber sogar wieder bis auf die Sessiongültigkeit zurückschlagen.
Wie meinst Du das?
Man könnte bei entsprechend abgelaufenen Rechten die gesamte Session kippen (löschen) und eine neue beginnen. Muss man aber nicht.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
-
-
-
Hello,
kannst du genauso gut machen, in dem du den timestamp in der session ablegst. und per default läuft die gültigkeit einer session sowieso nach 24 minuten nichtbenutzung ab.
Das entspricht nicht der Wirklichkeit.
Bei PHP gibt es keinen "Sessionablauf", den muss man selber implementieren.
Es gibt allerdings einen "Garbage Collector", das per Zufallsprinzip nach einer sogenannten "session.gc_maxlifetime" vielleicht die Sessiondatei einsammelt (löscht). Damit wäre dann die Session kaputt, aber nicht ordnungsgemäß beendet!Die irreführende Wahl des Konfigurationsparameternamens hat wohl dazu geführt, dass viele annehmen, dass PHP sich selber um die _maximale_ Lebensduaer der Session kümmern würde. Dieser Parameter müsste eigentlich "session.gc_minlifetime" heißen, da _frühestens_ _nach_ Ablauf dieser Nichtberührungszeit der Sessiondatei diese gelöscht werden darf. Das kann aber auch mal 24 Stunden dauern oder noch länger, je nachdem, wie stark das System belastet ist und wie hoch die Wahrscheinlichkeit session.gc_probability/session.gc_divisor ist.
<cite>
session.gc_divisor coupled with session.gc_probability defines the probability that the gc (garbage collection) process is started on every session initialization. The probability is calculated by using gc_probability/gc_divisor, e.g. 1/100 means there is a 1% chance that the GC process starts on each request. session.gc_divisor defaults to 100.
</cite>siehe http://de2.php.net/manual/en/ref.session.php#ini.session.gc-divisor
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hallo!
Was haltet ihr nun vor der Möglichkeit stattdessen, in einer existierenden Usertabelle noch zusätzlich die Felder 'lastLogin' und 'code' hinzuzufügen, wobei bei erfolgreicher anmeldung, in $_SESSION['code'] und das TabellenFeld mittels uniqid ein code reingeschrieben wird. Wenn diese dann nicht zusammenstimmen, muss man sich eben neu authentifizieren.
und was an diesem prozedere soll die sicherheit gegenüber der anderen methode erhöhen?
bedenke, dass in den meisten Fällen die Session-Daten auch von anderen Usern/Vhosts auslesbar/veränderbar sind. Das ist bei einer Datenbank meist etwas schwieriger - zumindest wenn man die Zugangsdaten nicht auslesen kann. Allerdings ist das Risiko vergleichsweise klein.
In lastlogin kommen eben die zeit des letzten Aufrufs und diese wiederum mehr als eine Stunde, etc. zurückliegt, fliegt der User ebenfalls raus.
kannst du genauso gut machen, in dem du den timestamp in der session ablegst. und per default läuft die gültigkeit einer session sowieso nach 24 minuten nichtbenutzung ab.
Ja, normalerweise reicht das aus, so wird das ja meistens gemacht. Aber wie gesagt, Session-Daten sind zwar nicht von außen veränderbar, aber durch andere Kunden oder auch andere Scripte mit entsprechenden Sicherheitslücken.
du scheinst zu glauben, die sicherheit erhöhen zu können, in dem du möglichst viele techniken (seesions von PHP, datenbank, ...) einsetzt - ist aber quatsch. da könntest du genauso gut den server grün anstreichen, erhöht die sicherheit auch nicht weiter.
Das sehe ich nicht so. Es hängt vor allem von der Server-Konfiguration ab wie sinnvoll derartige Maßnahmen sind. Aber "Quatsch" ist das sicher nicht! Dafür kostet es zusätzliche Datenbankabfragen.
Grüße
Andreas--
SELFHTML Tipps & Tricks: http://aktuell.de.selfhtml.org/tippstricks/
-