Lebensdauer von Sessions verlängern

[Joshh]

Hallo zusammen,

auf meiner Webseite können sich in einem kleinen Bereich Nutzer einloggen. Das habe ich über Sessions geregelt. Momentan werden die Nutzer nach ca. einer halben Stunde (ich vermute, genau 1440 Sekunden ;-)) automatisch ausgeloggt und müssen sich wieder anmelden.

Diese Zeit möchte ich gerne verlängern. Meine bisherigen Recherchen haben mich darauf gebracht, dass das mit
  session.gc_maxlifetime
zusammenhängt. phpinfo() zeigt mir, dass hierfür der Wert 1440 (als Local und Master Value) eingetragen ist.

Wenn ich in einer .htaccess-Datei mit
  php_value session.gc_maxlifetime 7200
den Wert auf zwei Stunden erhöhe, hat sich der Local Value geändert, aber in der Praxis muss ich mich dennoch nach 1440 Sekunden wieder neu anmelden.

Was mache ich falsch?

Gruß
Josh

[Tom]

Hello,

Was mache ich falsch?

Du untersacheidest nicht zwischen den physischen Grundlagen für eine Session und deren logischer Umsetzung, die zudem auch noch mehrschichtig sein kann.

Das in PHP implementierte Session-System stellt eine rudimentäre Möglichkeit dar, überhaupt Sessions zu implementieren. Es stellt einen Mecahanismus zur Verfügung, der eine Wiedererkennung des Users ermöglicht. Dieser Mechanismus wird sicherheitshalber nach der session_max_lifetime
<z.tz. leider nicht möglich>
beendet, damit keine Sciherheitslücken entstehen und der Server nicht mit unnützen Dateien vollgemüllt wird.

Wird eine Ressource aufgerufen (Request), so wird bei Verwendung des Sessionmechanismus auch die Gültigkeitsdauer nachgetriggert. Sie beginnt also wieder von vorne.

Grundsätzlich sit der Sessionmechanismus unsicher, da die Berechtigungsdaten (i.d.R. Cookie) über denselben Kanal übertragen werden, wie der Datenrequest und außerdem nur ein einzelner Cookie benutzt wird, und kein mehrteiliger Key. Aus einem einzelnen Cookie kann man keine Angriffe auf einen speziellen Account ableiten. Man kann nur feststellen, dass die Anfrage nicht gültig ist.

Erster Schritt wäre also die Teilung des Cookies in zwei teile. Ein teil gibt Auskunft über den Account, der andere darüber, ob Zugriff erlaubt ist. Dann lässt sich ein wiederholter unerlaubter Zugriff auf eine Account erkennen und man kann Sicherungsmaßnhamen ergreifen.

Zweiter Schritt ist die Erneurerung dieser Teilschlüssel möglichst mit jedem Request. Dafür ist eine zusätzliche Übersetzungsschicht notwendig.

Noch besser wäre dann aber die Verwendung eines verschlüsselten Protokolls.

Nun aber zurück zum Sessionmechanismus bezüglich "Anmelden, Online-Status, Abmelden".

Es ist absolut nicht notwenig, einen Benuter, der längere Zeit nicht zugegriffen hat auf seine Daten "abzumelden". Es würde reichen, anderen Usern erst einmal anzuzeigen, dass dieser User 1, 2, 5, 10 Minuten nicht mehr aktiv war.

Dazu müsste man aber den physikalischen Sessionmechanismus vom logischen trennen.

Wenn die Basis mittels PHP session_start() und der verwandten Freunde hergestellt wurde, kannst Du z.B. mittels Eintrag der Zugriffsdaten in eine Datenbank ermitteln, ob der User "angemeldet", "wie aktiv", oder "abgemeldet" ist.

Dazu gibt es hier im Archiv auch schon diverse Threads, die ich bei Interesse gerne heraussuche.

Wichtig ist nur, dass die Basisschicht die Session nicht eher abbrechen darf, als es die logische Schicht tut.

Die Basisschicht ist "Authorisation per Login"
Die Logische Schicht kann hingengen auch "Authorisation per Request"
oder sogar "Authorisation per Function" (on the fly) sicherstellen.

Gerade bei Ausdehnung von Anmeldungs-Gültigkeitsdauern sollte man überlegen, ob man das überhaupt verantworten kann.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joshh]

Hallo,

hui, viele Infos. Danke dafür.

Dazu gibt es hier im Archiv auch schon diverse Threads, die ich bei Interesse gerne heraussuche.

Immer gerne.

Bei meiner Anwendung handelt es sich um ein kleines Tippspiel für einen geschlossenen Anwenderkreis also keine Hochsicherheitsanwendung (nur zur Info - soll keine Ausrede für eine Murkslösung sein).

Erster Schritt wäre also die Teilung des Cookies in zwei teile. Ein teil gibt Auskunft über den Account, der andere darüber, ob Zugriff erlaubt ist. Dann lässt sich ein wiederholter unerlaubter Zugriff auf eine Account erkennen und man kann Sicherungsmaßnhamen ergreifen.

Meinst du beim zweiten Coockie den mit der Session-ID?

Zweiter Schritt ist die Erneurerung dieser Teilschlüssel möglichst mit jedem Request. Dafür ist eine zusätzliche Übersetzungsschicht notwendig.

Wie wird sowas realisiert?

Es ist absolut nicht notwenig, einen Benuter, der längere Zeit nicht zugegriffen hat auf seine Daten "abzumelden". Es würde reichen, anderen Usern erst einmal anzuzeigen, dass dieser User 1, 2, 5, 10 Minuten nicht mehr aktiv war.

Ich möchte einen User auch gar nicht abmelden, zumindest nicht nach so kurzer Zeit. Das soll nur passieren, wenn er selbst einen Abmelden-Link betätigt (löst session_destroy() aus). Anderen Usern soll auch nichts angezeigt werden.
Ziel ist, dass der Benutzer wenn er sich einmal angemeldet hat, die Seite besuchen kann, ohne sich allzu oft wieder neu anmelden zu müssen (jedenfalls nicht schon nach halbstündiger Inaktivität).

Die Basisschicht ist "Authorisation per Login"
Die Logische Schicht kann hingengen auch "Authorisation per Request"
oder sogar "Authorisation per Function" (on the fly) sicherstellen.

Diese Unterschiede habe ich noch nicht so richtig begriffen. Bedeutet "per Login" das Senden des Session-Coockies?

Danke & Gruß
Josh

[dedlfix]

Tach!

Wenn ich in einer .htaccess-Datei mit
  php_value session.gc_maxlifetime 7200
den Wert auf zwei Stunden erhöhe, hat sich der Local Value geändert, aber in der Praxis muss ich mich dennoch nach 1440 Sekunden wieder neu anmelden.

Bist du mit deiner Anwendung alleiniger Nutzer des session.save_path? Wenn nicht, kann es gut sein, dass andere Anwendungen, die die Default-Einstellungen verwenden, deine Sessiondateien aufräumen. Der Aufräummechanismus hat keine Chance bei einem gemeinsamen Verzeichnis nach Anwendungen getrennt zu agieren.

dedlfix.

[Tom]

Hello Dedlfix,

Wenn ich in einer .htaccess-Datei mit
  php_value session.gc_maxlifetime 7200
den Wert auf zwei Stunden erhöhe, hat sich der Local Value geändert, aber in der Praxis muss ich mich dennoch nach 1440 Sekunden wieder neu anmelden.

Bist du mit deiner Anwendung alleiniger Nutzer des session.save_path? Wenn nicht, kann es gut sein, dass andere Anwendungen, die die Default-Einstellungen verwenden, deine Sessiondateien aufräumen. Der Aufräummechanismus hat keine Chance bei einem gemeinsamen Verzeichnis nach Anwendungen getrennt zu agieren.

Das wäre ja wirklich eklig, wenn es noch solche Installationen gäbe.

Die müssten dann aber auch ihre Einstellung für session.gc_maxlifetime,  session.gc_divisor, usw. selber noch verändern können.

http://de3.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime
http://de3.php.net/manual/en/session.configuration.php#ini.session.gc-divisor
http://de3.php.net/manual/en/session.configuration.php#ini.session.gc-probability

Sonst ist es nur sinnvoll, dass er in jedem Script vor dem session_start() auch noch die empfohlenen Änderungen vornimmt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Das wäre ja wirklich eklig, wenn es noch solche Installationen gäbe.

Ich glaub schon, dass es solche noch zur Genüge gibt. Plesk-Installationen verwenden beispielsweise ohne weitere Anpassungen ein gemeinsames Verzeichnis, was man aber projektindividuell ändern kann.

Die müssten dann aber auch ihre Einstellung für session.gc_maxlifetime,  session.gc_divisor, usw. selber noch verändern können.
Sonst ist es nur sinnvoll, dass er in jedem Script vor dem session_start() auch noch die empfohlenen Änderungen vornimmt.

Oder in seiner .htaccess

dedlfix.

[Tom]

Hello,

Das wäre ja wirklich eklig, wenn es noch solche Installationen gäbe.

Ich glaub schon, dass es solche noch zur Genüge gibt. Plesk-Installationen verwenden beispielsweise ohne weitere Anpassungen ein gemeinsames Verzeichnis, was man aber projektindividuell ändern kann.

Die müssten dann aber auch ihre Einstellung für session.gc_maxlifetime,  session.gc_divisor, usw. selber noch verändern können.
Sonst ist es nur sinnvoll, dass er in jedem Script vor dem session_start() auch noch die empfohlenen Änderungen vornimmt.

Oder in seiner .htaccess

Ok, das will ich jetzt mal gar nicht anzweifeln. Hab es selber nur schon lange nicht mehr erlebt.
Aber für mich wäre das ein Grund, den Provider sofort zu wechseln und nicht selber anzufangen mit Basteln.

Dei Grundinstallation muss einfach sicher sein. Sonst kann ich mich auch nicht darauf verlassen, dass ANDERE nicht nachher doch Zugriff auf meine Session-Dateien haben und die ausführen oder sogar die Sessions entführen können.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joshh]

Hallo,

Bist du mit deiner Anwendung alleiniger Nutzer des session.save_path? Wenn nicht, kann es gut sein, dass andere Anwendungen, die die Default-Einstellungen verwenden, deine Sessiondateien aufräumen. Der Aufräummechanismus hat keine Chance bei einem gemeinsamen Verzeichnis nach Anwendungen getrennt zu agieren.

Dieser Fall würde mich wundern. Der Pfad zeigt zwar zu einem Verzeichnis, auf das ich keinen Zugriff habe, aber mein Provider (die Seite läuft auf einem gemieteten Webspace, nicht auf einem selbst gehosteten Server) wird ja kaum so blöd sein und andere Anwendern/Anwendungen auf das selbe Verzeichnis zu leiten - hoffe ich jetzt mal ;-)

Gruß
Josh

[Tom]

Hello,

Bist du mit deiner Anwendung alleiniger Nutzer des session.save_path? Wenn nicht, kann es gut sein, dass andere Anwendungen, die die Default-Einstellungen verwenden, deine Sessiondateien aufräumen. Der Aufräummechanismus hat keine Chance bei einem gemeinsamen Verzeichnis nach Anwendungen getrennt zu agieren.

Dieser Fall würde mich wundern. Der Pfad zeigt zwar zu einem Verzeichnis, auf das ich keinen Zugriff habe, aber mein Provider (die Seite läuft auf einem gemieteten Webspace, nicht auf einem selbst gehosteten Server) wird ja kaum so blöd sein und andere Anwendern/Anwendungen auf das selbe Verzeichnis zu leiten - hoffe ich jetzt mal ;-)

Kommt darauf an, welche Art der Insatallation überhaupt vorliegt.

• PHP als Modul (Achtung! Nur sicher, wenn richtig eingerichtet, dafür aber sehr schnell)
• PHP als CGI (meistens in einer eigenen CHROOT-Umgebung, also relativ sicher)
• PHP als FastCGI (siehe vorstehendes, aber schneller. Nicht so schnell, wie als Modul)
• und was es evtl. sonst noch gibt...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joshh]

Hi,

Kommt darauf an, welche Art der Insatallation überhaupt vorliegt.

• PHP als Modul (Achtung! Nur sicher, wenn richtig eingerichtet, dafür aber sehr schnell)
• PHP als CGI (meistens in einer eigenen CHROOT-Umgebung, also relativ sicher)
• PHP als FastCGI (siehe vorstehendes, aber schneller. Nicht so schnell, wie als Modul)

Es ist als Apache-Modul installiert. Im Plesk kann ich aber auch eine der anderen Möglichkeiten auswählen.

Gruß
Josh

[dedlfix]

Tach!

Kommt darauf an, welche Art der Insatallation überhaupt vorliegt.
Es ist als Apache-Modul installiert. Im Plesk kann ich aber auch eine der anderen Möglichkeiten auswählen.

FCGI mit suEXEC ist auf alle Fälle sinnvoll (zuzüglich angemessener Rechtevergaben). Das Umschalten allein reicht noch nicht, davon ändert sich die Default-Konfiguration nicht. Du musst auch noch den session.save_path ändern (geht auch im Plesk (10), wenn du dazu berechtigt wurdest). Der sollte auf ein Verzeichnis innerhalb deines Userverzeichnisses zeigen, aber außerhalb des DocumentRoots.

dedlfix.

[Joshh]

Hi,

FCGI mit suEXEC ist auf alle Fälle sinnvoll (zuzüglich angemessener Rechtevergaben). Das Umschalten allein reicht noch nicht, davon ändert sich die Default-Konfiguration nicht. Du musst auch noch den session.save_path ändern (geht auch im Plesk (10), wenn du dazu berechtigt wurdest). Der sollte auf ein Verzeichnis innerhalb deines Userverzeichnisses zeigen, aber außerhalb des DocumentRoots.

Ok, aber zur simplen Problemlösung müsste es dann ja auch reichen, das Verzeichnis mit der aktuellen Installation zu wechseln, oder?
Diesen Antworten entnehme ich jetzt auch, dass session.gc_maxlifetime prinzipiell die richtige Stellschraube ist, um zum gewünschten Ergebnis zu kommen?

Gruß
Josh

[Tom]

Hello,

Ok, aber zur simplen Problemlösung müsste es dann ja auch reichen, das Verzeichnis mit der aktuellen Installation zu wechseln, oder?
Diesen Antworten entnehme ich jetzt auch, dass session.gc_maxlifetime prinzipiell die richtige Stellschraube ist, um zum gewünschten Ergebnis zu kommen?

Wenn die Sessions und Temp-Dateien separat pro Domain liegen, ist session.gc_maxlifetime (und bedingt auch seine beiden Brüder)  das Mittel der Wahl, um die Basisschicht des Sessionmanagements stabil zu machen, bzw. die minimal mögliche Sessiondauer zu verlängern.

Wie lange die Session dann wirklich dauert, sollte immer die Appliaktion entscheiden. Diese Zeit muss aber, wie schon gesagt, innerhalb der der Basisschicht liegen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Kommt darauf an, welche Art der Insatallation überhaupt vorliegt.

• PHP als Modul (Achtung! Nur sicher, wenn richtig eingerichtet, dafür aber sehr schnell)
• PHP als CGI (meistens in einer eigenen CHROOT-Umgebung, also relativ sicher)
• PHP als FastCGI (siehe vorstehendes, aber schneller. Nicht so schnell, wie als Modul)

Es ist als Apache-Modul installiert. Im Plesk kann ich aber auch eine der anderen Möglichkeiten auswählen.

Das bedeutet also, dass Du einen eigenen Root-Swerverr bzw. VServer mit Root-Zugang hast?

Dann bekommst Du das PHP auch sicher eingerichtet für konkurrierende Domains. Das Problem bleibt nur der Serverzugang für Dateiübertragung. Einen SSH-Zugang pro Domain kannst Du nur dann vergeben, wenn Du eine CHROOT-Umgebung sicherstellen kannst. Ein FTP-Zugang bietet leider nicht die erforderlichen Möglichkeiten, die Rechte von Dateien und Verzeichnissen passend einstellen zu können.

Es wären dann immer noch spezielle Upload-Scripte notwendig, damit die User keine Probleme bekommen.

Der Safe-Mode ist absolut überflüssig. Er behindert mehr, als er für Sicherheit sorgen würde.

Allerdings müsstest Du bei einem shared Hosting (wenn Du das hier überhaupt anbieten willst), noch die Systemfunktionen in PHP "zu Fuß" ausschalten. Das ist der eigentliche Nutzen vom Safe-Mode gewesen, dass der das mittels EINES Schalters gemacht hat.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joshh]

Hallo,

Das bedeutet also, dass Du einen eigenen Root-Swerverr bzw. VServer mit Root-Zugang hast?

Nope, nur Webspace (und Domain).

Der Safe-Mode ist absolut überflüssig. Er behindert mehr, als er für Sicherheit sorgen würde.

Diese Erfahrung habe ich in anderem Zusammenhang auch schon gemacht.

Gruß
Josh

[Tom]

Hello,

Das bedeutet also, dass Du einen eigenen Root-Swerverr bzw. VServer mit Root-Zugang hast?

Nope, nur Webspace (und Domain).

Dann ist die Diskussion bisher eher akademisch einzustufen.

Wir müssten also mal überlegen, ob Du dich "von innen nach außen" wehren kannst gegen Fehleinrichtung. Das ist im Prinzip schon erledigt, wenn open_basedir vom Provider nur für irgendeinen der Mitbenutzer nicht richtig eingestellt wurde.

Wie sieht denn Deine Ausgabe auf php_info() aus? Du könntest die ja mal (mit Domain usw. geschwärzt) als Grafik irgendwo hochladen.

Sonst ist es eigentlich nicht mehr sinnvoll weiterzudiskutieren, auch wenn das weitre theoretische Erkenntnisse bringen könnte.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joshh]

Hi

Wie sieht denn Deine Ausgabe auf php_info() aus? Du könntest die ja mal (mit Domain usw. geschwärzt) als Grafik irgendwo hochladen.

Dann mache ich das nachher mal. Muss jetzt erstmal los, gleich kommt ja ein wichtiges Spiel ;-)

Gruß
Josh

[Joshh]

Hi,

Wie sieht denn Deine Ausgabe auf php_info() aus? Du könntest die ja mal (mit Domain usw. geschwärzt) als Grafik irgendwo hochladen.

Ich habe mal den Teil mit den Sessions hochgeladen:
https://docs.google.com/open?id=0Bw2pG879XPnNVHNERkJIT3Blenc

Was brauchst du sonst? Die ganze Info-Seite zu knipsen, wäre vielleicht ein bisschen Overload..

Gruß
Josh

[Tom]

Hello,

Wie sieht denn Deine Ausgabe auf php_info() aus? Du könntest die ja mal (mit Domain usw. geschwärzt) als Grafik irgendwo hochladen.

Ich habe mal den Teil mit den Sessions hochgeladen:
https://docs.google.com/open?id=0Bw2pG879XPnNVHNERkJIT3Blenc

Was brauchst du sonst? Die ganze Info-Seite zu knipsen, wäre vielleicht ein bisschen Overload..

Wichtig wäre noch der erste Teil, in der die Server-API benannt ist.
Wenn da "Apache Handler" drinsteht, läuft PHP bei Dir als Modul. Dann benötigt man noch die Angaben von "open_basedir"

Die Sessions in /var/lib/php5 abzuspeichern, ist natürlich ziemlicher Schrott, wenn sich dieses Verzeichnis nicht in einbem "Jail" befindet, also nur eine gleichnamig benanntes Verzeichnis in deinem persönlichen Bereich ist.

Wer ist denn der Provider?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joshh]

Hallo,

Wichtig wäre noch der erste Teil, in der die Server-API benannt ist.
Wenn da "Apache Handler" drinsteht, läuft PHP bei Dir als Modul. Dann benötigt man noch die Angaben von "open_basedir"

Hier der erste Teil.

open_basedir lautet:
  /var/www/vhosts/***meinedomain.de***/httpdocs:/tmp:/usr/share/php

Die Sessions in /var/lib/php5 abzuspeichern, ist natürlich ziemlicher Schrott, wenn sich dieses Verzeichnis nicht in einbem "Jail" befindet, also nur eine gleichnamig benanntes Verzeichnis in deinem persönlichen Bereich ist.

Sollte ich dann für session.save_path ein Verzeichnis parallel zu 'httpdocs' wählen?

Wer ist denn der Provider?

Padberg

Gruß
Josh

[Tom]

Hello,

Wichtig wäre noch der erste Teil, in der die Server-API benannt ist.
Wenn da "Apache Handler" drinsteht, läuft PHP bei Dir als Modul. Dann benötigt man noch die Angaben von "open_basedir"

Hier der erste Teil.

open_basedir lautet:
  /var/www/vhosts/***meinedomain.de***/httpdocs:/tmp:/usr/share/php

Die Sessions in /var/lib/php5 abzuspeichern, ist natürlich ziemlicher Schrott, wenn sich dieses Verzeichnis nicht in einbem "Jail" befindet, also nur eine gleichnamig benanntes Verzeichnis in deinem persönlichen Bereich ist.

Sollte ich dann für session.save_path ein Verzeichnis parallel zu 'httpdocs' wählen?

Das ist alles nicht so gut.
Die erste Möglichkeit wäre, den Provider zu wechseln.

Bevor wir die beiden andern Möglichkeiten erläutern, benötigen wir noch die Abschnitte / die Einstellungen, die "disable_functions", "safe_mode" und "uload_tmp_dir" enthalten.

Und probieren wir mal, ob der Provider freiwillig die Konfiguration berichtigt :-O

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joshh]

Hi,

Die erste Möglichkeit wäre, den Provider zu wechseln.

Hast du eine Empfehlung? Demnächst wollte ich sowieso mal nach einem anderen Paket schauen. Unzufrieden war ich bisher mit meinem Provider nicht, läuft alles schön unkompliziert (wenn man keine Fragen an den lahmen Support hat - wenigstens bei kritischen Sachen sind die richtig fix).

Bevor wir die beiden andern Möglichkeiten erläutern, benötigen wir noch die Abschnitte / die Einstellungen, die "disable_functions", "safe_mode" und "uload_tmp_dir" enthalten.

Knips

Und probieren wir mal, ob der Provider freiwillig die Konfiguration berichtigt :-O

Wäre nicht schlecht ;-)

Danke & Gruß
Josh

[Tom]

Hello,

Die erste Möglichkeit wäre, den Provider zu wechseln.

Das wird vermutlich die einzige bleiben, wenn der Provider nicht bereit ist, seine Konfiguration grundlegend zu ändern. Das muss er aber für alle User auf dem Shared Host, sonst bringt es nichts.

Er darf bei keinem einzigen dann einen Fehler machen

Hast du eine Empfehlung? Demnächst wollte ich sowieso mal nach einem anderen Paket schauen. Unzufrieden war ich bisher mit meinem Provider nicht, läuft alles schön unkompliziert (wenn man keine Fragen an den lahmen Support hat - wenigstens bei kritischen Sachen sind die richtig fix).

Solange sich alle an die Regeln halten, ist es ja auch nicht gefährlich. Aber ich habe selbst im Freundeskreis feststellen müssen, dass Vertrauen nichts wert ist, wenn man keine Kontrolle hat.

Bevor wir die beiden andern Möglichkeiten erläutern, benötigen wir noch die Abschnitte / die Einstellungen, die "disable_functions", "safe_mode" und "uload_tmp_dir" enthalten.

Knips

Und probieren wir mal, ob der Provider freiwillig die Konfiguration berichtigt :-O

Du solltest auf diesem Host z.Zt. nix mehr machen, was für dich wichtig sein könnte. Sichere deine gesamten Strukturen und alle Scripte und Einstellungen extern (also zuhause) und führe mal zur Verdeutlichung der Problematik ein paar "Tests" durch.

Nr. 1:

<?php   ### session_check.php

$_return = glob('/var/lib/php5/sess_*');

echo "<pre>\r\n";
echo "htmlspecialchars(print_r($_return,1));
echo "</pre>\r\n";

?>

und dann suchst Du Dir eine der Sessiondateien aus

z.B. im Format  "sess_ffdc2d5ccb24c9ec137b1b083633440c"

<?php   ### session_check.php

$sessionfile = '????';   ## hier einsetzen ohne das führende "sess_"
session_id($sessionfile);
session_start();

echo "<pre>\r\n";
echo "htmlspecialchars(print_r($_SESSION),1);
echo "</pre>\r\n";

?>

Aber bitte nichts in den $_SESSION-Arrays ändern... Das wäre wirklich böse!

Und dann mal die Ergebnisse hier posten...
Sollen ja Alle etwas davon haben.

Deinen Provider sollten wir dann mal anschließend ansprechen, falls das hier zu positiven Ergebissen (also im Sinne der Annahmen) führt.

Du solltest Dir ggf, eine eigenen kleinen VServer mieten. Die gibt es schon für 9 Euronen im Monat. Dann könntest Du (vorsichtig) eigene Erfahrungen sammeln. Allerdings sollte dieser VServer über eine Managementfunktion verfügen, mit dem man ihn ständig auf dem Laufenden halten kann. Sonst schaffst Du Dir nur Kummer an.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joshh]

Hi,

danke dir für die vielen guten kompetenten Inputs. Dann habe ich für morgen Abend mal was zum Testen, vorher komme ich leider nicht dazu.
Einen VServer habe ich mir auch schon überlegt, ich glaube nur, dass das momentan meinen zeitlichen Rahmen etwas sprengt...
Sicherungen habe ich von allen wichtigen (und unwichtigen) Daten doppelt und dreifach (getreu dem Motto: Daten, von denen keine Sicherung existert, sind per Definition unwichtig).

Gruß
Josh

[dedlfix]

Tach!

Die erste Möglichkeit wäre, den Provider zu wechseln.
Das wird vermutlich die einzige bleiben, wenn der Provider nicht bereit ist, seine Konfiguration grundlegend zu ändern. Das muss er aber für alle User auf dem Shared Host, sonst bringt es nichts.

Nein, Joshh kann doch auf (F)CGI umstellen, dann läuft zusammen mit suEXEC das ganze unter seinem Useraccount. Und die anderen, selbst wenn sie die Modulvariante verwenden, können auf seine Dateien nicht mehr zugreifen - die richtigen Berechtigungen vorausgesetzt.

Jetzt noch session.save_path einstellen ...

Du solltest auf diesem Host z.Zt. nix mehr machen, was für dich wichtig sein könnte. Sichere deine gesamten Strukturen und alle Scripte und Einstellungen extern (also zuhause) und führe mal zur Verdeutlichung der Problematik ein paar "Tests" durch.

Sei mal nicht so negativ, Plesk ist nicht per se unsicher.

Du solltest Dir ggf, eine eigenen kleinen VServer mieten. Die gibt es schon für 9 Euronen im Monat. Dann könntest Du (vorsichtig) eigene Erfahrungen sammeln. Allerdings sollte dieser VServer über eine Managementfunktion verfügen, mit dem man ihn ständig auf dem Laufenden halten kann. Sonst schaffst Du Dir nur Kummer an.

Er hat Plesk zur Verfügung und kann gewisse Dinge selbst einstellen. Es wäre besser, an dieser Stelle anzusetzen, als den Hoster unnötig madig zu machen.

Miete dir mal so einen VServer mit Plesk (es gibt auch welche mit Rückgabemöglichkeit). Da kannst du selbst al sehen, was da alles möglich ist, und beim nächsten Mal zielgerichteter helfen :-)

Abgesehen davon hat er mit einem VServer nicht mehr nur PHP zu administrieren, sondern einen ganzen Server. Er tauscht die (Komfort-weil-Plesk-)Kabine gegen ein ganzes Schiff. Das ist viel mehr Aufwand, als für die eigentliche und ausreichend sichere Problemlösung notwendig ist.

dedlfix.

[Tom]

Hello,

Die erste Möglichkeit wäre, den Provider zu wechseln.
Das wird vermutlich die einzige bleiben, wenn der Provider nicht bereit ist, seine Konfiguration grundlegend zu ändern. Das muss er aber für alle User auf dem Shared Host, sonst bringt es nichts.

Nein, Joshh kann doch auf (F)CGI umstellen, dann läuft zusammen mit suEXEC das ganze unter seinem Useraccount. Und die anderen, selbst wenn sie die Modulvariante verwenden, können auf seine Dateien nicht mehr zugreifen - die richtigen Berechtigungen vorausgesetzt.

Könnte es sein, dass Du irrst?

Gegen die vorhanden Sicherheitslücken kann Josh leider nicht viel unternehmen. Solange die anderen User auf dem Server noch die Systemfunktionen von PHP benutzen dürfen (exec, system, usw.) kommen sie überall heran, wo der PHP-Prozess auch dran kommt, also zumindest an die Verzeichnisse der anderen PHP-User, wenn nicht sogar an Systemverzeichnisse.

Das ändert auch nichts, wenn Josh sich nun beschränkt und auf CGI umstellt. Dann müssten alle PHP-Verwender auf CGI umgestellt werden.

Deine anderen Bemerkungen stelle ich mal zur späteren Diskussion zurück. :-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Nein, Joshh kann doch auf (F)CGI umstellen, dann läuft zusammen mit suEXEC das ganze unter seinem Useraccount. Und die anderen, selbst wenn sie die Modulvariante verwenden, können auf seine Dateien nicht mehr zugreifen - die richtigen Berechtigungen vorausgesetzt.
Könnte es sein, dass Du irrst?

Ja, aber in dem Fall vermutlich nicht.

Gegen die vorhanden Sicherheitslücken kann Josh leider nicht viel unternehmen. Solange die anderen User auf dem Server noch die Systemfunktionen von PHP benutzen dürfen (exec, system, usw.) kommen sie überall heran, wo der PHP-Prozess auch dran kommt, also zumindest an die Verzeichnisse der anderen PHP-User, wenn nicht sogar an Systemverzeichnisse.

Nochmal zum Mitschreiben: Wenn PHP als (F)CGI zusammen mit suEXEC verwendet wird, was bei Plesk (10) der Fall ist, läuft diese Instanz unter einer eigenen Userkennung. Andere Nutzer, auch wenn sie ihr PHP-Zeugs als Apache-Modul laufen lassen, verwenden andere Kennungen. Damit ist die Trennung mittels der Dateiberechtigungen möglich. Und an diesen kommen auch exec, system und usw. nicht vorbei.

Dass suEXEC verwendet wird, kann man unterhalb seines Benutzerverzeichnisses im Verzeichnis conf nachsehen. Dort liegen ein bis mehrere Konfigurationsdateien, die für die Konfiguration des VHosts des Benutzers zuständig sind. Die neueste ist die aktuelle.

Das ändert auch nichts, wenn Josh sich nun beschränkt und auf CGI umstellt. Dann müssten alle PHP-Verwender auf CGI umgestellt werden.

Doch bzw. nein. Ein eigener Benutzer ist ausreichend. Nicht ausreichend wäre es hingegen, wenn alle mit Apache-Modul arbeiten und einige davon unsichere Einstellungen haben.

dedlfix.

[Tom]

Hello,

Nochmal zum Mitschreiben: Wenn PHP als (F)CGI zusammen mit suEXEC verwendet wird, was bei Plesk (10) der Fall ist, läuft diese Instanz unter einer eigenen Userkennung. Andere Nutzer, auch wenn sie ihr PHP-Zeugs als Apache-Modul laufen lassen, verwenden andere Kennungen. Damit ist die Trennung mittels der Dateiberechtigungen möglich. Und an diesen kommen auch exec, system und usw. nicht vorbei.

Tja, da sind wir dann bei Adam & Eve angekommen.

Du bekommst die Dateiberechtigungen nicht so eingestellt, dass die anderen User nicht zumindest lesen können, denn dazu müsste der User Josh auch einen eigenen Apache-Server (oder anderen Webserver) laufen haben. Sonst kommt der gemeinsame Apache nämlich nicht mehr an die Files.

Du kannst dich drehen und wenden wie Du willst. Josh bekommt seinen Account nicht alleine sicher!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Du bekommst die Dateiberechtigungen nicht so eingestellt, dass die anderen User nicht zumindest lesen können, denn dazu müsste der User Josh auch einen eigenen Apache-Server (oder anderen Webserver) laufen haben. Sonst kommt der gemeinsame Apache nämlich nicht mehr an die Files.

Ja. Und? War es eine Anforderung, dass gar nichts lesbar sein soll? Der Apache muss nur die Dateien lesen können, die er direkt ausliefert, sowie seine Konfigurationsdateien (inklusive .htaccess und co.). Die PHP-Dateien und -Verzeichnisse können dem suEXEC-User gehören, ohne Zugriff für andere User. Das reicht üblicherweise. Die direkt ausgelieferten Apache-Dateien sind in der Regel sowieso frei zugänglich. Lediglich wenn ein HTTP-Auth-Schutz vorhanden ist, kann dieser hintenrum umgangen werden, inklusive der dafür notwendigen Konfigurationsdateien.

Du kannst dich drehen und wenden wie Du willst. Josh bekommt seinen Account nicht alleine sicher!

Hat er denn die Anforderung, völlig abgeschottet zu sein? Ein Wechsel zu einem dedizierten Server ist in meinen Augen nur notwendig, wenn solch hohe Sicherheitsanforderungen bestehen.

dedlfix.

[Joshh]

Hallo,

Nr. 1:

<?php   ### session_check.php

$_return = glob('/var/lib/php5/sess_*');

echo "<pre>\r\n";
echo "htmlspecialchars(print_r($_return,1));
echo "</pre>\r\n";

?>

Das liefert mir eine leere Seite (also das pre-Tag ohne Inhalt). Die Anführungszeichen vor htmlspecialchars habe ich entfernt ;-)
Ist doch eigentlich kein schlechtes Zeichen, oder?

Gruß
Josh

[Tom]

Hello,

Hallo,

Nr. 1:

<?php   ### session_check.php

$_return = glob('/var/lib/php5/sess_*');

echo "<pre>\r\n";
echo htmlspecialchars(print_r($_return,1));
echo "</pre>\r\n";

?>

Das liefert mir eine leere Seite (also das pre-Tag ohne Inhalt). Die Anführungszeichen vor htmlspecialchars habe ich entfernt ;-)
Ist doch eigentlich kein schlechtes Zeichen, oder?

Keine Sessions drin.
Und wenn Du vorher eine startest?

<?php   ### session_check.php

session_start();
    $_return = glob('/var/lib/php5/sess_*');

echo "<pre>\r\n";
    echo htmlspecialchars(print_r($_return,1));
    echo "</pre>\r\n";

?>

Taucht die dann wenigstens dort auf?

Aber wenn ich es genauer betrachte, können die Sessions gar nicht dort gespeichert werden, da der Pfad nämlich in open_basedir gar nicht aufgeführt ist. Und beim Session-Handler greift die open_basedir-Restriktion. So kannst Du eigentlich gar keine Sessions speichern.

Dass Glob() keinen Fehler und kein Ergebnis liefert, liegt an der Bauweise von glob(). Es scannt nur die für den User zugänglichen Verzeichnisse.

Wenn Du das Scan-Progrämmle la auf /usr/share/php/* ansetzen würdest, müsstest Du Ergebnisse bekommen.

Das Problem wird sowieso langsam akademisch. Ich habe heute Nachmittag im Wartezimmer vom Dok auch noch lange über Dedlfix's Post nachgedacht
https://forum.selfhtml.org/?t=209977&m=1429645

Ich bin mir nicht sicher, ob man diese Einrichtung nachhaltig "dicht" bekommt, auch wenn Du auf CGI wechslen würdest. Die anderen User haben ja immer noch die Exec-Funktion, die sich in der von ihr eröffneten Shell nicht die Bohne um die open_basedir-Restriktionen kümmert. Die können auf diese Weise alle Dateien auslesen, die dem php-prozess-Eigentümer zugänglich sind. Passwortdateien und Daten müsstest Du dann also immer so ablegen, dass nur Dein CGI-PHP-User Zugriff hat.

Fragt sich, welche Gruppe automatisch eingerichtet wird, wenn Du mittels PHP-CGI oder mittels FTP ein Verzeichnis oder eine Datei anlegst.

Ich würde mich freuen, wenn auch Dedlfix nicht so absolut von sich überzeugt wäre, sondern auch mal seine eigene These anzugreifen versuchte, also so fair wäre, mal den genauen Weg aufzuzeigen, den er gehen würde und dann veruschen würde, in seine eigene Idee ein Loch zu bohren. Wenn er das nicht schafft und wir auch nicht, erst dann will ich es glauben, dass es geht, auch wenn die anderen User weiterhin ihre Schrott-Einrichtung behalten.

Damit Deine Sessions überhaupt erstmal funktionieren, müss der session.save_path so eingestellt werden, dass Du ihn mit php auch beschreiben darfst. Das kannst Du hoffentlich in einer .htaccess-Datei tun

.htaccess

php_value session.save_path /var/www/vhosts/___________/httpdocs/sessions

Das Verzeichnis muss dan da sein, sonst wird es einen Fehler geben. PHP muss reinschreiben dürfen.

Du kannst den aber jetzt nur in ein Unterverzeihnis deiner htdocs verlegen. Dort musst Du dann dafür sorgen, dass dieses Verzeichnis nicht per HTTP auslesbar ist, also z.B. mit Hilfe einer .htaccess-Datei, die ein DENY enthält.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Ich bin mir nicht sicher, ob man diese Einrichtung nachhaltig "dicht" bekommt, auch wenn Du auf CGI wechslen würdest. Die anderen User haben ja immer noch die Exec-Funktion, die sich in der von ihr eröffneten Shell nicht die Bohne um die open_basedir-Restriktionen kümmert. Die können auf diese Weise alle Dateien auslesen, die dem php-prozess-Eigentümer zugänglich sind. Passwortdateien und Daten müsstest Du dann also immer so ablegen, dass nur Dein CGI-PHP-User Zugriff hat.

Seitens PHP (als (F)CGI mit suEXEC) bekommst du die Konfiguration so dicht, wie es in dem Multiusersystem Unix/Linux gehen kann. Der Schwachpunkt sind die Dateien, die der Apache lesen muss - der bleibt shared [*]. Alles was unter PHP läuft und nur von PHP aus zugreifbar sein muss, kann durch die eigene Kennung und die Berechtigungsvergabe gesichert werden (Multiuserprinzip von Unix/Linux).

Fragt sich, welche Gruppe automatisch eingerichtet wird, wenn Du mittels PHP-CGI oder mittels FTP ein Verzeichnis oder eine Datei anlegst.

psacln heißt die bei Plesk. Da sind alle Webserver-Nutzer drin. Und die ist auch bei suEXEC angegeben.

Ich würde mich freuen, wenn auch Dedlfix nicht so absolut von sich überzeugt wäre, sondern auch mal seine eigene These anzugreifen versuchte,

Meine Thesen basieren auf der Erfahrung mit Plesk-Systemen.

Damit Deine Sessions überhaupt erstmal funktionieren, müss der session.save_path so eingestellt werden, dass Du ihn mit php auch beschreiben darfst. Das kannst Du hoffentlich in einer .htaccess-Datei tun

Erstmal in der Plesk-Konfiguration nachschauen, ob das da erlaubt wurde. In aktuellen Plesk-Versionen gibt es eine Menge dieser grundlegenden PHP-Konfigurationsmöglichkeiten. Und die bleiben dann auch erhalten (bzw. werden entsprechend umgeschrieben), wenn man zwischen Modul und CGI wechselt oder Plesk anderweitig angewiesen wird, an der Konfiguration was zu ändern. CGI verwendet ja eine eigene php.ini und die Modulversion lässt sich über .htaccess konfigurieren.

Du kannst den aber jetzt nur in ein Unterverzeihnis deiner htdocs verlegen. Dort musst Du dann dafür sorgen, dass dieses Verzeichnis nicht per HTTP auslesbar ist, also z.B. mit Hilfe einer .htaccess-Datei, die ein DENY enthält.

Das Userverzeichnis bei Plesk ist /var/www/vhosts/eingerichteter_name/. Das gehört root/root mit drwxr-xr-x, es lässt sich als User also darein nicht direkt schreiben. DocumentRoot ist im Unterverzeichnis httpdocs. Mit dem File Manager im Control Panel kann man sich nun einen geeigneten Platz suchen, der dem Nutzer gehört, in den man auch schreiben darf, der aber keine Zugriffe von anderen Gruppen außer root zulässt. Mindestens das Verzeichnis private sollte diese Bedingung erfüllen.

[*] Ich kenne jedenfalls keine Möglichkeit, dass der Apache sich nach Usern aufteilen ließe. Beim IIS geht das über Application Pools, in denen die Requests zusammen mit einem dedizierten User eingesperrt werden können.

dedlfix.

[Joshh]

Moin,

Keine Sessions drin.
Und wenn Du vorher eine startest?

Taucht die dann wenigstens dort auf?

Nein, genau das gleiche.

Aber wenn ich es genauer betrachte, können die Sessions gar nicht dort gespeichert werden, da der Pfad nämlich in open_basedir gar nicht aufgeführt ist. Und beim Session-Handler greift die open_basedir-Restriktion. So kannst Du eigentlich gar keine Sessions speichern.

Aber faktisch geht es ja. Ich hab ja nur das Problem, dass es zu schnell wieder aufhört... ;-)

Wenn Du das Scan-Progrämmle la auf /usr/share/php/* ansetzen würdest, müsstest Du Ergebnisse bekommen.

Jo, dann werden Dateien aufgelistet.

Gruß
Josh

[dedlfix]

Tach!

Aber wenn ich es genauer betrachte, können die Sessions gar nicht dort gespeichert werden, da der Pfad nämlich in open_basedir gar nicht aufgeführt ist. Und beim Session-Handler greift die open_basedir-Restriktion. So kannst Du eigentlich gar keine Sessions speichern.

Es gibt da ein Bug-Ticket, das besagt, dass session.save_path (und error_log) nicht von open_basedir beschränkt wird. Der Grund ist, dass man das System so konfigurieren können muss, dass dem Script-Code nicht erlaubt ist, auf dieses Verzeichnis zuzugreifen (und man ein zentrales, ebenfalls unerreichbares error_log verwenden kann), es also außerhalb von open_basedir liegen können muss.

Aber faktisch geht es ja. Ich hab ja nur das Problem, dass es zu schnell wieder aufhört... ;-)

Hast du mal (mit Plesk) den session.save_path auf ein individuelles Verzeichnis gelegt? Das was der Tom da alles aufführt, ist zwar nicht generell unwichtig, aber wenn der Sicherheitsaspekt für dein Projekt uninteressant ist, dann musst du nicht so viel Aufwand treiben.

dedlfix.

[Tom]

Hello Dedlfix,

Aber wenn ich es genauer betrachte, können die Sessions gar nicht dort gespeichert werden, da der Pfad nämlich in open_basedir gar nicht aufgeführt ist. Und beim Session-Handler greift die open_basedir-Restriktion. So kannst Du eigentlich gar keine Sessions speichern.

Es gibt da ein Bug-Ticket, das besagt, dass session.save_path (und error_log) nicht von open_basedir beschränkt wird.

Nicht beschränkt werden sollen, so wie ich das lese.

Oder habe ich es verkehrt verstanden? Ab welkcher Version sind denn die Sessions von der open_basedir-Restriction ausgenommen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Es gibt da ein Bug-Ticket, das besagt, dass session.save_path (und error_log) nicht von open_basedir beschränkt wird.
Nicht beschränkt werden sollen, so wie ich das lese.
Oder habe ich es verkehrt verstanden? Ab welkcher Version sind denn die Sessions von der open_basedir-Restriction ausgenommen?

Das liest sich für mich so, als ob da mal jemand aus Versehen eingebaut hat, Sessions in open_basedir einzumauern und das noch vor dem Release einer ordentlichen Version wieder gefixt wurde, weil sonst jede Menge Hoster geheult hätten.

dedlfix.

[Tom]

Hello,

Es gibt da ein Bug-Ticket, das besagt, dass session.save_path (und error_log) nicht von open_basedir beschränkt wird.
Nicht beschränkt werden sollen, so wie ich das lese.
Oder habe ich es verkehrt verstanden? Ab welkcher Version sind denn die Sessions von der open_basedir-Restriction ausgenommen?

Das liest sich für mich so, als ob da mal jemand aus Versehen eingebaut hat, Sessions in open_basedir einzumauern und das noch vor dem Release einer ordentlichen Version wieder gefixt wurde, weil sonst jede Menge Hoster geheult hätten.

So wie ich mich erinnere, war nur das Standard-Session-Verzeichnis frei von open_basedir-Restrictions, und das war /tmp

Sowie man einen session.save_path angegeben hat, griff die open_basedir-Restriction, was ja auch ganz vernünftig ist, da der session.save_path schon immer PHP_INI_ALL war. Da könnte der Scriptnutzer einer Modulversion seine Sessions ja sonst überall hinlegen. Außerdem gibt es überhaupt keinen Grund, warum ein Scriptnutzer die Sessions seines eigenen Accounts nicht auslesen können sollte.

Ich habe z.B. in meinem Sessionmodul den Sessionbetrieb sowohl über Cookie, als auch über Basic Auth eingebaut. Und dazu muss ich den session.save_path auch beschreiben und auslesen können.

Ich interpretiere diese "Bug-Meldung" daher als unüberlegten Versuch, etwas zu verschlimmbessern, was eigentlich ganz sinnvoll gelöst ist.

Nun kenn ich mich mit dem Bug-Tracker zu wenig aus, um feststellen zu können, was aus der Meldung geworden ist.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Außerdem gibt es überhaupt keinen Grund, warum ein Scriptnutzer die Sessions seines eigenen Accounts nicht auslesen können sollte.

Ein Grund wäre, dass man diese Dateien nicht mit fopen() & Co. sondern nur über die Session-Funktionen erreichen können muss. Dann kann man auch nicht einfach mal so ein glob() machen und sich die Dateien zu Gemüte führen, sondern muss erstmal gültige IDs erraten.

Ich habe z.B. in meinem Sessionmodul den Sessionbetrieb sowohl über Cookie, als auch über Basic Auth eingebaut. Und dazu muss ich den session.save_path auch beschreiben und auslesen können.

Musst du das generell oder müssen das nur die Session-Funktionen können?

Nun kenn ich mich mit dem Bug-Tracker zu wenig aus, um feststellen zu können, was aus der Meldung geworden ist.

Ganz oben "Status: Closed", ganz unten "fixed in 5.2.4 (RC2)".

dedlfix.

[Tom]

Hello,

So wie ich mich erinnere, war nur das Standard-Session-Verzeichnis frei von open_basedir-Restrictions, und das war /tmp

Sowie man einen session.save_path angegeben hat, griff die open_basedir-Restriction, was ja auch ganz vernünftig ist, da der session.save_path schon immer PHP_INI_ALL war. Da könnte der Scriptnutzer einer Modulversion seine Sessions ja sonst überall hinlegen. Außerdem gibt es überhaupt keinen Grund, warum ein Scriptnutzer die Sessions seines eigenen Accounts nicht auslesen können sollte.

Das ist ja eine ganz böse Sache. Ich habe das eben auf PHP 5.2.9 auf Xampp ausprobiert. Da kann man die sessions hinlegen, wo man will, also auch ins Verzeichnis eines anderen Users.

Auslesen mit glob(), fopen(), usw, kann man sie aber scheinbar nicht. Da greift ja auch noch die Open_Basedir-Restriktion.

Die anderen mir verfügbaren Versionen werde ich jetzt auch nochmal testen.

Und es gibt noch mehr Ungereimtheiten, habe ich gerade festgestellt. Na, schaun wir mal :-(

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Das ist ja eine ganz böse Sache. Ich habe das eben auf PHP 5.2.9 auf Xampp ausprobiert. Da kann man die sessions hinlegen, wo man will, also auch ins Verzeichnis eines anderen Users.

Wenn man dafür Schreibrechte hat.

Auslesen mit glob(), fopen(), usw, kann man sie aber scheinbar nicht. Da greift ja auch noch die Open_Basedir-Restriktion.

Wie es das Ticket beschreibt. open_basedir allein ist jedenfalls kein Sicherheitskonzept.

dedlfix.

[Tom]

Hello,

Das ist ja eine ganz böse Sache. Ich habe das eben auf PHP 5.2.9 auf Xampp ausprobiert. Da kann man die sessions hinlegen, wo man will, also auch ins Verzeichnis eines anderen Users.

Wenn man dafür Schreibrechte hat.

Beim Modulsystem hat der PHP-Prozess die nötigen Schreibrechte. Und da open_basedir als bisher interne Kontrolle des Runtime nun ausgehebelt ist, wurde ein Loch aufgerissen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Das ist ja eine ganz böse Sache. Ich habe das eben auf PHP 5.2.9 auf Xampp ausprobiert. Da kann man die sessions hinlegen, wo man will, also auch ins Verzeichnis eines anderen Users.

Mit 5.3.8 auf Xampp sieht es genauso aus. Benutzer von PHP-Modul können sich jetzt gegenseitig ihre Sessions kaputtschreiben und natürlich auch auslesen, wenn sie den Session-Key wissen. Dazu muss man ja nur eine Session auf den vorhandenen Key starten.

Das ist eine Entwicklung in Richtung UNSICHER!

Das einzige, was der Admin jetzt noch machen kann, ist für jeden Account einen eigenen Session-Save-Path anzulegen mittels php_admin_value, in der Hoffnung, dass der User den dann in seinen Scripten nicht mehr ändern kann.

Das habe ich noch nicht ausprobiert. Muss jetzt auch erstmal zum Dok.

Hier wurde eindeutig etwas verschlimmbessert.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Mit 5.3.8 auf Xampp sieht es genauso aus. Benutzer von PHP-Modul können sich jetzt gegenseitig ihre Sessions kaputtschreiben und natürlich auch auslesen, wenn sie den Session-Key wissen. Dazu muss man ja nur eine Session auf den vorhandenen Key starten.
Das ist eine Entwicklung in Richtung UNSICHER!

Das Argument gilt im Prinzip auch für die Abschaffung des Safe Mode. Und trotzdem gab es gute Gründe, ihn zu schleifen.

Das einzige, was der Admin jetzt noch machen kann, ist für jeden Account einen eigenen Session-Save-Path anzulegen mittels php_admin_value, in der Hoffnung, dass der User den dann in seinen Scripten nicht mehr ändern kann.

Das muss er nicht hoffen, denn laut PHP-Handbuch kann eine php_admin_value/flag-Einstellung weder in .htaccess noch mit ini_set() geändert werden. Wer die Modulvariante verwendet, braucht eigentlich auch gar keine Sicherheit.

Welcher gewichtige Aspekt spricht denn trotz solcher Security-Anforderungen für eine Verwendung des Apache-Moduls gegenüber (F)CGI mit suEXEC?

dedlfix.

[Tom]

Hello,

Mit 5.3.8 auf Xampp sieht es genauso aus. Benutzer von PHP-Modul können sich jetzt gegenseitig ihre Sessions kaputtschreiben und natürlich auch auslesen, wenn sie den Session-Key wissen. Dazu muss man ja nur eine Session auf den vorhandenen Key starten.
Das ist eine Entwicklung in Richtung UNSICHER!

Das Argument gilt im Prinzip auch für die Abschaffung des Safe Mode. Und trotzdem gab es gute Gründe, ihn zu schleifen.

Das sehe ich nicht so, da der Safe-Mode viele zusätzliche Probleme und zuviele Regeln mit sich gebnracht hat, die man nicht so schnell durchschauen konnte.

Die Abschaltung aller Systemfunktionen in "system_off_mode" fände ich immer noch genauso gut, wie die strikte Einhaltung von open_basedir, auch für Sessions und Uploads (temporäre Files). Diese klar abgegrenzten Regeln aufzuweichen, ist einfach hirnverbrannt.

Wer die Modulvariante verwendet, braucht eigentlich auch gar keine Sicherheit.

Na das ist jetz mal eine Aussage, die mich hoffen lässt, dass Du gelegentlich auch nur aus dem Bauch heraus denkst und nicht mit dem Kopf und Andre eine Chance haben, Dir zu beweisen, dass das falsch ist...

Wenn FTP-Server genauso gebaut wären, wie Du das hier für die PHP-Modul-Version propagierst, dann könnte das Internet schon lange einpacken. Das soll nicht heißen, dass ich FTP als Protokoll akzepitere, denn das ist nicht verschlüsselt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Die Abschaltung aller Systemfunktionen in "system_off_mode" fände ich immer noch genauso gut, wie die strikte Einhaltung von open_basedir, auch für Sessions und Uploads (temporäre Files). Diese klar abgegrenzten Regeln aufzuweichen, ist einfach hirnverbrannt.

Zumindest ist das in einem alten XAMPP mit PHP 4.3.3 schon so gewesen.

Wer die Modulvariante verwendet, braucht eigentlich auch gar keine Sicherheit.
[Polemik]

Eigentlich wäre mir eine Antwort auf die darauffolgende Frage lieber gewesen.

dedlfix.

[Tom]

Hello,

Eigentlich wäre mir eine Antwort auf die darauffolgende Frage lieber gewesen.

Das wird mir alles zu stressig. Ich habe auch keine Bock, mich hier herumzuzanken.
Welche Polemik, welche Frage? Muss _ich_ immer wissenschaftlich korrekt bleiben und _DU_ kannsts Dir alles erlauben? Das ist nicht im Sinne einer Verbesserung der Sachlage...

Mir geht es ausschließlich um die Verbesserung von PHP!

Meine Meinung:

Die Herausnahme von session.save_path aus der open_basedir-Restriction war ein Satansdienst, denn damit wird die Sicherheit gefährdert _und_ der user in der freien Wahl seines Sessionsverzeichnisses eingeschränkt. Warum soll er als Scriptautor nicht mehr (einfach) auf seine Sessions zugreifen können? Kompliziert kann er es doch nach wie vor.

Um die Sicherheit eines Shares Hosts nicht zu gefähren, müsste der Pfad für die Sessions vom Administrator nun für jeden VirtualHost angenagelt werden. Der Admin muss isch also darauf verlassen, dass eine Direktive "php_admin_value" nicht durch eine "php_value" überschrieben werden kann.

Und warum soll der Scriptautor sein Sessionverzeichnis nicht mehr frei (innerhalb seines Bereiches) wählen können?

Dafür sehe ich überhaupt keien Veranlassung.

Hier haben einfach ein paar Leute etwas verschlimmbessert, die das Gesamtsystem nicht nachvollzogen haben. Es war sehr gut so, wie es war.

Und wenn es die einzige Möglichkeit bleibt, die PHP-Entwickler zur Umkehr zu bewegen, dann werde ich demnächst mal anfangen bei den einschlägigen Hackerforen mitzuklesen und vielleicht auch mal was posten.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

welche Frage?

Du versuchst eine sichere Variante mit dem Apache-Modul hinzubekommen, obwohl es mit CGI und suEXEC mit deutlich weniger Sicherheitsproblemen lösbar ist. Ich fragte, warum man bei solchen Sicherheitsanforderungen noch auf der Modulvariante (in einer shared Umgebung) bleiben sollte?

Die Herausnahme von session.save_path aus der open_basedir-Restriction

War es jemals drin? Wenn es schon in PHP 4.3.3 nicht drin war, und in dem Ticket beklagt wurde, dass dieser "Fehler" der Restriktion es sogar bis in einen RC1 geschafft hatte, bezweifle ich das stark.

Der Admin muss isch also darauf verlassen, dass eine Direktive "php_admin_value" nicht durch eine "php_value" überschrieben werden kann.

Das ist laut PHP-Handbuch gegeben. Verlassen muss man sich auch auf alle anderen Sicherheitsaspekte, die laut System gegeben sein sollen.

dedlfix.

[Joshh]

Hallo,

Hast du mal (mit Plesk) den session.save_path auf ein individuelles Verzeichnis gelegt? Das was der Tom da alles aufführt, ist zwar nicht generell unwichtig, aber wenn der Sicherheitsaspekt für dein Projekt uninteressant ist, dann musst du nicht so viel Aufwand treiben.

Also bei Plesk finde ich dafür keine Einstellungsmöglichkeit. Genauso finde ich nirgendwo etwas zu "suEXEC", wenn ich PHP als FCGI einstelle.

Gruß
Josh

[dedlfix]

Tach!

Hast du mal (mit Plesk) den session.save_path auf ein individuelles Verzeichnis gelegt? Das was der Tom da alles aufführt, ist zwar nicht generell unwichtig, aber wenn der Sicherheitsaspekt für dein Projekt uninteressant ist, dann musst du nicht so viel Aufwand treiben.
Also bei Plesk finde ich dafür keine Einstellungsmöglichkeit. Genauso finde ich nirgendwo etwas zu "suEXEC", wenn ich PHP als FCGI einstelle.

Bei Plesk 10.4 ist das im Control Panel auf der Seite, wo du PHP als Modul oder (F)CGI wählen kannst oben ein Reiter mit PHP-Einstellungen. Wenn der nicht da ist, hat das dein Hoster nicht für dich freigegeben (oder das Plesk ist zu alt und kann das noch nicht). suEXEC ist nicht extra erwähnt, wird aber bei Auswahl von FCGI eingestellt. Du kannst das prüfen, indem du im Verzeichnis conf die neueste der mit Ziffern beginnenden httpd_include anschaust (dazu wirst du vermutlich nicht berechtigt sein), da steht jedenfalls die Direktive SuexecUserGroup drin.

dedlfix.

[Joshh]

Hi,

Bei Plesk 10.4 ist das im Control Panel auf der Seite, wo du PHP als Modul oder (F)CGI wählen kannst oben ein Reiter mit PHP-Einstellungen. Wenn der nicht da ist, hat das dein Hoster nicht für dich freigegeben (oder das Plesk ist zu alt und kann das noch nicht). suEXEC ist nicht extra erwähnt, wird aber bei Auswahl von FCGI eingestellt. Du kannst das prüfen, indem du im Verzeichnis conf die neueste der mit Ziffern beginnenden httpd_include anschaust (dazu wirst du vermutlich nicht berechtigt sein), da steht jedenfalls die Direktive SuexecUserGroup drin.

PHP-Einstellungen scheinen gesperrt zu sein (einen entsprechenden Reiter habe ich nicht). Auf das conv-Verzeichnis kann ich auch nicht zugreifen. Allgemein kann ich parallel zu httpdocs kein neues Verzeichnis erstellen.

Wie etwas weiter oben beschrieben habe ich jetzt ein Verzeichnis für die Sessions erstellt und den session.save_path per htaccess auf das neue Verzeichnis gesetzt.

Wie es jetzt aussieht, scheint das die simpelste Lösung zu sein. Jedenfalls eine, die funktioniert...

Gruß
Josh

[dedlfix]

Tach!

Allgemein kann ich parallel zu httpdocs kein neues Verzeichnis erstellen.

Richtig, das geht nicht, aber in private solltest du schreiben können, ohne dass es in httpdocs liegt.

dedlfix.

[Joshh]

Moin,

Richtig, das geht nicht, aber in private solltest du schreiben können, ohne dass es in httpdocs liegt.

In Plesk kann ich da schreiben, aber mit php nicht mal lesen. In dem Verzeichnis liegt eine Hinweisdatei, in der steht:

Access to this directory is available only to you.
  The directory cannot be accessed via any web or system services.

Ich hab zwar die Rechte von rwx - - auf rwx rx rx angepasst, aber ein lesender Zugriff (mit dem session_test skript) klappt trotzdem nicht. Ich habe in dem Skript nach * suchen lassen un in das Verzeichnis eine test.txt gelegt, die dann eigentlich angezeigt werden sollte.

Gruß
Josh

[dedlfix]

Tach!

Richtig, das geht nicht, aber in private solltest du schreiben können, ohne dass es in httpdocs liegt.
In Plesk kann ich da schreiben, aber mit php nicht mal lesen.

Das wundert mich. Zunächst einmal, es gibt zwei Nutzerkennungen, eine für jeden Kunden, eine für jedes Abonement. Kunden bekommen ein oder mehrere Abonements. Wenn du FCGI eingestellt hast, läuft PHP unter der Abo-Kennung. Der Kennung gehören auch die Verzeichnisse private und httpdocs. Wenn du auf beide Verzeichnisse zugreifen kannst, dann verwendest du die Abo-Kennung. Demzufolge müsste auch PHP auf beide Verzeichnisse zugreifen können.

Wenn das auch mit FCGI nicht geht, dann kannst du probieren, das Document-Root von httpdocs in ein Unterverzeichnis dort zu verschieben. Dann sollte PHP "daneben" zugreifen können.

dedlfix.

[Joshh]

Hallo,

Damit Deine Sessions überhaupt erstmal funktionieren, müss der session.save_path so eingestellt werden, dass Du ihn mit php auch beschreiben darfst. Das kannst Du hoffentlich in einer .htaccess-Datei tun

Jep, kann ich.

Das Verzeichnis muss dan da sein, sonst wird es einen Fehler geben. PHP muss reinschreiben dürfen.

Im Moment klappt es aber nur, wenn ich dem Verzeichnis chmod(777) verpasse. Mit 755 oder 775 kam eine Fehlermeldung. Zur Not muss ich das vorübergehend so lassen oder das Verzeichnis mal per php erstellen. In 25 Minuten schaue ich nach, ob ich mich wieder neu anmelden muss, oder ob die Phase der erlaubten Inaktivität jetzt länger geworden ist ;-)

Gruß
Josh

[Tom]

Hello,

Damit Deine Sessions überhaupt erstmal funktionieren, müss der session.save_path so eingestellt werden, dass Du ihn mit php auch beschreiben darfst. Das kannst Du hoffentlich in einer .htaccess-Datei tun

Jep, kann ich.

Das Verzeichnis muss dan da sein, sonst wird es einen Fehler geben. PHP muss reinschreiben dürfen.

Im Moment klappt es aber nur, wenn ich dem Verzeichnis chmod(777) verpasse. Mit 755 oder 775 kam eine Fehlermeldung. Zur Not muss ich das vorübergehend so lassen oder das Verzeichnis mal per php erstellen. In 25 Minuten schaue ich nach, ob ich mich wieder neu anmelden muss, oder ob die Phase der erlaubten Inaktivität jetzt länger geworden ist ;-)

Leg das Verzeichnis nicht mit dem FTP-Programm an, sondern mit PHP. Dann sollte es auch klappen, wenn Du es auf 700 einstellst (mit mxdir() und der Umask oder anschließend mit chmod())

http://de3.php.net/manual/en/function.mkdir.php  bitte genau lesen bezüglich umask!
http://de3.php.net/manual/en/function.chmod.php

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Es ist als Apache-Modul installiert. Im Plesk kann ich aber auch eine der anderen Möglichkeiten auswählen.
Das bedeutet also, dass Du einen eigenen Root-Swerverr bzw. VServer mit Root-Zugang hast?

Nein, nicht zwangsläufig. Plesk ist mandantenfähig. Und man kann seinen Mandanten erlauben, auch die Art der PHP-Einbindung zu ändern. Das setzt aber ein gewisses Vertrauen voraus, besonders wenn auch das open_basedir optional oder änderbar ist.

Dann bekommst Du das PHP auch sicher eingerichtet für konkurrierende Domains.

Da er kein Super-User mit Kontrollmöglichkeit der Einstellungen seiner anderen Mithostlinge ist, bleibt sicherheitstechnisch nur eine suEXEC-Variante übrig. Zusammen mit einem eigenen Useraccount für seine Anwendung (der ist beim Einrichten von Abonnements individuell festzulegen und jeder Kunde/Mandant sollte mindestens ein eigenes Abo haben) hat er es durch die Berechtigungsvergabe im Dateisystem selbst in der Hand, wer da noch zugreifen darf.

dedlfix.

[dedlfix]

Tach!

Dieser Fall würde mich wundern. Der Pfad zeigt zwar zu einem Verzeichnis, auf das ich keinen Zugriff habe,

Zumindest der User, unter dem deine Anwendung läuft, muss darauf Zugriff haben. Und wenn das ein allgemeines, nicht nutzerspezifisches Verzeichnis ist, sind die Chancen sehr hoch, dass das geschilderte Szenario die Problemursache ist.

Kommt darauf an, welche Art der Insatallation überhaupt vorliegt.

• PHP als Modul (Achtung! Nur sicher, wenn richtig eingerichtet, dafür aber sehr schnell)

Mit der ".htaccess" PHP-Einstellungen ändern zu können, lässt keine andere Option zu.

Wie richtet man denn so etwas richtig ein? Wenn alle Anwendungen (meines Wissens) nur unter dem Useraccount des Apachen laufen können, sehe ich keine Möglichkeit der Absicherung (außer dem Safe Mode, der ab PHP 5.4 nicht mehr existiert).

• PHP als CGI (meistens in einer eigenen CHROOT-Umgebung, also relativ sicher)
• PHP als FastCGI (siehe vorstehendes, aber schneller. Nicht so schnell, wie als Modul)

Diese Modi allein bringen noch keine Sicherheit. Mit suEXEC kann man zumindest einen Useraccount für die Ausführung explizit zuweisen. Den Rest muss die Systemkonfiguration bringen (Berechtigungen im Dateisystem). PHP als CGI im CHROOT hab ich auch noch nicht in freier Wildbahn gesehen (soll nicht heißen, dass es das nicht geben kann).

dedlfix.

[Tom]

Hello,

Wie richtet man denn so etwas richtig ein? Wenn alle Anwendungen (meines Wissens) nur unter dem Useraccount des Apachen laufen können, sehe ich keine Möglichkeit der Absicherung (außer dem Safe Mode, der ab PHP 5.4 nicht mehr existiert).

Das ist eine Sache der PHP-Installation.
Mittels passender Einstellungen für open_basedir und der von dir schon angesprochenen Verzeichnisse für Sessions, (Logs,) Uploads, htdocs und data sollte es passen. Ich habe das bisher jedenfalls immer dicht bekommen.

• PHP als CGI (meistens in einer eigenen CHROOT-Umgebung, also relativ sicher)
• PHP als FastCGI (siehe vorstehendes, aber schneller. Nicht so schnell, wie als Modul)

Diese Modi allein bringen noch keine Sicherheit. kann man zumindest einen Useraccount für die Ausführung explizit zuweisen. Den Rest muss die Systemkonfiguration bringen (Berechtigungen im Dateisystem). PHP als CGI im CHROOT hab ich auch noch nicht in freier Wildbahn gesehen (soll nicht heißen, dass es das nicht geben kann).

Das wäre aber das Normale. Da der User i.d.R. dann keinen Konsolenzugang erhält, sondern nur FTP, gibt es auch kaum aufbohrbare Lochansätze.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Wie richtet man denn so etwas richtig ein? Wenn alle Anwendungen (meines Wissens) nur unter dem Useraccount des Apachen laufen können, sehe ich keine Möglichkeit der Absicherung (außer dem Safe Mode, der ab PHP 5.4 nicht mehr existiert).
Das ist eine Sache der PHP-Installation.
Mittels passender Einstellungen für open_basedir und der von dir schon angesprochenen Verzeichnisse für Sessions, (Logs,) Uploads, htdocs und data sollte es passen. Ich habe das bisher jedenfalls immer dicht bekommen.

Hmm, open_basedir schlägt aber vom Prinzip her in etwa die gleiche Kerbe wie der Safe Mode. Wenn man alles konsequent (und möglichst aus einer Hand) konfigurieren kann, dann mag das sicher aussehen. Aber sobald du einmal das open_basedir zu setzen vergisst, kann diejenige Applikation sich frei bewegen - wenn die Rechtevergabe nichts schlimmeres verhindert. Aber zumindest die Mithostlinge sind aufgrund derselben User-ID gefährdet.

dedlfix.

[Tom]

Hello,

Wie richtet man denn so etwas richtig ein? Wenn alle Anwendungen (meines Wissens) nur unter dem Useraccount des Apachen laufen können, sehe ich keine Möglichkeit der Absicherung (außer dem Safe Mode, der ab PHP 5.4 nicht mehr existiert).

Das ist eine Sache der PHP-Installation.

Mittels passender Einstellungen für open_basedir und der von dir schon angesprochenen Verzeichnisse für Sessions, (Logs,) Uploads, htdocs und data sollte es passen. Ich habe das bisher jedenfalls immer dicht bekommen.

Hmm, open_basedir schlägt aber vom Prinzip her in etwa die gleiche Kerbe wie der Safe Mode.

Nicht wirklich.
Open_Basedir regelt nur den Dateizugriff auf Files und Directories mittels PHP-interner Filefunktionen.

Darüberhinaus gibt es dann eben noch die Möchlichkeit, die Betriebssystemfunktionen bzw. eigentlich ja nur deren Dienstprogramme direkt aufzurufen mittels Exec() & Brüdern. Das muss man natürlich dann auch im Auge behalten oder ganz unterbinden. Wenn amn ein Jail einrichten kann, können diese Funktionen nur auf Daten zugreifen, die den User etwas angehen, sonst muss man sie mittels Verbot in
http://de3.php.net/manual/en/ini.core.php#ini.disable-functions und
http://de3.php.net/manual/en/ini.core.php#ini.disable-classes

separat ausschalten.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

also langsam geht mir das auf den Senkel. Diese vermeintliche Rechtschreibschwäche habe ich nur mit dem PC...

Wenn ich mit der Hand schreibe, dann ist alles richtig.

Darüberhinaus gibt es dann eben noch die Möchlichkeit, die ...

--

Wie heißt dieser Virus?

Das ulkige daran ist, dass dann "Rechtschreipschwäche" oder "Rächtschreibschweche" da steht und  nicht irgend ein nachvollziehbarer eindeutiger Typo...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

also langsam geht mir das auf den Senkel. Diese vermeintliche Rechtschreibschwäche habe ich nur mit dem PC...
Wie heißt dieser Virus?

Egal, als Beim-Tippen-auf-die-Tastatur-Seher kannm an dagegen soweiso ncihts machen, außer nachher auf dem Bildschirm kontrollzulesen. Dafür reicht jedoch die Zeit nicht, das nächste Posting wartet schließlich ganz dringend auf eine Antwort ...

dedlfix.

[dedlfix]

Tach!

Wenn amn ein Jail einrichten kann, können diese Funktionen nur auf Daten zugreifen, die den User etwas angehen

Wie gesagt, als Anwender muss man sich darauf verlassen, dass der Betreiber dieses Jail für alle gleichermaßen eingerichtet hat. Wenn man jedoch mit einer eigenen Kennung unterwegs ist, hat man die Sicherheit, dass die kein anderer verwendet, durch ein Passwort selbst in der Hand, ebenso diejenige der eigenen Dateien über die Berechtigungsvergaben.

dedlfix.