Dateien öffnen - Sicherheitsrisiko von Benutzereingaben
Dateien öffnen als Sicherheitsrisiko... tja, kann man denken, was soll da schon großartig passieren.
Aber Vorsicht, ein unsauberes Programm wie das Folgende kann es unliebsamen Zeitgenossen ermöglichen, Zugriff auf Ihren Server zu erlangen.
...
#Hier werden Parameter eingelesen, die Ihre Webseitenbesucher eingeben können, unter anderem auch den Parameter $datei open (in,"<daten/$datei.txt"); print <in>; close in;
Auf den ersten Blick alles ganz easy, im Verzeichnis daten wird die gewünschte Datei geöffnet. Funktioniert auch ganz prächtig. ABER:
Was, wenn auf Ihrem Server im Verzeichnis daten/passwoerter/ eine Liste mit Passwörtern in der Datei pw.txt liegt, die niemand einsehen darf?
Nun, was, wenn der User für die Variable $datei folgendes eingibt: passwoerter/pw?
Bingo, die Datei wird geöffnet und angezeigt! Alle Passwörter können eingesehen werden! Und von nun an können alle Eingaben Ihrer User geändert oder gelöscht werden!
Schlimm genug, aber das Drama geht noch weiter:
Durch eine geeignete Maskierung der eingegeben Daten für $datei ist es sogar möglich, ALLE Dateien auf dem Server auszulesen, sofern die Rechte entsprechend gesetzt sind!
Und alle bedeutet: ALLE! Sei es nun eine Text-Datei, HTML, Perl oder sonstwas.
Wie das gehen soll, obwohl doch nur .txt-Dateien angegeben werden (open (in,"<daten/$datei.txt");)? Denn Perl wandelt ja die Variable in den Dateiname+.txt um, also zum Beispiel $datei=test öffnet test.txt. Wie kann das Skript also alle andere Dateien öffnen, die nicht die Endung Text haben?
Unglaublich, geht aber trotzdem:
Zum Testen legt man am Besten eine Datei test.pl auf dem Server an, die geöffnet werden soll. Geben Sie nun für Datei den Wert:../test.pl%00 ein. Und was passiert? test.pl wird angezeigt! War ja klar, sonst wär es ja ein sch...lechtes Beispiel. Aber wieso???
Die Erklärung liegt in Perl und in der Programmiersprache C, in der Perl geschrieben wurde.
Für Perl sieht das Script so aus:
Öffne die Datei <daten/../test.pl\0.txt und gib sie aus.
Natürlich würde das nicht funktionieren, da es diese Datei nicht gibt.
Aber hier greift C ein: Das \0-Zeichen bedeutet für C, die Variable hier zu beenden, oder anders gesagt, aus daten/../test.pl\0.txt wird daten/../test.pl!!! Und schon werden alle Dateien angezeigt, die man haben will. Welche Folgen das haben kann, kann sich jeder selbst ausmalen...
Genannt wird dieses Phänomen übrigens "The poison NULL Byte" oder, zu deutsch, "Das vergiftete Null-Byte" oder "Die vergiftete Null". Vergiftet deswegen, weil durch das Null-Byte ansonsten sauber geschrieben Skripte plötzlich ein Verhalten aufweisen können, an das niemand gedacht hat.
Was kann ich dagegen tun?
Ich würde folgendes Vorschlagen:
1. Keine Usereingabe sollte ungeprüft zum Öffnen oder Schreiben von Dateien oder für eval(), system() oder sonstige Betriebssystem-Aufrufe verwendet werden.
2. Alle Zeichen, die für eine gültige Ausführung des Skriptes nicht verwendet werden müssen, sollten gelöscht werden.
hier: $eingabe=~ s/[\/\.\0]//g;
löscht also besagtes Null_Byte, alle . und / - Zeichen.
Interessante Effekte ergibt auch die Eingabe von "/bin/ls /etc\0|" für ein open (in,$eingabe);.
Wie Sie vielleicht sehen, steht am Ende der Eingabe das |-Zeichen, in Unix genannt Pipi, oder eingedeutscht, Kanal. Genutzt wird dieses zeichen, um einen "Kanal" von einer Anwendung zu einer anderen unter Unix zu erstellen. Oder besser gesagt: Alle Ausgaben des einen Prozesses werden an den anderen weitergeleitet. Und was soll das nun hier? Ganz einfach, sehen wir uns nochmal die Einabezeile an:
/bin/ls /etc\0|
Es passiert folgendes:
/bin/ls wird gestartet, wer es nicht weiß: ls entspricht dem dir Befehl unter dem populären Nicht-Unix System... Es wird also das Verzeichnis ausgegeben. Als Parameter wurde /etc angegeben, es erfolgt also eine Ausgabe des Verzeichnisses /etc des Servers. Einfach so, für jeden, auch für die, die es gar nichts angeht!
Abhilfe: |-Zeichen entfernen aus einer möglichen Eingabe!
$eingabe=~ s/\|//g;
UND:
Öffnen Sie niemals eine Datei in der Form open (in,$eingabe);
sondern benutzen Sie auf jeden Fall das < und das > - Zeichen, also < für lesenden Zugriff, > für Schreiben mit einem Neuanlegen oder das >> für anhängend-schreibend.
Denn dadurch wird die Geschichte mit dem | ebenfalls unterbunden.
Wie Sie sehen, kann also sogar ein einfaches Öffnen einer Datei ein Sicherheitsrisiko darstellen, das man aber mit etwas Umsicht abstellen kann.
Kommentare zum Beitrag "Dateien öffnen - Sicherheitsrisiko von Benutzereingaben"
Kommentar von Max
Ist dieser Effekt eigentlich für PERL 6 immer noch relevant? Das wurde ja in Haskell geschrieben. Haskell wird zwar nach C übersetzt, aber vielleicht wird dieser Fehler ja abgefangen.
RSS-Feed