tom Sun Aug 5 17:46:45 2001 EDT
Modified files:
/phpdoc/de/chapters security.xml
Log:
Is now up to date with en-version 1.23
Index: phpdoc/de/chapters/security.xml
diff -u phpdoc/de/chapters/security.xml:1.8 phpdoc/de/chapters/security.xml:1.9
--- phpdoc/de/chapters/security.xml:1.8 Sat Jun 23 05:06:01 2001
+++ phpdoc/de/chapters/security.xml Sun Aug 5 17:46:45 2001
@@ -1,3 +1,4 @@
+<!-- up-to-date against phpdoc/en/chapters/security.xml:1.23 -->
<chapter id="security">
<title>Sicherheit</title>
@@ -281,16 +282,17 @@
<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 schon oft daran gehindert
- wurde, virenverseuchte Dateien in das Userverzeichnis zu schreiben. Oder
- vielleicht wurde es auch daran gehindert, auf nicht �ffentliche
- Datenbanken zuzugreifen oder diese ga zu ver�ndern. In gleicher Weise
- wird auch davor "gesch�tzt", gewollte Dateien zu schreiben oder
- Datenbanktransaktionen durchzuf�hren.
+ 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.
</simpara>
<simpara>
Ein h�ufig gemachter Fehler in Punkto Sicherheit ist Apache Root-Rechte
- zu erteilen.
+ zu erteilen, oder die M�glichkeiten von Apache in einer anderen Weise
+ auszuweiten.
</simpara>
<simpara>
Die Ausweitung der Benutzerrechte f�r Apache auf root ist sehr
@@ -298,6 +300,13 @@
chroot, oder anderw�rtig als root zu arbeiten sollte niemand anders
als den Sicherheitsprofis �berlassen werden.
</simpara>
+ <simpara>
+ Es gibt auch ein paar einfachere L�sungen. Mit
+ <function>open_basedir()</function> 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.
+ </simpara>
</sect1>
<sect1 id="security.filesystem">
@@ -333,7 +342,7 @@
<programlisting role="php">
<?php
// L�schen einer Datei aus dem Heimatverzeichnis des Users
-$username = $user_submitted_name;
+$username = $HTTP_POST_VARS['user_submitted_name'];
$homedir = "/home/$username";
$file_to_delete = "$userfile";
unlink ($homedir/$userfile);
@@ -382,15 +391,15 @@
<?php
// l�scht eine Datei von der Festplatte, auf die
// der PHP user Zugriff hat.
-$username = $HTTP_REMOTE_USER; // verwenden Sie eine Authentifizierungs-
- // Methode
+$username = $HTTP_SERVER_VARS['REMOTE_USER']; // verwendet eine
+ // Authentifizierungsmethode
$homedir = "/home/$username";
$file_to_delete = basename("$userfile"); // den Pfad entfernen
unlink ($homedir/$file_to_delete);
$fp = fopen("/home/logging/filedelete.log","+a"); //logge die L�schung
-$logstring = "$HTTP_REMOTE_USER $homedir $file_to_delete";
+$logstring = "$username $homedir $file_to_delete";
fputs ($fp, $logstring);
fclose($fp);
@@ -398,21 +407,30 @@
?>
</programlisting>
</example>
- Als Alternative ziehen Sie vielleicht eine speziellere Pr�fung vor:
+ Auch dies nicht v�llig makellos. Wenn Ihr Authentifizierungssystem
+ Benutzern erlauben sollte, deren eigene Logins zu kreieren, und ein
+ Benutzer w�hlt den Login "../etc", ist das System wieder aufgedeckt.
+ Aus diesem Grund ziehen Sie es vielleicht vor, einen besseren Check
+ zu schreiben:
<example>
<title>Sicherere Dateinamenspr�fung</title>
<programlisting role="php">
<?php
-$username = getenv("REMOTE_USER");
+$username = $HTTP_SERVER_VARS['REMOTE_USER']; // verwendet eine
+ // Authentifizierungsmethode
$homedir = "/home/$username";
if (!ereg('^[^./][^/]*$', $userfile))
die('bad filename'); // "DIE", gehen Sie nicht weiter
-
+
+if (!ereg('^[^./][^/]*$', $username))
+ die('bad username'); // "DIE", gehen Sie nicht weiter
//etc...
?>
</programlisting>
</example>
+ </para>
+ <para>
Abh�ngig vom Betriebssystem gibt es eine gro�e Anzahl Dateien mit der
Sie sich befassen sollten, inklusive Eintr�ge f�r Ger�te (/dev/ oder
com1), Konfigurationsdateien (/etc/ Dateien und die .ini Dateien), gut
@@ -424,13 +442,29 @@
<sect1 id="security.errors">
<title>Fehlerbehandlung</title>
- <simpara>
+ <para>
+ PHP Security hat zwei Seiten der Fehlerbehandlung. Eine ist f�r die
+ Erh�hung der Sicherheit vorteilhaft, die andere ist sch�dlich.
+ </para>
+ <para>
Eine Standard-Angriffstaktik beinhaltet die Erstellung eines Profils
des anzugreifenden Systems, indem die aufgrund der Einspeisung von
unzul�ssigen Daten zur�ckgegebenen Fehlermeldungen anhand deren
- Art und des Kontextes ausgewertet werden.
- </simpara>
- <simpara>
+ Art und des Kontextes ausgewertet werden. Wenn z.B. ein Angreifer
+ Informationen �ber eine auf einem eingesendeten Formular basierte
+ Seite zusammengetragen hat, kann er versuchen, Variablen zu
+ �berschreiben bzw. zu modifizieren:
+ <example>
+ <title>Angreifervariablen mit einer eigenen HTML Seite</title>
+ <programlisting role="php">
+<form method="post" action="attacktarget?username=badfoo&password=badfoo">
+<input type="hidden" name="username" value="badfoo">
+<input type="hidden" name="password" value="badfoo">
+</form>
+ </programlisting>
+ </example>
+ </para>
+ <para>
Die normalerweise zur�ckgegebenen PHP Fehler k�nnen f�r den Entwickler
hilfreich sein, wenn dieser ein Skript debuggen m�chte, Hinweise auf
eine nicht korrekt arbeitende Funktion oder Datei, oder die PHP Datei
@@ -441,16 +475,37 @@
<function>highlight_file</function> zur Fehlersuche zu verwenden,
jedoch kann dies in einem lebenden System auch versteckte Variablen,
ungepr�fte Syntax und andere gef�hrliche Informationen aufdecken.
- </simpara>
- <simpara>
+ Speziell gef�hrlich ist es, Code von bekannten Quellen mit integrierten
+ Debugging Handlern auszuf�hren, oder weit verbreitete Debuggingtechniken
+ zu verwenden. Wenn ein Angreifer die von Ihnen benutzte generelle
+ Technik herausfindet, kann er versuchen, mit Brute-Force Ihre Seite zu
+ knacken, indem er verschiedene allgemein gebr�uchliche Debug Strings
+ sendet:
+ <example>
+ <title>Ausnutzen von gebr�uchlichen Debugging Variablen</title>
+ <programlisting role="php">
+<form method="post"
+action="attacktarget?errors=Y&showerrors=1"&debug=1">
+<input type="hidden" name="errors" value="Y">
+<input type="hidden" name="showerrors" value="1">
+<input type="hidden" name="debug" value="1">
+</form>
+ </programlisting>
+ </example>
+ </para>
+ <para>
+ Ungeachtet der Fehlerbehandlungsmethode f�hrt die M�glichkeit ein
+ System nach Fehlermeldungen sondieren dazu, dass einem Angreifer mehr
+ Informationen geboten werden.
+ </para>
+ <para>
Zum Beispiel weist schon alleine der Stil einer Fehlermeldung darauf
hin, dass auf einem System PHP l�uft. Wenn der Angreifer auf eine
.html Seite kommt und untersuchen m�chte welches System im Hintergrund
l�uft (um nach bekannten Systemschw�chen zu suchen), k�nnte dieser
mittels der Einspeisung von falschen Daten herausfinden, dass ein
System mit PHP aufgebaut ist.
- </simpara>
- <simpara>
+ </para>
+ <para>
Ein Fehler einer Funktion gibt Aufschluss dar�ber, ob ein System eine
bestimmte Datenbankapplikation benutzt, oder gibt Hinweise darauf,
wie eine Webseite programmiert bzw. entworfen wurde. Dies erlaubt
@@ -460,15 +515,15 @@
der Authentifizierung in einem Skript bestimmen (anhand der
Zeilennummern in den Fehlermeldungen), wie auch durch "Herumstochern"
Missbrauchsm�glichkeiten an verschiedenen Stellen im Script herausfinden.
- </simpara>
- <simpara>
+ </para>
+ <para>
Eine Fehlermeldung des Dateisystems oder eines generellen PHP-Errors
welche Rechte der Server hat, wie auch die Struktur und Organisation
der Dateien auf dem Webserver. Vom Entwickler geschriebene
Fehlermeldungen k�nnen das Problem verschlimmern, bis hin zum Preisgeben
von zuvor "versteckten" Informationen.
- </simpara>
- <simpara>
+ </para>
+ <para>
Es gibt drei bedeutende L�sungen zu diesem Thema. Die erste ist, alle
Funktionen zu �berpr�fen und zu versuchen, die Menge an Fehlermeldungen
zu ersetzen. Die zweite ist, die Ausgabe von Fehlermeldungen am laufenden
@@ -476,9 +531,104 @@
PHP Funktionen zur Fehlerbehandlung seinen eigenen Error-handler zu
schreiben. Abh�ngig von Ihrer Sicherheitspolitik k�nnte jede der drei
L�sungen f�r Sie geeignet sein.
- </simpara>
+ </para>
+ <para>
+ Ein Weg, diesen Punkt vorzeitig zu behandeln ist, das PHP eigene
+ <function>error_reporting</function> zu benutzen, um Ihren Code
+ sicherer zu gestalten und m�glicherweise gef�hrliche Nutzungen von
+ Variablen zu entdecken. Wenn Sie Ihren Code noch vor dem Einsatz
+ mit E_ALL testen, k�nnen Bereiche entdecken, in denen Ihre Variablen
+ eventuell f�r Verseuchung oder andere Modifikationen offen sind.
+ Sind Sie bereit zum Einsatz, k�nnen Sie Ihren Code mit E_NONE vor
+ Sondierungen sch�tzen.
+ <example>
+ <title>Gef�hrliche Variablen mit E_ALL finden</title>
+ <programlisting role="php">
+<?php
+if ($username) { // Vor Verwendung nicht initialisiert oder gepr�ft
+ $good_login = 1;
+}
+if ($good_login == 1) { // Wenn der obige Test fehlschl�gt, ist vor der
+ // Verwendung nicht initialisiert oder gepr�ft
+ fpassthru ("/highly/sensitive/data/index.html");
+}
+?>
+ </programlisting>
+ </example>
+ </para>
</sect1>
+ <sect1 id="security.registerglobals">
+ <title>Verwendung von Register Globals</title>
+ <para>
+ Ein Feature von PHP zur Erh�hung der Sicherheit ist die Konfiguration
+ von PHP mit register_globals = off. Mit Deaktivierung der M�glichkeit,
+ irgendeine vom Benutzer �bertragenen Variable in den PHP Code zu
+ injizieren, k�nnen Sie die Anzahl "vergifteter" Variablen reduzieren,
+ welche ein potentieller Angreifer zuf�gen k�nnte. Dieser ben�tigt mehr
+ Zeit, um sich �bermittlungen auszudenken, und Ihre internen Variablen
+ sind effektiv von den �bergebenen Benutzervariablen isoliert.
+ </para>
+ <para>
+ W�hrend dies den ben�tigten Aufwand mit PHP zu arbeiten leicht erh�ht
+ ist dargelegt, dass die Vorteile gegen�ber dem Aufwand klar �berwiegen.
+ <example>
+ <title>Ohne register_globals=off arbeiten</title>
+ <programlisting role="php">
+<?php
+if ($username) { // kann vom User mit get/post/cookies �bermittelt werden
+ $good_login = 1;
+}
+
+if ($good_login == 1) { // kann vom User mit get/post/cookies �bermittelt werden
+ fpassthru ("/highly/sensitive/data/index.html");
+}
+?>
+ </programlisting>
+ </example>
+ <example>
+ <title>Mit register_globals = off arbeiten</title>
+ <programlisting role="php">
+<?php
+if($HTTP_COOKIE_VARS['username']){
+ // kann nur von einem Cookie kommen
+ $good_login = 1;
+ fpassthru ("/highly/sensitive/data/index.html");
+}
+?>
+ </programlisting>
+ </example>
+ Dies weise genutzt ist es auch m�glich, pr�ventive Messungen
+ durchzuf�hren, um bei versuchten Vorst��en zu warnen. Wenn Sie
+ im Voraus wissen, woher eine Variable kommen soll, k�nnen Sie
+ pr�fen, ob die �bermittelten Daten nicht einen unpassenden Weg
+ genommen haben. Obwohl dies nicht garantiert, dass Daten nicht
+ nur ausgedacht sind, erfordert es von einem Angreifer, auch den
+ richtigen Weg zu finden.
+ <example>
+ <title>Entdecken einfacher Manipulationen von Variablen</title>
+ <programlisting role="php">
+<?php
+if ($HTTP_COOKIE_VARS['username'] &&
+ !$HTTP_POST_VARS['username'] &&
+ !$HTTP_GET_VARS['username'] ) {
+ // Durchf�hren anderer Checks, ob der Benutzername g�ltig ist...
+ $good_login = 1;
+ fpassthru ("/highly/sensitive/data/index.html");
+} else {
+ mail("[EMAIL PROTECTED]", "Possible breakin attempt",
+$HTTP_SERVER_VARS['REMOTE_ADDR']);
+ echo "Security violation, admin has been alerted.";
+ exit;
+}
+?>
+ </programlisting>
+ </example>
+ Nat�rlich hei�t ein einfaches Aktivieren von register globals nicht,
+ dass Ihr Code nun automatisch sicher ist. Jeder Teil mit Daten sollte
+ auch auf andere Arten gepr�ft werden.
+ </para>
+ </sect1>
+
<sect1 id="security.variables">
<title>Vom Nutzer �bermittelte Daten</title>
<para>
@@ -496,7 +646,8 @@
// oder vielleicht dem eines anderen Benutzers?
unlink ($evil_var);
-// Schreibe die Log-Information von deren Zugriff... oder vielleicht nicht?
+// Schreibe die Log-Information von deren Zugriff...
+// oder vielleicht einen /etc/password Eintrag?
fputs ($fp, $evil_var);
// F�hre etwas triviales aus... oder rm -rf *?
@@ -551,6 +702,51 @@
zu arbeiten kann auch helfen, Sie vor Variablen zu warnen, welche
benutzt werden, bevor sie gepr�ft oder initialisiert wurden (so k�nnen
Sie verhindern, dass mit ungew�hnlichen Daten gearbeitet wird).
+ </para>
+ </sect1>
+
+ <sect1 id="security.hiding">
+ <title>Verstecken von PHP</title>
+ <para>
+ Ein paar einfache Techniken helfen PHP zu Verstecken, um einen nach
+ Schw�chen in Ihrem System suchenden Angreifer m�glicherweise langsamer
+ Wenn Sie in Ihrer php.ini expose_php = off zu machen. setzen,
+ reduzieren Sie damit die ihm 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 konfigurieren, dass dieser verschiedene Dateitypen durch PHP parst.
+ So k�nnen Sie irref�hrende Dateierweiterungen verwenden:
+ <example>
+ <title>PHP als andere Sprache ausgeben</title>
+ <programlisting role="php">
+# Lasse PHP Code wie andere Arten von Code aussehen
+AddType application/x-httpd-php .asp .py .pl
+ </programlisting>
+ </example>
+ Oder komplett unklar machen:
+ <example>
+ <title>Verwenden von unbekannten Typen f�r PHP Dateierweiterungen</title>
+ <programlisting role="php">
+# Lasse PHP Code wie unbekannte Typen aussehen
+AddType application/x-httpd-php .bop .foo .133t
+ </programlisting>
+ </example>
+ Oder verstecken Sie ihn als html Code, was einen leichten
+ Performanceverlust bedeutet, da alle html Dateien durch die PHP
+ Engine geparst werden:
+ <example>
+ <title>Verwenden von html Typen f�r PHP Dateierweiterungen</title>
+ <programlisting role="php">
+# Lasse PHP code wie html aussehen
+AddType application/x-httpd-php .htm .html
+ </programlisting>
+ </example>
+ Um dies effektiv arbeiten zu lassen, m�ssen Sie Ihre PHP Dateien
+ nach den obigen Dateierweiterungen umbenennen. W�hrend dies eine
+ Form der Sicherheit durch Verh�llung ist, ist es ein kleines
+ pr�ventives Ma� mit ein paar Nachteilen.
</para>
</sect1>
