svn: /phpdoc/de/trunk/security/ apache.xml hiding.xml

sammywg                                  Fri, 14 May 2010 13:38:17 +0000

Revision: http://svn.php.net/viewvc?view=revision&revision=299380

Log:
sync with en

Changed paths:
    U   phpdoc/de/trunk/security/apache.xml
    U   phpdoc/de/trunk/security/hiding.xml

Modified: phpdoc/de/trunk/security/apache.xml
===================================================================
--- phpdoc/de/trunk/security/apache.xml	2010-05-14 13:32:27 UTC (rev 299379)
+++ phpdoc/de/trunk/security/apache.xml	2010-05-14 13:38:17 UTC (rev 299380)
@@ -1,36 +1,37 @@
 <?xml version="1.0" encoding="utf-8"?>
 <!-- $Revision$ -->
-<!-- EN-Revision: 297028 Maintainer: sammywg Status: ready -->
+<!-- EN-Revision: 297645 Maintainer: sammywg Status: ready -->

  <chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook">
    <title>Verwendung als Apache-Modul</title>
    <simpara>
-    Wenn PHP 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
+    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 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
+    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
+    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.
+    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 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 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.
+    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
+    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>
@@ -43,13 +44,14 @@
    <simpara>
     Es gibt deutlich einfachere Lösungen. Mit
     <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
+    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
@@ -70,4 +72,3 @@
 vim: et tw=78 syn=sgml
 vi: ts=1 sw=1
 -->
-

Modified: phpdoc/de/trunk/security/hiding.xml
===================================================================
--- phpdoc/de/trunk/security/hiding.xml	2010-05-14 13:32:27 UTC (rev 299379)
+++ phpdoc/de/trunk/security/hiding.xml	2010-05-14 13:38:17 UTC (rev 299380)
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="utf-8"?>
 <!-- $Revision$ -->
-<!-- EN-Revision: 297028 Maintainer: sammywg Status: ready -->
+<!-- EN-Revision: 297645 Maintainer: sammywg Status: ready -->
 <chapter xml:id="security.hiding" xmlns="http://docbook.org/ns/docbook">
 <title>PHP verstecken</title>
  <para>
@@ -9,16 +9,17 @@
   Sicherheit wünschenswert.
  </para>
  <para>
-  Ein paar einfache Techniken helfen, PHP zu verstecken, um nach
-  Schwächen in Ihrem System suchende Angreifer unter Umständen langsamer
+  Ein paar einfache Techniken helfen, <acronym>PHP</acronym> zu verstecken, um
+  nach Schwächen in Ihrem System suchende Angreifer unter Umständen langsamer
   zu machen. Wenn Sie in Ihrer &php.ini; expose_php auf <literal>off</literal>
   setzen, reduzieren Sie damit die zur Verfügung stehenden Informationen.
  </para>
  <para>
   Eine andere Taktik ist, den Webserver wie z.B. Apache entweder mittels
   einer &htaccess;-Direktive oder in der Apache-Konfigurationsdatei selbst
-  so einzustellen, dass dieser verschiedene Dateitypen durch PHP parst.
-  So können Sie irreführende Dateierweiterungen verwenden:
+  so einzustellen, dass dieser verschiedene Dateitypen durch
+  <acronym>PHP</acronym> parst. So können Sie irreführende Dateierweiterungen
+  verwenden:
   <example>
    <title>PHP als andere Sprache ausgeben</title>
    <programlisting role="apache-conf">
@@ -38,11 +39,12 @@
 ]]>
    </programlisting>
   </example>
-  Oder verstecken Sie ihn als HTML-Code, was einen leichten
-  Performanceverlust bedeutet, da so alle HTML-Dateien durch die PHP-Engine
-  geparst werden:
+  Oder verstecken Sie ihn als <acronym>HTML</acronym>-Code, was einen leichten
+  Performanceverlust bedeutet, da so alle <acronym>HTML</acronym>-Dateien durch
+  die <acronym>PHP</acronym>-Engine geparst werden:
   <example>
-   <title>Verwenden von HTML-Typen für PHP-Dateierweiterungen</title>
+   <title>Verwenden von <acronym>HTML</acronym>-Typen für
+    PHP-Dateierweiterungen</title>
    <programlisting role="apache-conf">
 <![CDATA[
 # Lasse PHP-Code wie HTML aussehen
@@ -50,10 +52,10 @@
 ]]>
    </programlisting>
   </example>
-  Um dies effektiv arbeiten zu lassen, müssen Sie Ihre PHP-Dateien
-  nach den obigen Dateierweiterungen umbenennen. Obwohl dies eine
-  Form der Sicherheit durch Verhüllung ist, ist es eine geringfügige
-  präventive Maßnahme mit nur wenigen Nachteilen.
+  Um dies effektiv arbeiten zu lassen, müssen Sie Ihre
+  <acronym>PHP</acronym>-Dateien nach den obigen Dateierweiterungen umbenennen.
+  Obwohl dies eine Form der Sicherheit durch Verhüllung ist, ist es eine
+  geringfügige präventive Maßnahme mit nur wenigen Nachteilen.
  </para>
 </chapter>