archived-doc-de/security/errors.xml

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

  <chapter xml:id="security.errors" xmlns="http://docbook.org/ns/docbook">
   <title>Fehlerbehandlung</title>
   <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. Dies erlaubt es einem Angreifer,
    nach Informationen über den Server zu suchen, um seine potentielle
    Verwundbarkeit herauszufinden. 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>Variablen mit einer eigenen HTML-Seite angreifen</title>
     <programlisting role="html">
<![CDATA[
<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, da sie z.B. Hinweise
    auf eine nicht vorhandene Funktion oder Datei, die PHP-Datei und die
    Zeilennummer des auftretenden Fehlers ausgeben. Dies alles sind
    Informationen, die ausgenutzt werden können. Es ist für
    einen PHP-Entwickler nicht unüblich, <function>show_source</function>,
    <function>highlight_string</function> oder
    <function>highlight_file</function> zur Fehlersuche zu verwenden,
    jedoch kann dies in einem produktiven System auch versteckte Variablen,
    ungeprüfte Syntax und andere gefährliche Informationen aufdecken.
    Besonders gefährlich ist es, Code aus 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, Ihre Seite mittels Bruteforce zu
    knacken, indem er verschiedene allgemein gebräuchliche Debugstrings
    sendet:
    <example>
     <title>Ausnutzen von gebräuchlichen Debugging-Variablen</title>
     <programlisting role="html">
<![CDATA[
<form method="post" action="attacktarget?errors=Y&amp;showerrors=1&amp;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 zu sondieren, dazu, dass einem Angreifer mehr
    Informationen geboten werden.
   </para>
   <para>
    Zum Beispiel weist schon alleine der Stil einer Standardfehlermeldung darauf
    hin, dass auf einem System PHP läuft. Wenn der Angreifer auf eine
    <literal>.html</literal> Seite kommt und untersuchen möchte, welches System im Hintergrund
    läuft (um nach bekannten Systemschwächen Ausschau zu halten), könnte dieser
    mittels der Einspeisung von falschen Daten herausfinden, dass ein
    System mit PHP aufgebaut ist.
   </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
    eine tiefere Überprüfung von offenen Datenbankports oder die Suche
    nach spezifischen Bugs bzw. Schwächen einer Webseite. Mit der
    Einspeisung von falschen Daten kann ein Angreifer z.B. die Reihenfolge
    der Authentifizierung in einem Skript bestimmen (anhand der
    Zeilennummern in den Fehlermeldungen). Ebenso lassen sich auch durch
    "Herumstochern" Missbrauchsmöglichkeiten an verschiedenen Stellen im Skript
    herausfinden.
   </para>
   <para>
    Eine Fehlermeldung des Dateisystems oder eines generellen PHP-Errors kann
    darüber Auskunft geben, welche Rechte der Webserver hat, ebenso darüber, wie
    die Dateien auf dem Webserver strukturiert und organisiert sind. Vom
    Entwickler geschriebene Fehlermeldungen können das Problem verschlimmern,
    bis hin zum Preisgeben von zuvor "versteckten" Informationen.
   </para>
   <para>
    Es gibt drei bedeutende Lösungen zu diesem Thema. Die erste ist, alle
    Funktionen zu überprüfen und zu versuchen, einen Großteil der
    Fehlermeldungen zu ersetzen. Die zweite ist, die Ausgabe von Fehlermeldungen
    bei produktivem Code generell zu deaktivieren. Die dritte ist, sich unter
    Verwendung der PHP-Funktionen zur Fehlerbehandlung einen eigenen
    Errorhandler zu schreiben. Abhängig von Ihrer Sicherheitspolitik könnte jede
    der drei Lösungen für Sie geeignet sein.
   </para>
   <para>
    Ein Weg, diesen Punkt zügig abzuarbeiten, 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 <constant>E_ALL</constant> testen, können Sie schnell Bereiche entdecken, 
    in denen Ihre Variablen eventuell für Verseuchung oder andere Modifikationen 
    offen sind. Ist Ihr Code einsatzbereit, können Sie entweder das Errorreporting 
    komplett ausschalten, indem Sie <function>error_reporting</function> auf 0 
    setzen, oder Sie schalten die Fehleranzeige mittels der &php.ini;-Option
    <literal>display_errors</literal> aus, um Ihren Code vor dem Ausspähen zu
    schützen. Wenn Sie letztere Möglichkeit wählen, sollten Sie mittels der
    Ini-Direktive <literal>error_log</literal> einen Pfad definieren, in dem
    sich das Logfile befindet, und <literal>log_errors</literal> anschalten.
    <example>
     <title>Gefährliche Variablen mit E_ALL finden</title>
     <programlisting role="php">
<![CDATA[
<?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
    readfile ("/highly/sensitive/data/index.html");
}
?>
]]>
     </programlisting>
    </example>
   </para>
  </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
-->