nicht angemeldet
$_SESSION fälschen
Hallo,
ich speichere Bunutzerdaten (u.a. Passwort und "Sicherheitsstufe") in einer Datenbank. Wenn ich die Sicherheitsstufe aus der Datenbank auslesen und in $_SESSION['foo'] speichere, besteht dann die Möglichkeit, dass der Benutzer $_SESSION['foo'] verändert?
Also in der Art wie sich ein POST oder GET Request beliebig manipulieren lässt?
Ich könnte natürlich auch jedesmal in der Datenbank nachfragen welche "Sicherheitsstufe" ein Benutzer hat, würde mir das aber sehr gerne sparen wenn es auch ohne geht.
Gruß,
Severin
--
They that can give up essential liberty to obtain a little temporary safty deserve neither liberty nor safty.
-- Benjamin Franklin
They that can give up essential liberty to obtain a little temporary safty deserve neither liberty nor safty.
-- Benjamin Franklin
-
Hi
ich speichere Bunutzerdaten (u.a. Passwort und "Sicherheitsstufe") in einer Datenbank. Wenn ich die Sicherheitsstufe aus der Datenbank auslesen und in $_SESSION['foo'] speichere, besteht dann die Möglichkeit, dass der Benutzer $_SESSION['foo'] verändert?
Nein, da die Inhalte der Sessionvariablen nicht beim Client sondern auf dem Server gespeichert werden.
Gruß
Carl-
Hallo,
Danke für die flotte Antwort :-)
Gruß,
Severin--
They that can give up essential liberty to obtain a little temporary safty deserve neither liberty nor safty.
-- Benjamin Franklin
-
-
Hi!
ich speichere Bunutzerdaten (u.a. Passwort und "Sicherheitsstufe") in einer Datenbank. Wenn ich die Sicherheitsstufe aus der Datenbank auslesen und in $_SESSION['foo'] speichere, besteht dann die Möglichkeit, dass der Benutzer $_SESSION['foo'] verändert?
Also in der Art wie sich ein POST oder GET Request beliebig manipulieren lässt?
Ich könnte natürlich auch jedesmal in der Datenbank nachfragen welche "Sicherheitsstufe" ein Benutzer hat, würde mir das aber sehr gerne sparen wenn es auch ohne geht.Wie Carl dir bereits gesagt hat, werden die Session-Daten in serialisierter Form auf dem Server gespeichert. Wo diese genau gespeichert werden, hängt vom Wert der Konfigurationsoption »session.save_path« ab und dies ist genau der Punkt, wo sich Probleme ergeben könnten: Viele Massenhosting-Provider stellen für alle ihre Kunden »session.save_path« einfach auf /tmp, d.h. andere Kunden könnten unter Umständen (wenn der Server-Admin überhaupt nichts von seinem Fach versteht) auf bestehende Sessions zugreifen.
Aus diesem Grund sollte man »session.save_path« immer auf ein Verzeichnis im eigenen DocumentRoot umbiegen. Das erhöht einerseits die Sicherheit der eigenen Skripte und man beugt Problemen mit den Einstellungen der anderen Kunden vor (z.B. »session.gc_maxlifetime«).Grüße,
Fabian St.-
echo $begrüßung;
Aus diesem Grund sollte man »session.save_path« immer auf ein Verzeichnis im eigenen DocumentRoot umbiegen.
Ja, das globale Temp-Verzeichnis ist ungünstig. Aber im DocumentRoot und dessen Unterverzeichnissen sind die Session-Daten genauso schlecht aufgehoben wie beispielsweise Zugangsdaten zu Datenbanken. Am besten ist also ein privater Platz den der Webserver nicht über eine URL erreichbar macht.
Severin: Übrigens ergeben sich durch Fehler in der verwendeten Technik oder fehlerhafte Scripte, vor allem im Zusammenhang mit aktiviertem register_globals, also in Situationen, in denen sich Variableninhalte ungewollt überschreiben lassen, weitere Angriffsmöglichkeiten.
echo "$verabschiedung $name";
-
Hallo,
Ich habe das Glück, dass mein Programm auf einem dezidierten (Schul-)Server laufen wird und ich davon ausgehen kann, dass der Server "sicher" ist (für Schulverhältnisse...) . Meine größte "Gefahr" sind neugierige Schüler, die meine Skripte mit handgeschribenen POST und GET Requests traktieren.
Ich achte sehr auf eine Trennung der Variablenräume und verwende strikt $_POST,$_GET,$_SESSION....
Ich war mir bei Session einfach nicht sicher wie das ganze wirklich funktioniert und wollte einfach sicher gehen, dass ich nicht in gutem Glauben ein Loch offenlasse.Vielen Dank für eure ausführlichen Antworten!
Gruß,
Severin--
They that can give up essential liberty to obtain a little temporary safty deserve neither liberty nor safty.
-- Benjamin Franklin -
Hi!
Aus diesem Grund sollte man »session.save_path« immer auf ein Verzeichnis im eigenen DocumentRoot umbiegen.
Ja, das globale Temp-Verzeichnis ist ungünstig. Aber im DocumentRoot und dessen Unterverzeichnissen sind die Session-Daten genauso schlecht aufgehoben wie beispielsweise Zugangsdaten zu Datenbanken. Am besten ist also ein privater Platz den der Webserver nicht über eine URL erreichbar macht.
Mit DocumentRoot meinte ich jetzt nicht ausdrücklich das Rootverzeichnis für den Apache, sondern eher das persönliche Rootverzeichnis beim Provider, welches normalerweise ja nicht gleich dem Apache-DocumentRoot ist.
Dennoch wäre es IMHO auch nicht so schlimm, wenn die »session.save_path« im DocumentRoot des Apache liegt, immerhin lässt sich der Zugriff auf ein solches Verzeichnis auf HTTP-Ebene ja einfach unterbinden.Grüße,
Fabian St.
-
-
Hallo!
Wie Carl dir bereits gesagt hat, werden die Session-Daten in serialisierter Form auf dem Server gespeichert. Wo diese genau gespeichert werden, hängt vom Wert der Konfigurationsoption »session.save_path« ab und dies ist genau der Punkt, wo sich Probleme ergeben könnten: Viele Massenhosting-Provider stellen für alle ihre Kunden »session.save_path« einfach auf /tmp, d.h. andere Kunden könnten unter Umständen (wenn der Server-Admin überhaupt nichts von seinem Fach versteht) auf bestehende Sessions zugreifen.
Session-Dateien werden normalerweise mit 600er Rechten gespeichert. Wenn man also SuExec oder SuPHP verwendet, muss man sich hier keine großen Sorgen machen. Bei mod_php muss man sich auf open_basedir verlassen, welches sich zum einen über PHP-Extensions und über nicht-PHP Scripte umgehen lässt. Diese Woche noch wurden zusätzliche open_basedir Prüfungen in die curl Extension eingebaut - die sind bisher in keinem veröffentlichten PHP-Release enthalten. Das ist jetzt vermutlich keine besonders einfach auszunutzende Lücke gewesen, aber davon gab es in älteren PHP Versionen einige...
Wenn man mod_php einsetzt, laufen die PHP-Scripte verschiedener User unter derselben User-ID (instabile Apache-MPMs mal außen vor gelassen). Daher muss man jede Lücke finden, mit der ein User auf Daten/Scripte eines anderen Users zugreifen kann, und beheben. Selbst wenn open_basedir 100% funktionieren würde - was machst Du dagegen, wenn ich aus PHP heraus ein eigenes Binary ausführe (welches open_basedir umgeht)? Wenn Du exec()... nicht verbieten willst, musst Du den safe_mode verwenden und damit ein entsprechendes Verzeichnis pflegen, aus dem der/die User Dateien ausführen können. Aber auch der safe_mode hat dieselben Probleme wie open_basedir - wer garantiert Dir, dass man nicht eine PHP-Extension dazu bringen kann, eine Datei auszuführen? Solche Fälle hat es in der Vergangenheit mehrfach gegeben.
Abgesehen davon muss man auch wieder genau aufpassen, welche Binaries man denn erlaubt, perl wäre natürlich offensichtlich, aber bist Du Dir so sicher, dass man den mysql client nicht dazu bringen kann, den Inhalt einer Session-Datei in die Datenbank zu schreiben? Ausreichende Zugriffsrechte hätte er jedenfalls, und von open_basedir oder safe_mode hat der noch nie was gehört...Das alles kann man ganz einfach vermeiden, indem man CGI mit SuPHP verwendet - was AFAIK fast alle Hoster der Webhostlist Top 10 auch machen (aus guten Gründen, die könnten sich mit Hilfe von mod_php sicher ein paar Server sparen...).
Zum eigentlichen "$_SESSION fälschen" Problem in diesem Thread: Wie Fabian schon richtig sagte hängt es sehr stark von der Konfiguration des Servers ab.
Z.B. mit mod_php und open_basedir und ohne safe_mode ist es im Prinzip ein Kinderspiel, allerdings braucht man Zugriff auf den Server, das ist aber Dank der unzähligen veralteten phpBB, postnuke... Installationen (auch bei anderen Kunden auf diesem Server!) möglicherweise gar nicht so schwierig.
Bei CGI/SuPHP kann man das Risiko durch die zig 100 oder sogar 1000de fremden Kunden auf diesem Server schonmal ausschalten, und auf den eigenen Account beschränken. Aber wenn man selber sowas wie ein altes phpBB irgendwo mal installiert hat (oder vergleichbare Lücken in eigenen Scripten...) ist es natürlich möglich Session-Dateien zu manipulieren.
Man muss sich halt seinen Provider gut aussuchen, und aufpassen was man für Scripte installiert!
Grüße
Andreas--
SELFHTML Linkverzeichnis: http://aktuell.de.selfhtml.org/links/-
Hi Andreas,
Das alles kann man ganz einfach vermeiden, indem man CGI mit SuPHP verwendet [...]
Wobei ich es hier vorziehen würde, für PHP auch suExec zu verwenden - dann braucht man nämlich nur ein Modul zu pflegen für sämtliche CGI-Anwendungen und muss sich nicht um suPHP für PHP und suExec für Perl & Co kümmern.
MfG, Dennis.
--
Mein SelfCode: ie:{ fl:( br:> va:) ls:[ fo:) rl:( n4:# ss:) de:] js:| ch:{ sh:| mo:} zu:|
Die FlatBox 0.3 mit Dokumentation ist da!
Wenn Sie einen Schweizer Bankier aus dem Fenster springen sehen, springen Sie hinterher. Es gibt bestimmt etwas zu verdienen. (Voltaire)
-
-