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. 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:
Beispiel #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, 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, show_source(),
highlight_string() oder
highlight_file() 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:
Beispiel #2 Ausnutzen von gebräuchlichen Debugging-Variablen
<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>
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 Standardfehlermeldung 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 Ausschau zu halten), 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 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.
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.
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.
Ein Weg, diesen Punkt zügig abzuarbeiten, 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 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 error_reporting() auf 0
setzen, oder Sie schalten die Fehleranzeige mittels der php.ini-Option
display_errors
aus, um Ihren Code vor dem Ausspähen zu
schützen. Wenn Sie letztere Möglichkeit wählen, sollten Sie mittels der
Ini-Direktive error_log
einen Pfad definieren, in dem
sich das Logfile befindet, und log_errors
anschalten.
Beispiel #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
readfile ("/highly/sensitive/data/index.html");
}
?>