Nach dem Lesen des heise-Artikels gestern habe ich mir, wie schon erwähnt, eine WebSite der Telekom, bzw. eine der T-öchter, mal etwas genauer angeschaut. Dort fiel mir im Download-Bereich der Aufbau der Links zu den PDFs auf:

http://t-zeuch.de/blabla/download.script?file=mehrzeuch.pdf
(Wollte grad “t-website.de” schreiben, aber die gibt es wirklich. <G>)

Solche URmeLs springen mich geradezu an, würgen mich und flehen darum genauer untersucht zu werden.

http://t-zeuch.de/blabla/download.script?file=../download.script

…

http://t-zeuch.de/blabla/download.script?file=../../index.script

Jo! Funzt, zwei Dateien mehr auf der Platte! :O)


Was ist das?
Wenn man das Acrobat-Reader-Plugin im Browser installiert hat und der Browser wie üblich konfiguriert ist, so öffnet sich eine PDF immer im Browser selber. Wenn man nun als WebSite-Betreiber möchte das eine PDF nicht wie üblich direkt im Browser des Besuchers angezeigt wird, sondern ein Download startet, so schaltet man ein Script dazwischen. Dieses Script sagt dem Browser: Bitte nicht selber anzeigen, sondern nur runterladen.

So weit so gut. Aber… und das ist der Knackpunkt… das Script muß natürlich prüfen welche Dateien überhaupt zum Download freigegeben werden dürfen. Das Script darf natürlich nicht ../datei oder ../../../../verzeichnis/datei oder Ähnliches verarbeiten und Dateien zum Download anbieten die u.U. auch außerhalb der öffentlichen Verzeichnisse liegen.

Üblicherweise macht man es so das ein Verzeichnis für den Download freigegeben ist. Das Script weiß, alle Dateien in dem Verzeichnis XYZ, vom Typ PDF, XLS, DOC, etc. dürfen von einem User geladen werden. Versucht der User außerhalb des vorgesehenen Verzeichnisses Dateien zu laden, so wird dies mit einer Fehlermeldung quittiert bzw. ignoriert. Fertig.

Der T-Mensch der das von mir gefundene Downloadscript geschrieben hat hat schlicht und ergreifend vergessen die eben genannten Prüfungen in sein Script einzubauen. Diesen Fehler findet man in vielen Scripten, also sollte sich der T-Mensch nicht zu sehr grämen.

Der Fehler in dem Script war zwar simpel – es sind oft eher Flüchtigkeitsfehler – aber diese vermeintlich kleinen Fehler haben manchmal weitreichenden Auswirkungen, auf die gesamte IT-Infrastruktur eines Unternehmens. Es kann sogar, sofern der Server falsch konfiguriert ist, auch ein unbeteiligter WebSite-Betreiber betroffen sein und dies nur weil er zufällig auf dem gleichen Server seine WebSite liegen hat.

Was der Telekom und auch anderen Unternehmen fehlt ist ein Externer, jemand der nach den Fehlern schaut, so ein Korinthenkacker wie ich z.B. :O)


Die T-Menschen haben das Script gefixt, mir natürlich nicht geantwortet, ist ihnen wohl zu peinlich… Naja, ich kenn es ja nicht anders. Jetzt kommt nur noch folgende Meldung:
“Sie versuchen Dateien herunterzuladen, die nicht für einen Download vorgesehen sind.”
(Ohne HTML drumherum… naja, ausnahmsweise…)

Wie humorlos! Die T-Menschen haben keinen Spass an ihrer Arbeit. Ich hätte da etwas anderes gemacht:

Zum Beispiel eine Weiterleitung zu dem schon fast legendären 127.0.0.1-Hacker bitchchecker (stophiphop.com). :O)

Oder wie wäre es mit einer Hacker-Spielwiese, wo der RosaRiese sich gleich qualifiziertes Personal sucht, evtl. auch mal welche ohne Studium, Diplom und Doktor-Titel, einfach nur mal welche die auch wirklich Ahnung haben von dem was sie machen. :O)


Update: 15.10.2008
Eben trudeln bei mir zwei E-Mails rein, einmal von der Telekom und einmal von T-Systems. Das freut mich sehr! Also, auch wenn es evtl. peinlich war, die Jungs und Mädels gehen mit eigenen Fehlern konstruktiv um.