Sicherheit von $_SESSION Variablen

[Stonebreaker62]

Hallo,

ich generiere per php SQL SELECT Statements, die ich in einer $_SESSION Variablen speichere. Je nachdem, welche Seite der Benutzer anfordert, setze ich dann ich nächsten Dialogschritt offset und limit neu und hänge diese Werte an die SELECT Statements dran.

Gehe ich damit ein Sicherheitsrisiko ein, weil $_SESSION Variablen angeblich nicht sicher sind?

[tontechniker]

Abgesehen davon, dass sich das nach einem ziemlich hässlichen Design anhört, nein. Die $_SESSION Variablen liegen auf dem Server. Es kann nur die Möglichkeit bestehen Sessions von anderen Benutzern über präperiete oder gepostete Links zu übernehmen.

[PHP-Desaster]

Re: Sicherheit von $_SESSION Variablen

Gehe ich damit ein Sicherheitsrisiko ein, weil $_SESSION Variablen angeblich nicht sicher sind?

Steht wo?

[Stonebreaker62]

Ich weiss nicht mehr, wo ich das gelesen habe - wahrscheinlich hier igrndwo im Forum.

An Tontechniker: was spricht gegen dieses Design? Irgendwo muß ich doch zwischenspeichern, was der Benutzer vorher verlangt hat, wenn er auf die nächste Seite weiterblättern will.

[IchBinIch]

immer diese Unwahrheiten im Netz. Und Leute die alles glauben, anstatt es in Frage zu stellen.

Zum Thema Design: Du speicherst nur die Werte die Angefragt wurden in die Session. Der Rest vom Query bleibt im Script.

[Stonebreaker62]

Da ich die anzeige-Methode (z. B. für Kontakte) für unterschiedlichste Abfragen nutzen wollte, habe ich sie in ein Objekt gepackt. Diese Methode nimmt sich dann aus den Session-Variablen $_SESSION['letze_abfrage'] und $_SESSION['sortierung'] die Werte aus der letzten Anzeige und setze den neuen Offset dahinter. Wenn der Benutzer eine andere Sortierung will, ändere ich z.B. nur den Wert in $_SESSION['sortierung'].

Dachte eigentlich, dass das im Sinne von Code-Mehrfachverwendung so optimal ist, lasse mich aber gerne eines Besseren belehren.

[IchBinIch]

Ich würde mal behaupten, dass das genau das Gegenteil von Code-Mehrfachverwendung ist. Schließlich hast du für jeden User einen eigenen Code. Anstatt ihn Zentral im Script zu hinterlegen und nur noch mit Werten zu füllen.

[combie]

Also.. session Sicherheit:
1. Vor dem ServerAdmin ist nichts sicher...
2. Sessions kann man Hijacken, das ist aber ein ganz anderes Problem

Und SQL in Session:
Nunja, ob das nötig ist...
Der Status einer Anwendung/Session sollte darin gehalten werden!
Auch ein User oder Warenkorb Objekt wäre da gut aufgehoben.

[3DMax]

Original geschrieben von combie
Also.. session Sicherheit:
1. Vor dem ServerAdmin ist nichts sicher...

es muss nicht mal der admin sein.
bei mehrbenutzer-hosting und "schlecht" konfiguriertem (gemeinsamen) session.save_path kann _jeder_ benutzer die session manipulieren.

[combie]

Für solch fürchterliche konfigurations Schlappen darf man PHP nicht verantwortlich machen...
Und sollte in der Praxis nicht auftreten.
(Sonst bitte den Provider vierteilen!!)