[PHP] Über Sessions und Cookies...

[Gast]

Hey erstmal

So langsam wird es Zeit, ein Benutzersystem für meine Seite zu bauen, welches auch Rechteverwaltung beherrscht. Hierfür ist es logischerweise wichtig, dass ein Benutzer anhand irgendwas identifiziert werden kann - bei mir soll das über Accounts laufen, mit Login-/logout, ganz klassisch halt.

Dafür gibts ja eigentlich 2 Wege, so wie ich das bisher sehe: man erzeugt für die User nachm einloggen eine Session und speichert dort so Sachen wie Rechte, Accountnummer und Namen, diese übergibt man dann an die nächste Seite, so dass die Sachen beim Weitersurfen noch vorhanden sind oder kurz gesagt: der User eingeloggt bleibt.
Der zweite Weg scheint über Cookies zu gehen, eigentlich das selbe wie oben, nur dass die Sachen halt lokal gespeichert werden und nichts übergeben werden muss.

Soweit, so gut. Eigentlich hatte ich mich schon für Sessions entschieden - da kann jeder teilnehmen, egal ob er Cookies erlaubt oder nicht, es ist vllt etwas sicherer, da mans aufm Server speichert etc...
Was ich nicht bedacht habe: man muss die Session ID ja wohl per URL übergeben - nein wie hässlich.
Jetzt hab ich die ganze letzte Woche an mod_rewrite rumgeschraubt, damits auch schöne Links gibt ala host.com/user/karlheinz oder host.com/news/1684, das ganze will ich eigentlich nicht mit Sessionids verunstalten. Außerdem gibts da ja immernoch das Problem, wenn User ausversehen die URL mit ihrer eigenen SessId an andere weitergeben etc. Kann man natürlich abfangen, aber naja, dadurch wird die URL auch nicht schöner.

Also doch Cookies? In Forensoftware wie dem vBulletin hier im 3DC sieht man in der URL auch keine Sessionids, wird hier dann auch mit Cookies gearbeitet?

Vielleicht habe ich mich zu wenig eingelesen und man kann die Sessionid auch "unsichtbar" übergeben, ist das so?

mfg

[Gast]

Lieber anderer Gast, danke für deine Antwort.
Du wirst es nicht glauben, aber ich habe im ersten Post vergessen zu Fragen, ob ASP.NET und Co. das ganze besser machen, habs aber vergessen. Denn ein Umzug auf Windows wäre kostenfrei für mich.

Vorerst solll das ganze aber noch mindestens 2 Monate auf PHP laufen!

[The_Invisible]

unsichtbar geht nur wenn du den client zu 100% authentifizieren kannst und es keine bedenken gibt das auf einmal ein anderer client eine session vom anderen bekommt.

am meisten setzt man aber auf cookies die die sessionid gespeichert haben, übergabe per url ist sehr unschön und sehe ich eigentlich nie, auch nicht bei großen sites. eine blöde idee wäre noch die sessionid per hidden-field per post zu übergeben. :D

ansonsten bietet dein webserver vielleicht noch möglichkeiten.

mfg

[Gast]

Okay, Danke schonmal The_Invisible.

Also wenn ich das richtig verstehe, ist die gängige Methode auch Cookies zu benutzen, mit dem feinen Unterschied, dass man darin nur die erstellte Sessionid des Benutzers speichert. Dies hat den Vorteil, dass keine empfindlichen Daten wie PWs etc darin enthalten sind, diese stecken in der Sessionid aufm Server, an welche man mit dem cookie rankommt.

Doch ist das nicht eigentlich noch gefährlicher? Schnappt sich ein Angreifer den Cookie von einem Rechner, kommt er mit der darin enthaltenen ID ja direkt in den entsprechenden Account rein, auch ohne PW.
Man könnte zwar die IPs dann vergleichen - aber dann sperrt man ja noch mehr User aus, als man mit der Cookiegeschichte eh schon tut (denn es gibt ja Provider, welche im Sekundentakt die Client-IP ändern, gehört da nicht AOL dazu?).

Gruß

[Coda]

Man speicher normal die User ID und das Passwort (als Hash!) im Cookie und verifiziert das dann wenn man die Seite läd.

[darph]

Doch ist das nicht eigentlich noch gefährlicher? Schnappt sich ein Angreifer den Cookie von einem Rechner, kommt er mit der darin enthaltenen ID ja direkt in den entsprechenden Account rein, auch ohne PW.

Hier im Forum hast du die Möglichkeit, auch nach Verlassen der Seite eingeloggt zu bleiben. Beim Einloggen mußt du das per Häkchen erst aktivieren. Erst wenn du das Häkchen setzt, wird ein Cookie mit langer Lebensdauer gesetzt. Andernfalls erlischt er mit verlassen der Sitzung a.k.a. Beenden des Browsers.

Wenn ein Angreifer dieses Cookie bekommt, kann er damit eingeloggt als "du" in dieses Forum, ja. Man kann da noch zusätzliche Vergleichswerte einfügen (Browserversion, wird ja nicht alle 3 Tage aktualisiert, etc. pp.) um das zu minimieren, aber die Gefahr ist gegeben, ja. Hier ist aber jeder Einzelne gefragt, seine Accountdaten selbst zu sichern. Wenn ich hier eingeloggt bleiben will, muß ich als User selbst dafür sorgen, daß niemand an den Computer kann, wenn es sich um wichtige Daten handelt.

Wenn ich als User das nicht garantieren kann, dann darf ich mich eben nur für die eine Sitzung einloggen, sodaß nach Beendigung des Browsers oder nach einer gewissen Zeit die Session erlischt und der entsprechende Cookie gelöscht wird.

Wenn es sich bei deinem Projekt um wirklich wichtige Sachen handelt, dann wäre es sinnvoll, die Option, permanent eingeloggt zu bleiben, gar nicht erst anzubieten. Denn dies ist eine Option für höhere Beqemlichkeit und die steht der Sicherheit eigentlich immer entgegen. Der User kann entweder selbst entscheiden, was für ihn wichtiger ist, oder, wenn du ihm nicht vertraust, bietest du ihm diese Option gar nicht erst an.

[HellHorse]

Man speicher normal die User ID und das Passwort (als Hash!) im Cookie und verifiziert das dann wenn man die Seite läd.
Öh nein. Normalerweise hat man eine völlig intranstrente session id (Zufallszahl), welche denn auf dem Server auf ein Session Objekt gemappt wird. In diesem ist dann entweder ein User Objekt oder bloss der username oder was auch immer. Der Punkt ist dass diese Information auf dem Server im session Objekt ist und diesen nie verlässt. Der Client hat bloss einen lookup-key für dieses Objekt.

Der Punkt mit dem Cookie klauen ist insbesondere ein Problem falls ein Angfreiffer JavaScript oder CSS auf der Seite unterbringen kann. Sessions lassen sich zwar an eine IP binden, völlige Sicherheit bietet aber auch das nicht. IE Nutzer sind hier sicherer da man per HttpOnly Option Cookies von JavaScript verstecken kann.

[Gast]

Öh nein. Normalerweise hat man eine völlig intranstrente session id (Zufallszahl), welche denn auf dem Server auf ein Session Objekt gemappt wird. In diesem ist dann entweder ein User Objekt oder bloss der username oder was auch immer. Der Punkt ist dass diese Information auf dem Server im session Objekt ist und diesen nie verlässt. Der Client hat bloss einen lookup-key für dieses Objekt.


Das kommt drauf an. Wenn man nur Daten über eine Sitzung hinweg speichern möchte, dann landet die SessionId einfach im Cookie (SessionCookie), mehr nicht. Das machen aber die Web Frameworks i.d.R. automatisch. Möchte man aber den Nutzer über einen längeren Zeitraum automatisch wiedererkennen, dann muss man die Credentials im Cookie speichern (am besten mit einem Salt und gehasht). Man kann ja wohl schlecht den Session State eines Nutzers für Monate im RAM aufbewahren.
Zumindest ist das in den meisten Fällen unerwünscht. Möchte man das aber doch aus irgendwelchen Gründen haben, dann setzt man die Zeit für den Sessionablauf im WebServer nicht auf unendlich, sondern verwendet einen StateServer oder speichert das in einer SQL Datenbank. Letzteres ist z.B. in ASP.NET vollkommen trivial umzusetzen.