Sind sessionvariablen für besucher lesbar???

[LSpreee]

Hallo Forum,

ich frage mich gerade aus Sicherheitsgründen, ob sich Benutzer irgendeines Browsers und irgendeiner Plattform die $_SESSION-Variablen, die gerade belegt sind, ausgeben lassen können.

Wenn ich soll, poste ich auch gerne das Problem. Es ist aber nicht unbedingt nötig für die Frage, denke ich.

Es geht mir um die Sicherheit von Passwörtern. Diese Passwörter möchte ich nämlich nicht einfach in einem hidden-Feld durchschleifen.

Vielen Dank für Hilfe.

PS: Google hat auf die schnelle nichts gegeben, nur Tuts.

[EKKi]

Mahlzeit LSpreee,

ich frage mich gerade aus Sicherheitsgründen, ob sich Benutzer irgendeines Browsers und irgendeiner Plattform die $_SESSION-Variablen, die gerade belegt sind, ausgeben lassen können.

Nur, wenn sie es irgendwie schaffen, entsprechenden PHP-Code auf dem Server auszuführen.

Es geht mir um die Sicherheit von Passwörtern. Diese Passwörter möchte ich nämlich nicht einfach in einem hidden-Feld durchschleifen.

Das solltest Du in der Tat NIEMALS tun. Genausowenig solltest Du allerdings Passwörter in einer Session hinterlegen - wozu? Du prüfst an genau EINER Stelle (bzw. durch genau EINE Funktion, die Du dann an den benötigten Stellen aufrufen kannst), ob eine gegebene Benutzer-Passwort-Kombination korrekt ist und merkst Dir dann in der Session, dass Benutzer "Sowieso" eingeloggt ist. Wozu brauchst Du dann anschließend dessen Passwort in der Session?

MfG,
EKKi

[LSpreee]

Moin,

Nur, wenn sie es irgendwie schaffen, entsprechenden PHP-Code auf dem Server auszuführen.

Ertsmal danke für diese Info. Damit rechne ich vorerst nicht.

Genausowenig solltest Du allerdings Passwörter in einer Session hinterlegen - wozu? Du prüfst an genau EINER Stelle (bzw. durch genau EINE Funktion, die Du dann an den benötigten Stellen aufrufen kannst), ob eine gegebene Benutzer-Passwort-Kombination korrekt ist und merkst Dir dann in der Session, dass Benutzer "Sowieso" eingeloggt ist. Wozu brauchst Du dann anschließend dessen Passwort in der Session?

Das wusste ich nicht, ich habe es in der Tat anders. Ich prüfe bei jedem Seitenaufbau die Kombination. Dachte, dann kann man eine "User sowieso ist eingeloggt"-Variable nicht unterjubeln. Ist vielleicht echt Quatsch.
Also Du meinst, ich soll die Prüfung EINMAL ausführen?

Das Problem, dass ich jetzt gerade habe:
Es gibt einen Seitenlogin, der für viele Dinge fungiert. Außerdem gibt es ein Forum. Wenn man dort einen Beitrag schreiben will, was man auch als Gast kann (!), kann man sich auch entscheiden, es mit seinem Login zu machen. Dieser soll geprüft werden, auf die korrekte Ben-Pass-Kombination, _und_ der Seitenlogin soll _nicht_ anspringen! Weil ich davon ausgehen möchte, dass der Nutzer sich nicht anmelden will, sondern nur ein Beitrag unter seinem Namen schreiben möchte. Wenn im Formular jetzt ein fehlerhaftes Feld ist, wird das Formular erneut aufgebaut, alle Felder werden mittels $_POST bestückt. Wenn die Ben-Pass-Kombi schon verifiziert wurde, soll sie das natürlich bleiben. Daher der Hidden-Field-Gedanke.
Ich werde jetzt wahrscheinlich temporäre $_SESSION-Var. definieren. Wie gesagt, der globale Login soll nicht anspringen, das hatte ich schon realisiert.

Vielen dank, wer sich das ganze Zeug durchgelesen hat.
Und Danke an EKKi

[Cheatah]

Hi,

Sessions funktionieren grob gesagt wie folgt: Der Client erhält einen Identifikator seiner Session. Dieser Wert ist lediglich eindeutig, transportiert darüber hinaus aber keinerlei Information. Auf Serverseite wird der Identifikator mit einem Set an Daten assoziiert; mit diesen Daten kann der Server arbeiten.

Das wusste ich nicht, ich habe es in der Tat anders. Ich prüfe bei jedem Seitenaufbau die Kombination. Dachte, dann kann man eine "User sowieso ist eingeloggt"-Variable nicht unterjubeln. Ist vielleicht echt Quatsch.
Also Du meinst, ich soll die Prüfung EINMAL ausführen?

Ja. Die permanente Prüfung kostet Ressourcen, die insbesondere beim Prüfen gegen eine Datenbank teuer sind. Nur der Server verwaltet die Sessiondaten; gefährlich wird es erst dann, wenn eine Sicherheitslücke erzeugt wird, die es erlaubt, eigenen serverseitigen Code auszuführen (oder wenn entsprechend mächtiger Code bereits vorliegt und vom Nutzer ausgeführt werden kann).

Das Problem, dass ich jetzt gerade habe:

Ich sehe eigentlich kein Problem darin. Wenn Du keine Session erzeugen möchtest, dann lass es halt bleiben - die Überprüfung der Benutzerdaten kannst Du ja durchführen, ohne damit eine Session zu öffnen. Ich bin nur nicht sicher, ob diese Möglichkeit vom Benutzerkonzept her sinnig ist, was aber natürlich auch vom Einzelfall abhängt.

Cheatah

[LSpreee]

Vielen Dank für die Antworten. Ich werde mir die Ratschläge in Bezug auf Sicherheit und Ressourcen zu Herzen nehmen.

Ich bin nur nicht sicher, ob diese Möglichkeit vom Benutzerkonzept her sinnig ist, was aber natürlich auch vom Einzelfall abhängt.

»»

Das stimmt. Habe mich jetzt doch entschieden, die Logins gleichwertig zu behandeln. Ich hoffe das meintest Du.

Vielen Dank auch für die Erklärung mit dem Sessionprinzip. Aber da habe ich nochmal eine Frage. Ich habe zwei Seiten, auf unterschiedlichen Servern, mit, so sieht es aus, unterschiedlichen Einstellungen. Bei A muss ich an jeden (!) Link mittels strip_tags (SID) die Session ID ranhängen, für den Fall, dass der User keine Cookies akzeptiert. Tut er dies, bleibt die Var. strip_tags (SID) leer und der
Browser schickt den Identifikator irgendwie anders. Bei Server B muss ich die Session-Id niemals an einen Link ranhängen, auch nicht, wenn ich Cookies ablehne.
Frage: welche Servereinstellung ist für dieses Verhalten verantwortlich?
Und wie kann ich folgendes verhindern: Ein User logt sich bei mir ein, ich speichere die Loginzeit. Er setzt einen Link in den Lesezeichen. Er vergisst sich auszuloggen. Geht er nächsten Tag über diesen Link rein, ist er angemeldet, obwohl die Session längst abgelaufen sein müsste. Eine neue Loginzeit bekomme ich nicht erfasst. Das ist doof für meine Forumsfunktion: Beiträge seit dem letzten Login. Oder für anderes. Warum wird das Sessiontimeout auf diese Weise für den Nutzer umgangen?

Vielen Dank an dieses SupertolleForum im vorraus.

LSpreeee

[ChrisB]

Hi,

Bei Server B muss ich die Session-Id niemals an einen Link ranhängen, auch nicht, wenn ich Cookies ablehne.
Frage: welche Servereinstellung ist für dieses Verhalten verantwortlich?

session.use_trans_sid in Verbindung mit url_rewriter.tags
Und session.use_only_cookies überschreibt das ganze ggf.

http://www.php.net/manual/en/session.configuration.php

Und wie kann ich folgendes verhindern: Ein User logt sich bei mir ein, ich speichere die Loginzeit. Er setzt einen Link in den Lesezeichen. Er vergisst sich auszuloggen. Geht er nächsten Tag über diesen Link rein, ist er angemeldet, obwohl die Session längst abgelaufen sein müsste. Eine neue Loginzeit bekomme ich nicht erfasst. Das ist doof für meine Forumsfunktion: Beiträge seit dem letzten Login. Oder für anderes. Warum wird das Sessiontimeout auf diese Weise für den Nutzer umgangen?

PHPs Sessions haben kein "Ablaufdatum", sondern ein Mindeshaltbarkeitsdatum.
Die Einstellung session.gc_maxlifetime ist in der Hinsicht falsch benannt, da sie eigentlich eine minlifetime darstellt.
Der jeweils letzt Zugriff auf die Session-Datei wird hier zum Vergleich herangezogen, ob eine Session als "Garbage", Müll, angesehen wird. Wenn ja, darf der Garbage Collector sie wegräumen - der aber wird zufallsgesteuert aufgerufen. Du hast also nur eine Garantie dafür, wie lange eine Session-Datei mindestens verfügbar ist - aber kein Maximum.

Wenn du sowas willst, musst du es selber implementieren.
Wenn du bspw. den jeweils letzten Zugriffszeitpunkt in der Session hinterlegst, dann kannst du ihn mit dem aktuellen vergleichen. Und wenn dir die Differenz zu gross ist, dann den Nutzer auffordern, sich zuerst neu einzuloggen.

MfG ChrisB

[Tom]

Hello,

Wenn du sowas willst, musst du es selber implementieren.
Wenn du bspw. den jeweils letzten Zugriffszeitpunkt in der Session hinterlegst, dann kannst du ihn mit dem aktuellen vergleichen. Und wenn dir die Differenz zu gross ist, dann den Nutzer auffordern, sich zuerst neu einzuloggen.

Und wenn er den letzten Zugriffszeitpunkt nicht in der Session, sondern in einer für alle zugänlichen Datenhaltung (bei stärker frequentierten Seiten kommt da eigentlich nur eine Datenbank in Frage) registriert, dann kann auch solche beliebten Spielchen, wie "wer ist online" spielen, also dioejenigen User feststellen, die innerhalb eines Zeitfensters einen Request durchgeführt haben.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[LSpreee]

Wow,
vielen Dank an ChrisB und Tom (aus dem schönen Oberharz),

das sind sehr hilfreiche Tipps. Werde das gleich einbauen.

Schnes We noch

LSpreee

[Tom]

Hello,

ob Du Dir das "Login" in der Session merkst oder ob Du jedes Mal gegen eine gemeinsame Datenhaltung prüfst, hängt davon ab, ob Du ein "Auth per Session" oder ein "Auth per Request" realisieren willst.

Bei einem "Auth per Request" hast Du zwei Vorteile:

1. es ist einfach feszustellen, welche User innerhalb einer gewissen Zeit Requests
   durchgeführt haben

2. es ist viel leichter möglich einem bestimmten User ganz einfach von einem Request
   zum nächsten die Rechte zu ändern oder ihn rauszuschmeißen, ohne dass dadurch seine
   Sessiondaten gleich verloren gehen müssen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg