Hello,

Wenn ich hier vorher

$login = false;   ## Initialisierung

if ($passwort="geheim") {
  $login=true;
}
if ($login) {
  usw.
}

Mit seite.php?login=1 liessen sich solche Prüfungen ohne weiteres umgehen, was dann dazu führte, dass die für den Variablenimport verantwortliche PHP-Option standardmäßig ausgeschaltet wurde.

durchgeführt habe, kann  'seite.php?login=1'  nichts mehr ausrichten, da

• Parameter übernehmen in der vorgeschriebenen Reihenfolge: meistens GPC
• die im Script vorgesehenen Aktionen ausführen, also z.B.
• • Includes,
• • Konstanten,
• • Variablen-Deklaration/Initialisierung,
• • Session-Start,
• • usw.

Dann könnte nichts passieren.

Besonders gefährdet sind da die "Includer", die Scriptteile aufgrund einer externen Filename-Angabe dazuladen.

index.php?site=start

und dann im Script stehen haben:

include "$site.php";

Das oder

Mesitens ist fopen als Wrapper erlaubt,

dies dürfte das Einfallstor für den Virus sein, der hier angesprochen wurde. Das hat aber weniger mit nicht-initalisierten Variablen zu tun als mit der Frage, warum der Inhalt von $site nicht vor Benutzung geprüft wird. Dabei gilt die Regel, auf exakt das zu prüfen, was drinstehen darf, nicht umgekehrt zu prüfen, ob etwas nicht drinsteht. Mit einer Prüfung auf eine unerlaubte eine URL (http://...) kann man immer noch Systemdateien ausgeben lassen (index.php?site=/etc/passwd). Wird die Datei durch fopen gelesen, könnte man sogar den Code der PHP-Skripte anzeigen lassen.

In meinem Beispiel hatte ich ja schon eine Endung dazugestanzt. Das würde (unter Normalumständen) schon mal verhindern, dass irgendwelche dateien vom System gelesen werden.
Wenn man nun noch den Basename() des Parameters ermittelt und mit dem Parameter vergleicht (!) und bei Abweichung sofort das Script abbricht bzw. in eine Standardausgabe laufen lässt, hat man die nächste Unsicherheitsstufe verlassen. Schließlich sollte man dann noch die zu includende Datei aus einem fest vorschriebenen Verzeichnis holen, und wenn sie dort nicht vorhanden ist, ebenfalls intern die rote Lampe anknipsen und nach außen Standardausgaben tätigen.

Include() ist die am häufigsten eingebaute Sicherheitslücke in PHP-Scripten. Da eval() i.d.R. schon beim Coden Zicken macht (wenn man nicht weiß, wie es funktioniert), wir es seltener benutzt. Es ist aber keinesfalls gefährlicher als include().

Weitere wesentliche Methoden sind die der Session-Entführung, die bei vielen Großprovidern anstandslos funktioniert. Dagegen kann ein Hosting-Kunde nichts unternehmen. Das ist ein Fehler in der Systemkonfiguration, weshalb ich immer wieder behaupte, dass eine vServer-Zelle sicherer ist, als ein Massen-Account.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom