apache.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<!-- EN-Revision: ab6785b01ce1006e3a9761988575289f40c9b678 Maintainer: sammywg Status: ready -->

 <chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook">
   <title>Verwendung als Apache-Modul</title>
   <simpara>
    Wenn <acronym>PHP</acronym> als Apache-Modul eingesetzt wird, übernimmt es
    die Benutzerrechte des Apache (üblicherweise die des Users "nobody"). Das
    hat verschiedene Auswirkungen auf Sicherheit und Authentifizierung. Wenn Sie
    beispielsweise via <acronym>PHP</acronym> 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
    <acronym>PHP</acronym>-Skripte einbinden.
   </simpara>
   <simpara>
    Ist erst einmal eine Sicherheitsstruktur bis zu dem Punkt eingerichtet, an
    dem der <acronym>PHP</acronym>-User (in diesem Falle der Apache-User) nur
    noch ein geringes Risiko darstellt, hat man meist die Situation, dass
    <acronym>PHP</acronym> gehindert wird, beliebige Dateien in das
    Benutzerverzeichnis zu schreiben. Oder vielleicht ist PHP dann 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 an diesem Punkt oft geöffnetes Sicherheitsloch ist die Zuweisung von
    Root-Rechten an den Apache-Prozess oder die Ausweitung der Rechte des Apache
    auf anderem Wege.
   </simpara>
   <simpara>
    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 deutlich einfachere Lösungen. Mit
    <link linkend="ini.open-basedir">open_basedir</link> können Sie
    kontrollieren, welche Verzeichnisse <acronym>PHP</acronym> benutzen darf
    oder nicht. Sie können auch einen Bereich nur für Apache einrichten, um alle
    webbasierten Aktivitäten auf dem System oder nicht dem Benutzer gehörende
    Dateien zu verhindern.
   </simpara>
  </chapter>


<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->