Kapitel 28. Fehlerbehandlung

PHP Security hat zwei Seiten der Fehlerbehandlung. Eine ist für die Erhöhung der Sicherheit vorteilhaft, die andere ist schädlich.

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. 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:

Beispiel 28-1. Variablen mit einer eigenen HTML Seite angreifen <form method="post" action="attacktarget?username=badfoo&password=badfoo"> <input type="hidden" name="username" value="badfoo"> <input type="hidden" name="password" value="badfoo"> </form>

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 und die Zeilennummer des aufgetretenen Fehlers anzeigen lassen möchte. Das sind alles Informationen, die ausgenutzt werden können. Es ist für einen PHP Entwickler nicht unüblich, show_source(), highlight_string(), oder highlight_file() zur Fehlersuche zu verwenden, jedoch kann dies in einem lebenden System auch versteckte Variablen, ungeprüfte Syntax und andere gefährliche Informationen aufdecken. 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:

Beispiel 28-2. Ausnutzen von gebräuchlichen Debugging Variablen <form method="post" action="attacktarget?errors=Y&amp;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>

Ungeachtet der Fehlerbehandlungsmethode führt die Möglichkeit ein System nach Fehlermeldungen zu sondieren dazu, dass einem Angreifer mehr Informationen geboten werden.

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.

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 Datenbank-Ports, 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), wie auch durch "Herumstochern" Missbrauchsmöglichkeiten an verschiedenen Stellen im Script herausfinden.

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.

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 Code generell zu deaktivieren. Die dritte ist, sich unter Verwendung der 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.

Ein Weg, diesen Punkt vorzeitig zu behandeln ist, das PHP eigene error_reporting() 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 Sie 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.

Beispiel 28-3. Gefährliche Variablen mit E_ALL finden <?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"); } ?>