cvs: phpdoc-de /security apache.xml

sammywg Tue Nov 27 02:06:44 2007 UTC Modified files: /phpdoc-de/security apache.xml Log: sync to en http://cvs.php.net/viewvc.cgi/phpdoc-de/security/apache.xml?r1=1.2&r2=1.3&diff_format=u Index: phpdoc-de/security/apache.xml diff -u phpdoc-de/security/apache.xml:1.2 phpdoc-de/security/apache.xml:1.3 --- phpdoc-de/security/apache.xml:1.2 Sat Jun 23 13:21:53 2007 +++ phpdoc-de/security/apache.xml Tue Nov 27 02:06:43 2007 @@ -1,51 +1,49 @@ <?xml version="1.0" encoding="iso-8859-1"?> -<!-- $Revision: 1.2 $ --> -<!-- EN-Revision: 1.2 Maintainer: tom Status: ready --> +<!-- $Revision: 1.3 $ --> +<!-- EN-Revision: 1.4 Maintainer: sammywg Status: ready --> <chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook"> - <title>Apache-Modul</title> + <title>Verwendung als Apache-Modul</title> <simpara> Wenn PHP als Apache-Modul eingesetzt wird, übernimmt es die - Benutzerrechte des Apache (üblicherweise user "nobody"). Das hat - verschiedene Auswirkungen auf Sicherheit und Authentifizierung, z.B.: - Wenn Sie PHP zum Zugriff auf eine Datenbank benutzen, es sei denn - diese Datenbank hat eine integrierte Zugriffskontrolle, müssen Sie - dem Benutzer "nobody" Zugriffsrechte auf die Datenbank erteilen. Das - heißt, dass ein böswilliges Skript auch Benutzerkennung und Passwort - auf die Datenbank zugreifen, und sie verändern könnte. Es ist durchaus + Benutzerrechte des Apache (üblicherweise die des Users "nobody"). Das hat + verschiedene Auswirkungen auf Sicherheit und Authentifizierung. Wenn Sie + beispielsweise via PHP auf eine Datenbank zugreifen, müssen Sie + dem Benutzer "nobody" Zugriffsrechte auf die Datenbank erteilen, es sei denn, + diese Datenbank hat eine integrierte Zugriffskontrolle. Das + heißt, dass ein böswilliges Skript auch ohne Benutzerkennung und + Passwort auf die Datenbank zugreifen und sie verändern könnte. Es ist durchaus möglich, dass ein Web-Spider über die Webseite eines - Datenbankadministrators stolpert, und alle Ihre Datenbanken löscht. - Sie können sich dagegen mit Apache Authentifizierung schützen, oder - ein eigenes Zugangsmodell unter Verwendung von LDAP, .htaccess Dateien, - etc. entwerfen, und diesen Code als Teil Ihrer PHP Skripte einbinden. + Datenbankadministrators stolpert und alle Ihre Datenbanken löscht. + Sie können sich dagegen mit Apache-Authentifizierung schützen, oder + ein eigenes Zugangsmodell unter Verwendung von LDAP, .htaccess Dateien + etc. entwerfen, und diesen Code als Teil Ihrer PHP-Skripte einbinden. </simpara> <simpara> - Es wurde festgestellt, dass wenn einmal die Sicherheitsmaßnahmen so - weit eingerichtet sind dass dem PHP User (in diesem Fall ein Apache - User) nur mehr ein geringes Risiko bleibt, PHP daran gehindert wird, - virenverseuchte Dateien in das Benutzerverzeichnis zu schreiben. Oder - vielleicht wurde es auch daran gehindert, auf Datenbanken zuzugreifen - oder diese gar zu verändern. In gleicher Weise wird auch davor - abgehalten, "gute" oder "bösartige" Dateien zu schreiben, oder "gute" - bzw. "bösartige" Datenbanktransaktionen durchzuführen. + Ist erst einmal eine Sicherheitsstruktur bis zu dem Punkt eingerichtet, an + dem der PHP-User (in diesem Falle der Apache-User) nur noch ein geringes + Risiko darstellt, hat man meist die Situation, dass PHP gehindert wird, + beliebige Dateien in das Benutzerverzeichnis zu schreiben. Oder PHP ist + nicht mehr in der Lage, auf Datenbanken lesend oder verändernd zuzugreifen. + In gleicher Weise wird auch verhindert, "gute" oder "bösartige" Dateien zu + schreiben, oder "gute" bzw. "bösartige" Datenbanktransaktionen durchzuführen. </simpara> <simpara> - Ein häufig gemachter Fehler in Punkto Sicherheit ist Apache Root-Rechte - zu erteilen, oder die Möglichkeiten von Apache in einer anderen Weise - auszuweiten. + Ein häufig gemachter Fehler in Punkto Sicherheit ist, Apache Rootrechte + zu erteilen oder die Möglichkeiten von Apache in anderer Weise auszuweiten. </simpara> <simpara> - Die Ausweitung der Benutzerrechte für Apache auf root ist sehr - gefährlich, und kann dem gesamten System schaden, denn mit sudo, - chroot, oder anderwärtig als root zu arbeiten sollte niemand anders - als den Sicherheitsprofis überlassen werden. + Die Ausweitung der Benutzerrechte für Apache auf root ist extrem + gefährlich und kann das gesamte System kompromittieren, daher sollten + Prozesse, die wie sudo oder chroot mit Rootrechten arbeiten, niemandem + zugänglich sein, der kein Sicherheitsprofi ist. </simpara> <simpara> Es gibt auch ein paar einfachere Lösungen. Mit - <link linkend="ini.open-basedir">open_basedir()</link> können Sie + <link linkend="ini.open-basedir">open_basedir</link> können Sie kontrollieren, welche Verzeichnisse PHP benutzen darf oder nicht. Sie können auch einen Bereich nur für Apache einrichten, um alle - webbasierten Aktivitäten auf nicht-Benutzer- bzw. nicht-System-Dateien - einzuschränken. + webbasierten Aktivitäten auf dem System oder nicht dem Benutzer gehörende + Dateien zu verhindern. </simpara> </chapter>