Häufige Unsicherheit bei der Einrichtung von PHP?

10

Ich arbeite mit der Systemadministration an einer Universität und bin nur auf etwas gestoßen, was wahrscheinlich üblich ist, aber für mich ein ziemlicher Schock war.

Alle public_html-Verzeichnisse und Webbereiche werden auf afs mit Leseberechtigungen für die Webserver gespeichert. Da Benutzer PHP-Skripte in ihrer public_html haben dürfen, bedeutet dies, dass sie über PHP (und die wichtigsten Webdateien!) Auf die Dateien der anderen zugreifen können.

Dies macht nicht nur jeden .htaccess-Passwortschutz völlig unbrauchbar, sondern ermöglicht es Benutzern auch, PHP-Quelldateien zu lesen, die MySQL-Datenbankkennwörter und ähnliche vertrauliche Informationen enthalten. Oder wenn sie feststellen, dass andere Personen Verzeichnisse haben, in denen die Webserver Schreibzugriff haben (z. B. für persönliche Protokolle oder zum Speichern übermittelter Formulardaten), können sie Dateien in diesen Konten speichern.

Ein einfaches Beispiel:

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

Ist das ein häufiges Problem? Und wie löst man das normalerweise?

AKTUALISIEREN:

Danke für die Eingabe. Leider scheint es keine einfache Antwort zu geben. In einer großen gemeinsamen Umgebung wie dieser sollten Benutzer wahrscheinlich nicht so viel Auswahl haben. Der beste Ansatz, den ich mir vorstellen kann, ist, "open_basedir" in der Hauptkonfiguration für alle "public_html" -Verzeichnisse festzulegen, suphp auszuführen und nur sauberes PHP zuzulassen (keine CGI-Skripte, externe Befehle mit Backticks usw. ausführen).

Eine solche Änderung der Richtlinie würde jedoch eine Menge Probleme verursachen und möglicherweise dazu führen, dass Benutzer ihre Mistgabeln greifen und uns verfolgen ... Ich werde dies mit meinen Kollegen besprechen und hier aktualisieren, wenn wir eine Entscheidung über die Änderung des Setups treffen.

apache-2.2 security php

— Pontus
quelle

Dies ist eine interessante Frage. Ich bin mir sicher, dass dies bei großen Shared-Hosting-Anbietern (z. B. DreamHost) nicht möglich ist. Aber es würde mich interessieren, wie sie sich davor schützen. suphp scheint, wie cstamas erwähnte, eine gute lösung zu sein, aber ist es das, was die meisten hosting-anbieter verwenden?

— Lèse Majesté

1

Ich habe die open_basedirunten stehende Lösung auf gemeinsam genutzten Produktionshosting-Systemen verwendet, aber wir haben alle in ihren eigenen vhost aufgeteilt - Ich bin mir nicht sicher, ob es für einzelne Verzeichnisse funktioniert ...

— voretaq7

8

Man kann suphp verwenden, das das PHP-Skript mit der UID seines Besitzers ausführt.

http://www.suphp.org

— cstamas
quelle

Dies wird das oben genannte Problem wahrscheinlich nicht lösen (zumindest in einer gemeinsam genutzten Hosting-Umgebung .htpasswd-Dateien gehören normalerweise dem Benutzer, dem die Site und die Gruppe (Apache) oder die Welt (weil Benutzer die Sicherheit nicht kennen / sich nicht um sie kümmern). Selbst mit suphp könnten sie diese Dateien lesen.)

— voretaq7

@ voretaq7: Es können verschiedene andere Einschränkungen angewendet werden. Soweit ich mich erinnere, können Sie sogar den Zugriff auf Dateien verweigern, die Sie nicht besitzen. Dies schließt also den obigen Angriff aus.

— Cstamas

Ich weiß, dass Sie Berechtigungen für Dateien einschränken können ("Kann nicht von Gruppe / Anderen / irgendjemandem geschrieben werden"), aber ich kenne keine Möglichkeit, Lesevorgänge über FS-Berechtigungen hinaus zu blockieren. Sie haben check_vhost_docroot, aber AFAIK, die nur für das Skript gilt, das ausgeführt wird (? Ich könnte mich darin irren)

— voretaq7

1

Ich bin mir nicht sicher, ob suphp in einer solchen Umgebung eine gute Lösung ist. Ein Benutzer verfügt möglicherweise über alle Arten von Berechtigungen, über die der WWW-Benutzer nicht verfügt. Ein Angreifer, der einen Weg durch PHP gefunden hat, kann SSH-Schlüssel oder Keytabs finden oder die Anmeldeskripte eines Benutzers ändern, um Hintertüren zu erstellen. Und die Einstellungen für "vhosts" sind nicht besonders hilfreich, da die Verzeichnisse public_html über "/ ~ Benutzername" auf dem virtuellen Haupthost verfügbar sind. Ich denke, vielleicht sollten Skripte in public_html vollständig deaktiviert werden.

— Pontus

4

Mein Vorschlag wäre, den Zugriff von PHP auf Dateien zu beschränken (über open_basedir& ähnliche Anweisungen, pro Host): Sie möchten, dass Benutzer Dateien unter ihrer Webroot öffnen / lesen / schreiben können und möglicherweise eine Ebene darüber (für Scratch) Leerzeichen), aber kein Verzeichnis, in dem sie z htpasswd. B. Dateien speichern würden .

Eine Verzeichnisstruktur wie:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Würde diese Anforderung erfüllen: open_basedirkönnte /Client/sitesicher gezeigt und htpasswdDateien gespeichert werden /Client/auth(mit .htaccessDateien oder httpd.confgeändert, um stattdessen auf den entsprechenden Ort zu zeigen).
Dies verhindert, dass Ihre Kunden die Dateien anderer öffnen, UND als Vorteil können böswillige Benutzer das Material nicht einlesen /Client/auth(oder irgendetwas anderes auf Ihrem System, wie /etc/passwd:-)

Weitere Informationen zur Implementierung von open_basedir & per-vhost finden Sie unter http://php.net/manual/en/ini.core.php .

— voretaq7
quelle

1

suphpWie von cstamas festgestellt, ist dies auch in einer Shared-Hosting-Umgebung eine wirklich gute Idee. Die Einrichtung ist mit einem geringen Aufwand verbunden, aber ich würde sagen, dass sich der Sicherheitsgewinn absolut lohnt. Wenn Sie nicht alle Ihre PHP-Sites in einem FreeBSD-Gefängnis oder einer dedizierten virtuellen Maschine sandboxen, ist dies einer der größten Sicherheitsgewinne.

— voretaq7

"open_basedir" scheint eine einfache Möglichkeit zu sein, die wichtigsten Webdateien von den Benutzerdateien zu trennen, vorausgesetzt, "public_html" wird über einen eigenen virtuellen Host bereitgestellt. Die Benutzer werden jedoch nicht voreinander geschützt, da sie keine eigenen virtuellen Hosts haben. Richtig?

— Pontus

Ich habe nicht versucht, open_basedirinnerhalb einer <Directory> -Direktive zu setzen, aber ich denke, es sollte zulässig sein ("try it and see" - das Schlimmste, was es tun kann, ist, nicht zu funktionieren :)

— voretaq7

1

Bisher sieht es so aus, als ob open_basedir von den meisten kommerziellen Webhosts verwendet wird (normalerweise haben Abonnenten ihre eigenen kostenpflichtigen Domains oder erhalten eine kostenlose Subdomain), aber für verzeichnisbasierte Homepages wie in einer akademischen Einrichtung scheint suphp die beste Antwort zu sein.

— Lèse Majesté

1

Nein, dies ist kein häufiges Problem, da die meisten freigegebenen Hosts eine open_basedir-Konfiguration in der htaccess-Datei im Verzeichnis public_html jedes Benutzers definieren (oder im vhost, wenn jeder Benutzer seinen eigenen vhost hat).

zB der .htaccess-Datei:

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

Stellen Sie jedoch sicher, dass Sie die richtigen Berechtigungen für die .htaccess-Datei festlegen, um zu verhindern, dass der Benutzer das open_basedir ändert (wenn er versucht, es in subdir / .htaccess zu überschreiben, sollte es nicht funktionieren - aber Sie sollten dies wahrscheinlich testen, um sicherzustellen). .

HTH

C.

— symcbean
quelle

2

Dies kann dazu beitragen, einen ersten Schutz für neue Konten zu bieten. Die Tatsache, dass ein Benutzer es nicht bearbeiten kann, kann jedoch verlockend sein, die .htaccess-Datei zu entfernen (was er tun kann, da nur Schreibzugriff auf das Verzeichnis public_html erforderlich ist) und eine eigene zu erstellen. Das Hinzufügen eines "<Directory>" - Blocks in der Hauptkonfiguration für jeden Benutzer würde funktionieren, aber hier dürfen sie weiterhin externe Befehle von PHP zurückticken, was bedeutet, dass open_basedir leicht umgangen werden kann.

— Pontus

@ Pontus: Guter Punkt zum Löschen der Datei (ich bin nicht sicher, ob afs das unveränderliche Dateiattribut unterstützt). Ich hätte +1 gegeben, wenn Sie gesagt hätten, dass das Ausführen des Webservers im Chroot-Gefängnis vor allen Arten von Sicherheitslücken bei der Programmausführung schützen würde.

— Symcbean

1

AFS ignoriert einfache Unix-Benutzerberechtigungen. suPHP führt eine Setuid aus, bevor das PHP-Programm ausgeführt wird. Dadurch erhält der Prozess jedoch nicht die Kerberos-Token, die für den Zugriff auf AFS erforderlich sind, und ist auf seine Berechtigungen beschränkt. suPHP müsste auf irgendeine Weise modifiziert werden, um diese Token zu erhalten, bevor es sich dem AFS-System als dieser Benutzer präsentieren könnte. Soweit ich weiß, wurde dies nicht getan. (Tatsächlich fand ich diese Frage, als ich nachschaute, ob jemand anderes dies getan hatte.)

— Charles B.
quelle