[PHP] Session + Sicherheit

[freddymc]

Hallo!

Ich bin grad mal wieder am herumbasteln mit php und sessions.
Dabei ist mir aufgefallen, dass sich die Session-Daten manipulieren lassen.
Nun wäre es sicherheitstechnisch ungeschickt, wenn der User in der Session lediglich die Variable $_SESSION['right'] ändern muss, um zum Administrator zu anvancieren.

Wie prüft man Sessions auf richtige Daten?
Soll ich am Anfang jeder php Seite immer prüfen ob "username in session" == "username in Datenbank" (wobei das schon sehr unsicher wäre), oder wie wird das normalerweise geregelt?

Danke schonmal!
MfG,
Fred

 

[thorus]

Öhm, wieso kann der User an $_SESSION was verändern? Du lässt dem doch keinen PHP-Code ausführen?

Die Daten in diesem Array werden, je nach PHP-Konfiguration, im RAM oder auf der Platte des Servers zwischengespeichert. Standardmäßig erhält der User nur einen Cookie mit der SessionID, mit der PHP die richtigen Daten lädt. Ich sehe da also keine Probleme, bis auf die Tatsache, dass man mit der SessionID sich potenziell als anderer User identifizieren kann, dies Einbruchsmöglichkeit kann man aber durch weitere Menchanismen (Speichern der IP-Adresse, weiterer Daten im Cookie) leicht wieder aushebeln, wenn man besonders paranoid ist.

 

[freddymc]

Die Info, dass die eigentlichen Daten auf dem Server liegen und nur die SID im Cookie liegt, kann ich gut gebrauchen, dieser Punkt war mir immer unklar...

Das speichern der IP fällt aber wegen Proxys etc. weg.
Da gäbs doch das Problem mit den AOL Nutzern - irgendwie erinnere ich mich dunkel an irgendwas...

Danke,
MfG,
Fred

 

[sono]

Da gäbs doch das Problem mit den AOL Nutzern - irgendwie erinnere ich mich dunkel an irgendwas...

Trifft die Sache auf den Punkt.

AOL User haben dank den Proxys über die sie kommen keine "feste" Ipadressen, anhand derer man sie auf einer Seite whärend der Sessiondauer "sicher" identifizieren könnte.

Kann man auch wunderbar in den Logfiles beobachten.

Weiterere Cookies lösen das Problem leider auch nicht da man die mitkopieren könnte, das ist also mehr ein Plazebo als Sicherheit.

Man erreicht eine Relative Sicherheit wenn man die Session nach X Minuten inaktivität automatisch schliesen lässt. So ist das Zeitfenster in dem man mit dem geklauten Cookie was machen kann etwas eingeschränkt.

Was man noch machen kann ist den die Browserindentifikation in der Session zu speichern. Wenn plötzlich einer mit dem Cookie aber in einem anderen Browser kommt , dann ist das schon recht verdächtig.

Bekommst du über $_SERVER['HTTP_USER_AGENT'].

Aber halt auch noch ned 100%tig sicher , kann man ja faken oder auch den richtigen Browser haben , aber bis da mal einer draufkommt wenn du es ihm nicht gleich in der Fehlermeldung auf die Nase bindest kann dauern.

Aber wenn einer seine Cookies nicht gerade durch die Gegend verschickt sind Sessions über Cookies relativ sicher.

Über dir Url währe riskanter, da schickt einer nem Kumpel nen Link und schon ist der Kumpel angemeldet.


Gruß Sono

 

[freddymc]

Man erreicht eine Relative Sicherheit wenn man die Session nach X Minuten inaktivität automatisch schliesen lässt. So ist das Zeitfenster in dem man mit dem geklauten Cookie was machen kann etwas eingeschränkt.

Jop, an Logtimeout hab ich schon gedacht.

Über dir Url währe riskanter, da schickt einer nem Kumpel nen Link und schon ist der Kumpel angemeldet.

Du wirst lachen, wie oft ich per google schon an Foren-Eingabemasken (für die Postings) gelangt bin, mit der entsprechende URL oben drin.

Ist es verantwortlich (wird es also praktiziert), dass man z.B. Rechte in der Session speichert? Prüft man das jedesmal per DB nach - dann wäre es ja sinnlos...

MfG,
Fred

P.S.: Was ich schon immer mal wissen wollte: was schafft ein MySQL Server eigentlich an Anfragen? Wie soll ich mir das bei größeren Projekten vorstellen, da sind das doch pro Seite zig gesendete Querys * die Anzahl der Benutzer die beispielsweise an einem CMS herumschrauben...

 

[sono]

P.S.: Was ich schon immer mal wissen wollte: was schafft ein MySQL Server eigentlich an Anfragen? Wie soll ich mir das bei größeren Projekten vorstellen, da sind das doch pro Seite zig gesendete Querys * die Anzahl der Benutzer die beispielsweise an einem CMS herumschrauben...

Das kommt halt ganz drauf an auf was für ner Hardware mit was für einer Einstellung der Server läuft.

Bei bestimmten "dynamischen" Seiten die wie z.B in einem Forum oder CMS kann man auch hingehen und die Teile die nicht wirklich dynamisch sind als html String in eine Tabelle zu speichern und nur noch dann neu zu generieren wenn sie geändert wurden. So kann man teils Perfomancegewinne erreichen.

Im Moment habe ich aber ein ähnliches Problem wie du nur für Postgres.

Mir fehlen leider noch etwas die Erfahrungswerte um sagen zu können wie man einen Server dimmensionieren muss um eine bestimmte Anzahl von User bedienen zu können.