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
5-11
.
Variablen
mit
einer
eigenen
HTML
Seite
angreifen
|
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
5-12
.
Ausnutzen
von
gebräuchlichen
Debugging
Variablen
|
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
5-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")
;
}
?
|
|