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 4-11. 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 4-12. 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 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 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 4-13. 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");
}
?> |
|
