Javascript from Hell
Marc Ruef | 24.02.2006

Wer kennt sie nicht: Die kleinen web-basierten Hackits, bei denen man als Frischling sein jüngst erworbenes Wissen im Umgang mit dem Thema Computersicherheit ausprobieren darf. Ein Klassiker dabei ist das Umgehen von mit Javascript (Abk. JS) umgesetzten Passwortabfragen. Beim Betreten einer Webseite wird man auf dieser nach einem Passwort gefragt. Ist man im Besitz des richtigen und gibt dieses an, wird man auf den geschützten Bereich geleitet und hat damit das Hackit bestanden. Bei der fehlerhaften Eingabe des Passworts wird hingegen eine Fehlermeldung ausgegeben. Als Angreifer geht es nun darum ohne das Wissen um das richtige Passwort den Zugang zu erlangen.

Wer sich ein bischen intensiver mit dem Absichern von Web-Applikationen auseinandergesetzt hat, wird in der Regel innert weniger Minuten diese schwache Authentisierung umgangen haben. Das Durchsehen des Quelltexts des HTML-Dokuments reicht meistens aus, um den Mechanismus verstanden zu haben und damit die simple Passwort-Überprüfung aushebeln zu können. Aus diesem Grund gelten Schutzmassnahmen mit Javascript als sehr unsicher und deshalb in professionellen Umgebungen nicht empfehlenswert.

Die Sicherheitsvorkehrungen werden nämlich ganz oder zu grossen Teilen auf dem Client (hierbei eigentlich der Webbrowser) selber umgesetzt. Da der Angreifer in den meisten Fällen seinen Client nach belieben analysieren (HTML-Quelltext durchschauen), manipulieren (Javascript deaktivieren) oder einen eigenen vortäuschen kann (Telnet nutzen), hat er auch den Grossteil der Kontrolle über die Schutzmassnahme.

Im Rahmen eines gross angelegten Audit-Pakets musste ich für einen internationalen Telekommunikations-Dienstleister eine Web-Applikation auf mögliche Mängel hin untersuchen. Der zu testende Dienst war für Provider und Reseller gedacht, die ihre Pakete für Telefonie-Verbindungen online verwalten können sollen. Durch die schicke Oberfläche liessen sich neue Nummern aktivieren, Routen für Nummernbereiche abändern oder Text-Ansagen für kostenpflichtige Rufnummern speichern.

Wie immer loggte ich mich mit meinem extra angelegten Test-Konto ein, um ein Gefühl für das "normale Handling" des Produkts zu bekommen. Ich erstellte mir sodann einige Service-Nummern, die ich zu meinem Erstaunen mit vorgefertigten Ansagen für "erotische Dienste" belegen konnte. Vielleicht steig ich trotzdem mal noch in die Erotikbranche ein. Eine Nummer - wenigstens für die kommenden Tage - hab ich jedenfalls nun schonmal.

Bei diesem ersten Herantasten ist mir aufgefallen, dass ein Grossteil der Bedienelemente mit Javascript versehen wurden. Beispielsweise wurden Buttons erst dann aktiviert (enabled), wenn in der erforderlichen Textbox auch wirklich eine nummerische Zeichenkette eingegeben wurde. Soweit eigentlich nichts Spezielles, denn derlei Hilfestellungen für Benutzer, die damit von fehlerhaften Eingaben abgehalten werden, sind durchaus sinnvoll. Defensive Programmierung ist meines Erachtens gar stetig lobenswert.

Wie es sich aber alsbald herausstellen sollte, war der umfassende Einsatz der kleinen Skripting-Technologie ein grösseres Hindernis für meinen Penetration Test. Und zwar wurden in vielen Eingabefeldern unerwünschte und potentiell gefährliche Zeichenketten einfach gelöscht. Es war mir also gar nicht möglich, ein Formular mit SQL-Injection und Cross Site Scripting umzusetzen. Vor allem die dafür zwingend notwendigen Sonderzeichen (z.B. ' oder