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