[phpdev]

Nabend,

ich überlege mir gerade wie ich eine Session Klasse am besten schreiben kann.
Ich habe nun eine Klasse namens Session und eine Methode namens login, dieser Methode werden Benutzername und Passwort übergeben.

Nun denke ich darüber nach wie ich das mit der "Session" am besten mache. Bis jetzt habe ich immer den Benutzernamen und das Passwort (verschlüsselt) in zwei Cookies gespeichert und auf jeder Seite den Benutzernamen und das Passwort ausgelesen und auf Übereinstimmung mit den Daten aus der MySQL Datenbank überprüft.

Jetzt gibts ja das Problem das manche User keine Cookies zulassen, aber auf verschiedenen Seiten habe ich gelesen das auch eine Session ID entweder im Cookie gespeichert wird (geht automatisch) oder mit POST oder GET übergeben wird.

Auf die Übergabe in der URL per POST oder GET möchte ich eigentlich verzichten, da man ja auch gerne mal
einen Link weitergibt und nicht auf die URL achtet.

Ist es denn Sinnvoll NUR die SessionID mit session_start() zu erstellen und in einem Cookie zu speichern und diese dann in der Datenbank einzutragen und so dann den Benutzer mittels $_COOKIE['PHPSESSID'] zu identifiezieren ?

PS: Ich habe zwar schon mehrere Seiten gefunden und durchstöbert aber richtig beantworten konnte mir diese Frage noch keine.

[mepeisen]

Gegenfrage: Wieso ist das nicht sinnvoll?

Es gibt exakt drei Möglichkeiten, einen Benutzer zuverlässig zu erkennen und eine davon fällt im Internet eh flach.
1. Verschlüsselte Ablage der Benutzer-/Passwort-Daten in einem Cookie. Das ist für paranoide Sicherheitsneurotiker der Worst Case. Aber nun ja. Möglich ist es.
2. Eine normale PHP-Session und dort (in welcher Form auch immer) die Session-Daten hinterlegen. In diesem Fall nutze ich eigentlich immer ein zusätzliches Identifizierungsmerkmal für die Session, zum Beispiel den aktuell verwendeten Browser, IP-Adresse usw. Je nach Anforderung. Es gibt nur zwei Chancen, die Session-ID vom Client zu erfahren, das ist entweder ein Cookie oder als POST-/Get-Variable. Wenn man beides nicht haben will hat man Pech gehabt.
3. Nutzen zusätzlicher Dienste, zum Beispiel eines Microsoft Authentifizierungsdienstes. Sowas fällt in 99,99% im Internet flach und ist eher in einem LAN zu finden bzw. in Unternehmesnetzwerken.

Nun nochmal ausführlich: Worum gehts dir eigentlich? Um Sicherheit? Wenn ja um welche Sicherheit? Das des Passwortes? Die Sicherheit, einen User wiederzuerkennen? Um Cookies? Fragen über Fragen.

Ich gehe mal davon aus, dass du dir die Frage selbst beantworten kannst, sobald du genau weisst, worum es dir geht, denn so viele Möglichkeiten hat man eh nicht.

[MrNiceGuy]

Zum Thema Sicherheit mit Sessions habe ich mir selber mal eine alternative Lösung erarbeitet, die ich persönlich sicherer finde, als die IP oder den Browser zu verwenden:

Beim ersten Zugriff auf die Session speichere ich in der Session einen HASH-Key als Schlüssel eines Arrays (beinhaltet widerum auch ein Array) mit einem UNIX-Timestamp (aktuelle Zeit + konfigurierbarer Timeout) als einen Wert dieses Array-Elements und einem Boolean als anderen Wert (Speichert, ob dieser Key bereits aufgerufen wurde oder nicht). Zusätzlich wird der HASH-Key als Cookie gespeichert, um beim nächsten Seitenaufruf wieder an den Server übertragen zu werden.

Das Array sieht dann etwa wie folgt aus:

PHP-Code:

$_SESSION['arrayAuthorisationCheck']['hierDerHashKey'] = array ('booleanUsed' => FALSE, 'integerTimeout' => (time () + $integerTimeout)); 


Soweit so gut, es gibt also einmal die ID zur Session und den HASH-Key als Cookie. Beim nächsten Seitenaufruf wird geschaut, ob der Timestamp zum HASH-Key in der Session abgelaufen ist. Ist dies der Fall oder ist der HASH-Key garnicht in der Session enthalten, wird die Session geschlossen und als ungültig erkannt. Befindet sich der HASH-Key in der Session und der Timestamp ist noch nicht abgelaufen, wird der Boolean-Wert überprüft. Steht er noch auf "FALSE", wird er auf "TRUE" gesetzt, der Timeout neu gesetzt und ein neu generierter HASH in der Session (wie oben auch schon) angelegt, als Cookie verschickt und für den aktuellen HASH als "neuer HASH" im String gespeichert. Steht der Boolean bereits auf "TRUE", wird kein neuer HASH generiert, sondern die Session "lediglich" als gültig anerkannt. Ein neuer HASH-Key wurde ja bereits übermittelt.
Dies hat folgenden Hintergrund: Jeder Hash soll, bis er verwendet wurde, die Gültigkeitsdauer wie eine Session selbst haben (z.B. 15 Minuten). Befindet man sich auf einer Seite mit mehreren Links, die man gleichzeitig öffnet (z.B. Forum, Gallery, etc.), die alle auf die selbe Seite mit der Session zugreifen, wird auch bei nahezu jedem Aufruf der gleiche HASH-Key übermittelt. Würde jetzt nach erstmaliger Benutzung der HASH-Key gelöscht und somit ungültig werden, wäre nur eine Seitenanfrage gültig und der Rest würde mit Fehler abgebrochen. Um dies zu überbrücken, sollte nach der ersten Verwendung der HASH noch für z.B. 30 Sekunden gültig bleiben, bevor er dann gelöscht wird.

Ich finde, dass durch diese Methode die Möglichkeit eine Session zu erschleichen deutlich sinkt, auch wenn sie nicht zu 100% gebannt ist. Aber wie ich eh immer sage: Es gibt keine 100%ige Sicherheit.

Was mich nach meinem doch recht ausschweifendem Post jedoch interessiert ist, was ihr davon haltet!? Ich habe diese Methode bereits erfolgreich in mein CMS (noch eine Alpha) integriert und ohne Probleme getestet - bisher.

ich hoffe ihr versteht alle die Arbeitsweise dieser Technik!?

[phpdev]

Danke für eure Antworten

Mir gehts eigentlich darum die beste Möglichkeit zu finden den user zu identifizieren, aber auch um die Sicherheit des Users.
Hätte ich gleich sagen sollen, sorry.
Ich habe das so verstanden, das wenn man session_start() verwendet, automatisch versucht wird einen Cookie zu setzen und wenn der User Cookies deaktiviert hat ist man gezwungen das ganze per Hand (URL) weiterzugeben.
Ist das so richtig?

Ich bin noch nicht lange dabei PHP zu programmieren, deswegen auch die Frage, wird die Session ID bei vielen Webanwendungen weitergegeben und anhand derer der user identifiziert ?

Oder welche Methoden sind da so üblich ?

EDIT: MrNiceGuy hab deinen Beitrag jetzt erst gesehen, das lese ich mir doch gleich mal genau durch

[MrNiceGuy]

Also Cookies sind ansich üblich für die Verwendung von Session-IDs und ich muss auch ganz ehrlich sagen, dass ich persönlich nichts anderes verwenden würde. Die Einstellung "session.use_only_cookies = 1" in der php.ini sollet meiner Meinung nach immer gesetzt sein. Es ist zwar "schlecht", User auszuschließen, die keine Cookies aktiviert haben, da es sich bei einem Cookie jedoch um reine Textinformationen handelt, sehe ich hier keien Gefahr für einen User.
Ich weiß zwar, dass es sich nicht gehört, User wegen anderer Einstellungen "auszuschließen" und zu sagen, dass es ihr eigenes Problem sei, aber in diesem Fall muss ich einfach sagen, dass für mich das Verständnis aufhört, weil der Aufwand, den man betreiben muss, irgendwo nicht gerechtfertigt ist. Einfacher wäre dann wohl eher ein dezenter Hinweis mit einem gut formuliertem Text, der die Leute darauf hinweißt, dass die Cookies dieser Seite nichts böses sind und lediglich der Identifizierung für diese eine Session notwendig machen und diese zu aktivieren sind.
Man erwischt in der Regel so oder so keine Leute, die nicht wissen, wie man Cookies aktiviert, da eigentlich alle Browser standardmäßig Cookies an haben (zumindest alle, die ich je benutzt habe) und somit lediglich Sicherheitsfanatiker und Leute mit paranoider Schitzophrenie ihre Cookies deaktivieren. Diese Leute wissen dann aber auch, wie sie das wieder rückgängig machen können.

[dago]

Hallo MrNiceGuy,

würde aber nicht auch das gehen:

PHP-Code:

$_SESSION['arrayAuthorisationCheck']['hierDerHashKey'] = (time () + $integerTimeout); 


und anstatt "booleanUsed" auf TRUE zu setzen, einfach das:

PHP-Code:

$_SESSION['arrayAuthorisationCheck']['hierDerHashKey'] = FALSE;
// oder
unset($_SESSION['arrayAuthorisationCheck']['hierDerHashKey']); 


Aber ich verstehe denn Sinn dahinter nicht. Das man ein Hash im Cookie zur Wiedererkennung abspeichert ist mir klar. Dieser Setzt sich aber dann auch aus Userdaten zusammen. Einen extra zufällig generiertes Hash pro Seitenaufruf erscheint mir unsinnig. Denn was soll das jetzt genau bringen. Verstehe da dich nicht ganz.

Das denke ich würde das gleiche bringen:

PHP-Code:

$_SESSION['integerTimeout'] = (time () + $integerTimeout); 


[MrNiceGuy]

Natürlich würde das gehen, nur wie ich in meinem Text schon geschrieben hatte: Wenn dann mehrere Seitenaufrufe quasi-gleichzeitig erfolgen, führt nur die Erste davon zum Erfolg, der Rest wäre ungültig.

Der Sinn, weshalb bei jedem Seitenaufruf ein neuer Hash-Key generiert wird ist ganz einfach: Es wird schwieriger für Dritte sich in genau diese Session reinzumogeln, da der Hash-Key spätestens nach der Timeout-Zeit nicht mehr gültig ist (das ist der Maximalfall).

Der Hash-Key muss nicht aus Benutzerdaten bestehen, da kann auch ein md5 () über einen microtime () genutzt werden. microtime () liefert bei jeder Anfrage ein anderes Resultat, da PHP-Scripte nacheinander abgearbeitet werden und somit gewährleistet wird, dass der Key auch eindeutig ist. Man kann aber auch die Funktion uniqid () verwenden oder sich irgend etwas anderes tolles einfallen lassen

[dago]

Zitat von MrNiceGuy

Natürlich würde das gehen, nur wie ich in meinem Text schon geschrieben hatte: Wenn dann mehrere Seitenaufrufe quasi-gleichzeitig erfolgen, führt nur die Erste davon zum Erfolg, der Rest wäre ungültig.

Der Sinn, weshalb bei jedem Seitenaufruf ein neuer Hash-Key generiert wird ist ganz einfach: Es wird schwieriger für Dritte sich in genau diese Session reinzumogeln, da der Hash-Key spätestens nach der Timeout-Zeit nicht mehr gültig ist (das ist der Maximalfall).

Also mir reicht da eine Timeout-Zeit der Session. Also die Zeit wie lange ein Benutzer bei Inaktivität noch angemeldet bleibt.


Aber um das noch genau zu verstehen, was du damit vor hast. Wenn ich jetzt 10mal auf ein Link klicke und jedesmal ein neues Fenster öffne. Dann bin ich so 20min nur noch im letzten Fenster unterwegs.
Wenn ich jetzt wieder zum 4. Fenster gehe, müsste dann ja der Hash der ja beim letzten Aufruf des Fensters erzeugt wurde, ungültig werden. Also müsste ich in diesem Fenster abgemeldet sein. Aber im letzten Fenster wo ich zuletzt aktiv war noch angemeldet.

Verstehe ich deine Motivation richtig?

Dies würde aber nicht funktionieren. Denn dazu müsste das ursprüngliche Fenster nicht von Cookies des aufgerufenes Fensters wissen. Aber so weit mir bekannt gelten die Cookies Browserweit. Also verhält sich das arbeiten mit mehreren Fenstern genauso wie mit nur einem.


EDIT: Oder missverstehe ich deine Absicht? Und du versuchst damit nur das entwenden des Cookies zu verhindern. (bzw. des darin enthaltenen Hashes) Aber das erscheint mir auch als unnötig.

[MrNiceGuy]

Stopp. Bevor wir weiter aneinander vorbeireden: Was ich meinte ist folgendes...

Nehmen wir mal an, du befindest dich auf dieser Seite im Forum "PHP-Programmierung". Es gibt dort 3 interessante Themen, die du möglichst gleichzeitig öffnen willst, damit die 2 übrigen Themen, sich schön öffnen, während du das eine schon am Lesen bist. Du klickst also z.B. mit gehaltener SHIFT-Taste auf die 3 Links und es öffnen sich 3 weitere Fenster. Je anch Verbindung, Geschwindigkeit des Servers, etc. lädt die Seite im ersten Fenster noch, während du die nächsten 2 Fenster durch die klicks öffnest.

So weit, so gut. Alle 3 Fenster werden jetzt mit dem selben Hash als Cookie geöffnet, allerdings wird das 2. Fenster erst dann anfangen die Daten zu laden, sobald das Script im ersten Fenster die Session geschlossen hat (PHP blockiert die Sessions, bis sie nicht mehr benötigt werden, das ist aber ein anderes Thema) und das 3. lädt erst, wenn das 2. die Session nicht mehr braucht. Wenn du nun im 1. Fenster schon den Hash aus der Session löschen würdest, könnten die Fenster 2 und 3 nicht mehr erfolgreich ausgeführt werden, weil der Hash, der bei ihnen übergeben wird nicht mehr existiert. Die Anfrage wurde ja schon gestellt, bevor das erste Script abgearbeitet war und den neuen Hash übertragen konnte.

Deswegen habe ich die Übergangszeit von z.B.20 oder 30 Sekunden, um dies zu verhindern. So lange wäre der Hash dann noch aktiv. Der Boolean ist eigentlich nur dazu da, damit nur das 1. Fenster einen neuen Hash generiert und als Cookie zurückschickt. Auf diese Weise gibt es bei allen 3 Fenstern zusammen nur einen neuen Hash (weniger Berechnungszeit, weniger Transfer, weil kein neuer Hash als Cookie an den Browser geschickt werden muss, das Array in der Session bleibt so klein wie nötig, etc.), wohingegen ohne den Boolean bei allen 3 Fenstern ein neuer Hash erzeugt und verschickt würde. Davon würde beim nächsten Seitenaufruf jedoch nur der letzte wieder übertragen werden und die übrigen Hashes sind sinnlos und verbrauchen für die Dauer ihrer Existenz nur Speicherplatz und mehr nicht. Außerdem steigt das Risiko, dass sich jemand in diese Session einschleichen kann, da die Anzahl gültiger Hashes steigt.

Ich hoffe, dass ich einigermaßen klar rüberbringen konnte, was ich meine!? Ich versuche das nochmal alles in einem kleinen PAP darzustellen und zu posten, das könnte aber noch ein bisschen dauern, bis ich da die Zeit zu habe.

EDIT: Hier nun das Struktogramm, wie ich es meinte, vielleicht bringt das ein bisschen Licht ins Dunkel!?

[dago]

Ach, vielen Dank für deine ausführliche und gute Erklärung! Aber so weit komme ich eigentlich garnicht. Ich verstehe nicht wozu du mehre Hashes erstellst.

Ich generiere ein Hash nur beim start einer Sitzung, Besipiel:

PHP-Code:

$hash1 = sha1($username . $browser . $ip); 


und auch nur eines zusätzliches beim Login, Beispiel:

PHP-Code:

$hash2 = sha1( uniqid( rand() ) ); 


Diese beiden lege ich nun im Cookie aber auch in der Session zum abgleich ab. Dazu noch den TIMESTAMP der letzten Aktivität des Benutzers. Fertig!

Es muss kein weiterer Hash erstellt werden oder diese ersetzt werden, bis der Benutzer eine bestimmte Zeit inaktiv gewesen ist.

In wie weit ist deine Lösung sicherer wie diese hier?

[Jann Hendrik]

da du die IP mit einbeziehst solltest folgendes beachten:
29.15. Warum verwendet PHP nicht die IP-Nummer des Browsers als Schutz gegen eine Übernahme der Session?
insbesondere den Teil:

Die sichtbare IP-Nummer eines Benutzers kann während der Session wechseln.

[Waq]

Zitat von phpdev

ich überlege mir gerade wie ich eine Session Klasse am besten schreiben kann.

Das ist IMHO schonmal der erste Fehler. Benutz die PHP-eigenen Sessions, setze bei Bedarf einen eigenen Speichermechanismus drunter (http://de3.php.net/manual/en/functio...ve-handler.php) und geeignete Sicherheitsmechanismen oben drauf.

Einen Login würdest Du so bauen, dass nach erfolgreicher Passwortabfrage in der Session gepeichert wird, dass der User eingeloggt ist, fertig. Unverschlüsselt natürlich, da auf dem Server.

Warum? Weil Sessions eine Solide Implementation sind, um Daten mitzuschleppen, denn z.B. ...

Zitat von phpdev

Ich habe das so verstanden, das wenn man session_start() verwendet, automatisch versucht wird einen Cookie zu setzen und wenn der User Cookies deaktiviert hat ist man gezwungen das ganze per Hand (URL) weiterzugeben.

... ist das genau falsch. PHP-Sessions können, falls Du es so einstellst und Cookies nicht angenommen werden, die Session-Id automatisch an jeden Link anhängen.

[MrNiceGuy]

@dago: Dadurch, dass ein einzelner Hash nur für eine begrenzte Zeit (bei mir z.B. 15 Minuten) gültig ist, verkleinere ich das Fenster für jemanden, der sich unerlaubt Zutritt zu dieser Session verschaffen möchte auf maximal 15 Minuten. Wenn du nur ein Mal diese Hashes am Anfang der Session erstellst, ist das Fenster zum Einschleichen in die Session so groß, wie die Session selbst aktiv ist, also im Groben: Vom Login bis zum Logout.

Ein Beispiel: Was ist wahrscheinlicher? Dass eine Fußballmannschaft in 15 Minuten ein Tor schießt oder in 90?

Natürlich MUSS man das ja nicht so machen. Es ist nur eine Methode, die ich mir selber für mich überlegt habe, die relativ einfach zu realisieren ist und meiner Meinung nach eine vergleichsweise hohe Sicherheit bietet.

@Waq: Das ist soweit richtig. Jetzt aber mal eine Frage an die Allgemeinheit von mir: Würdet ihr eine andere Session-Authentifikation als Cookies zulassen?

[Waq]

Zitat von MrNiceGuy

Also Cookies sind ansich üblich für die Verwendung von Session-IDs und ich muss auch ganz ehrlich sagen, dass ich persönlich nichts anderes verwenden würde.

Da seit der Erfindung der XSRF-Attacke Session-IDs in Keksen kein bisschen sicherer sind als in der URL, ist das so mittlerweile Unsinn.
http://de.wikipedia.org/wiki/XSRF

Zitat von MrNiceGuy

[..] dass für mich das Verständnis aufhört, weil der Aufwand, den man betreiben muss, irgendwo nicht gerechtfertigt ist.[..]

Welcher Aufwand? session_use_only_cookies wieder anzuschalten?

Zitat von MrNiceGuy

Einfacher wäre dann wohl eher ein dezenter Hinweis mit einem gut formuliertem Text, der die Leute darauf hinweißt, dass die Cookies dieser Seite nichts böses sind [..]

Da doch lieber ein dezenter Hinweis, dass der User, da er ja keine Cookies nimmt, bitte auf seine Session-ID aufpassen und die URLs nicht weitergeben möge. Rausschmeissen muss man ihn dafür nicht.

Für die Weitergabe/Mitbenutzung von Session-IDs gibt es folgende einfachen Möglichkeiten:
- Weitergabe der URL durch den User (durch o. g. Warnung eindämmbar?)
- URL wird bei ausgehenden Links als Referrer an fremde Seiten weitergegeben (durch Redirect vor ausgehenden Links verhinderbar, potentiell nichttriviale Aufgabe)
- XSRF-Attacke auf den Keks (verhinderbar durch zus. shared secret per URL/Hidden-Feld)

Da es aber keinen "einfachen" Angriff sowohl auf die URL als auch auf den Keks gibt, sollte man IMHO, um halbwegs sicher zu sein, beides machen.
Strukturell am Einfachsten ist es hierbei, die Session-ID erstmal grundsätzlich in die URL zu tun (per session_use_cookies=0, um trans-sid nutzen zu können), und eine zusätzliche ID per Keks durchzuschleifen, die natürlich in der Session gespeichert wird.
Wenn man einen Cookie-Check einbaut, kann man den Keks auch optional halten.

PS: Ich hatte eine etwas längere Diskussion zu dem Thema hier: http://phpforum.de/forum/showthread....highlight=xsrf
Ich will das nicht alles nochmal wiederholen *g*

[dago]

Zitat von Jann Hendrik

da du die IP mit einbeziehst solltest folgendes beachten:
29.15. Warum verwendet PHP nicht die IP-Nummer des Browsers als Schutz gegen eine Übernahme der Session?
insbesondere den Teil:

Jup, ist klar. Wahr jetzt nur als Beispiel.


@MrNiceGuy
Gut bei meiner Version währen es 15 Minuten + Aktivitätszeit des Benutzers. Ich hab nur aufgrund deiner Erklärung angenommen gehabt, dass du damit mehr bezweckst.

Danke für deine Erläuterungen!

[MrNiceGuy]

Hmm... OK, klingt auch irgendwie einleuchtend @Waq. Ich bezweifle allerdings, dass ein Otto-Normal-Verbraucher versteht, weshalb er die URL nicht weitergeben sollte und diese Regel entsprechend umsetzt!?. Im Grunde muss man eigentlich sagen, dass es keine praktikable Lösung für das Problem gibt und man - egal, was man nun anwendet - den Bedienkomfort in gewissen Dingen einschränken muss.

Also ich für meinen Teil schließe jedoch lieber Benutzer aus, die ihre Cookies nicht aktiviert haben, als dass ich darauf hoffen muss, dass die DAUs ihre URLs nicht weitergeben...