Moin!

Und die Frage, wie man die Lücke schließt, überläßt du mit deinem
Wissen dann sowieso lieber jemandem, der sich damit auskennt.

das wird sich zeigen, wenn ich nicht weis wie man die lücke schließen
kann, kann ich ja schlecht sagen wie der jenige sie schließen soll.

Sollst du ihm ja auch nicht sagen, das sollte er schon allein wissen.

Ein Praxisbeispiel:

Der WYSIWYG-Browsereditor SPAW besteht aus diversen PHP-Dateien.

In einer dieser Dateien stand direkt am Anfang folgender Code (schematisch, die exakten Variablennamen weiß ich jetzt nicht auswendig):

include ($SPAW_CONFIG_DIR."/irgendein/festes/skript.inc.php");

Fällt dir die mögliche Sicherheitslücke sofort auf?

Jemandem ist sie aufgefallen, er meldete "arbitrary code include possible" an den Hersteller, weil man bei "register_globals=on" und "allow_url_fopen=on" hier beliebigen Code einschleusen kann.

Der Hersteller reagierte mit folgender Verbesserung:

if (!ereg("/^http:\/\//i",$SPAW_CONFIG_DIR))  
{  
  include ($SPAW_CONFIG_DIR."/irgendein/festes/skript.inc.php");  
}

Siehst du hier die Lücke auch noch?

Die Prüfung, ob in der eingeschleusten Variablen vorn "http" steht, ist zwar nett, aber "allow_url_fopen" gilt für mehr Mechanismen als nur "http" - beispielsweise auch "ftp".

Das Problem bei diesem Editor ist nur: Dieses Skript wird seinerseits im Normalfall von einem Hauptskript eingebunden, die Variable $SPAW_CONFIG_DIR ist dadurch gewöhnlich mit einem vernünftigen Wert vorbelegt, und wenn man jetzt hier irgendwelche Prüfungen unternimmt oder die Variable rauswirft, dann gefährdet man unter Umständen die Funktionsfähigkeit des gesamten Skriptes.

Es ist also wesentlich leichter, in einem Programmtext, dessen tatsächliche Zusammenhänge und Funktionsweisen man nicht so genau verstehen muß, nur durch isoliertes Betrachten einer einzigen Codezeile eine mögliche Lücke zu finden - die Beseitigung dieser Lücke hingegen erfordert in der Regel dann doch die umfangreichen Kenntnisse über das Programm, die man sich nur mit viel Arbeit aneignen kann.

Natürlich läßt sich dieses Beispiel auch auf andere Weisen abdichten. register_globals sollte ja sowieso lieber off sein. Alternativ kann auch allow_url_fopen abgeschaltet werden - eine der beiden Maßnahmen verhindert das Ausnutzen der Lücke ebenso. Und wenn beides nicht möglich ist (bei Massenprovidern tendentiell der Fall), dann könnte man immer noch den externen Zugriff per HTTP auf dieses Verzeichnis unterbinden - PHP selbst greift ja über das Dateisystem zu.

Diese alternativen Workarounds lösen das Problem aber nicht endgültig.

sondern kann ihn nur darauf aufmerksam machen das eine lücke vorhanden
ist und ich sie gefunden habe. wenn ich sie nicht finde kann ich ihn
nichtmal darauf aufmerksam machen. ich denke aber das man wenn man
eine lücke kennt auch die lösung dazu kennt. wenn man sie nicht kennt
ist es zufall.

Du hast bislang noch zuwenig Lücken in deinem Leben gefunden, glaube ich.

Mir sind bislang ja auch nur ein paar wirklich offensichtliche Lücken aufgefallen, von Leuten, die etwas dilettantisch programmiert haben.

Das bislang spannendste (auch weil ich direkte Live-Interaktion vom programmierenden Admin kriegte) war ein HTML-Formular (verkürzt dargestellt), welches man in einem Intranet aufrufen konnte, um sein eigenes Login-Passwort zu ändern:

  
<input type="hidden" name="user" value="23">  
<input type="password" name="password1">  
<input type="password" name="password2">  
<!-- und weitere Textfelder für Name, Adresse, Telefon etc. -->  

Einen Sessionmechanismus existierte nicht.

• Sven Rautenberg