entwickler.com

Bei der Schwachstellen-Suche in Webanwendungen sind nach den normalen Parametern nun versteckte Informationen im Client an der Reihe. Versteckte (type="hidden") Felder könnten z.B. Token zum Schutz vor CSRF-Angriffen sein, aber auch für den Programmablauf der Webanwendung wichtige Werte. Geradezu ein Klassiker ist die Speicherung der Preise eines Warenkorbs in einem versteckten Feld. Verlässt sich die Webanwendung dann auf die vom Client gelieferten Werte, steht einem Billigeinkauf nichts mehr im Wege. Außerdem nutzt ColdFusion versteckte Felder, um auf dem Server zu prüfende Parameter zu kennzeichnen:

<input type="text" name="Anzahl" size="10" maxlength="10">
<input type="hidden" name="Anzahl_cfforminteger" value="Bitte Zahl eingeben">

Der Server wird hiermit angewiesen, den Parameter "Anzahl" darauf zu prüfen, ob es ein Integer-Wert ist. Entsprechend gibt es viele weitere Prüffunktionen, die über ein verstecktes Feld nach dem Muster "Parameter_Prüfung" aufgerufen werden. Der Angreifer muss also nichts weiter tun, als die entsprechenden Zeilen aus dem HTML-Code zu entfernen, um die automatische Prüfung der Parameter zu umgehen.

Nach den HTML-Tags ist in der Seite enthaltener JavaScript-Code an der Reihe, der oft auch zum Prüfen von Eingaben verwendet wird. Interessanter JavaScript-Code kann z.B. an einen OnSubmit-Event gekoppelt sein: Wenn ein Formular abgeschickt wird, wird der zugehörige Testcode aufgerufen. Generell muss aber der gesamte JavaScript-Code daraufhin untersucht werden, ob es sich um Eingabeprüfungen handelt. Alle auf dem Client geprüften Werte müssen natürlich trotzdem auf dem Server geprüft werden - aber passiert das wirklich? Um das zu testen, müssen die Eingabeprüfungen auf dem Client deaktiviert werden. Die einfachste Methode, um JavaScript-Eingabeprüfungen zu deaktivieren, ist das Ausschalten von JavaScript. Da dann aber oft auch weitere, benötigte Funktionen, z.B. für die Navigation, nicht mehr funktionieren, kann der für die Prüfungen zuständige Code auch über ein Tool wie Firefox Firebug oder eine gezielte Manipulation der HTML-Seite ausgeschaltet werden.

Damit ist die Untersuchung des statischen Clients abgeschlossen. Wir kommen nun zum

Schritt 3b: Untersuchung von Ajax-Clients

Wie bereits in About Security #146 erwähnt, besteht der Unterschied zwischen klassischen, statischen Websites und den dynamischen Ajax-Webanwendungen darin, dass ein Ajax-Client interne Zustände hat, die sein Verhalten beeinflussen. Die Reihenfolge der Benutzerinteraktionen hat Auswirkungen auf den Ablauf des JavaScript-Codes, dazu kommen u.U. automatische Requests zur Aktualisierung von z.B. Aktienkursen oder Wetterdaten. Hinzu kommen Änderungen während der Laufzeit: Server-Antworten enthalten neuen JavaScript-Code, der das Verhalten der Seite ändern kann. Dynamisches Nachladen von Skriptcode ist aus Sicherheitssicht problematisch: Welche Code-Teile sind zu einem bestimmten Zeitpunkt auf dem Client aktiv? Dazu kommen neue Datenstrukturen wie XML, JSON, JavaScript-Arrays und proprietäre Strukturen sowie neue Protokolle wie SOAP, REST und XML-RPC. Zu guter Letzt gibt es in Abhängigkeit vom verwendeten Framework unterschiedliche Formate für den Aufbau eines Requests - kennt ein menschlicher Tester oder ein Schwachstellen-Scanner das Framework nicht, erkennt er evtl. Requests nicht oder nicht richtig.

An die Schwachstellen-Suche in Web-2.0-Anwendungen, egal ob durch einen Menschen oder einen Schwachstellen-Scanner, werden also zwei Anforderungen gestellt:

• Es müssen alle verwendeten Ressourcen auf dem Server bzw. den Servern ermittelt werden.
  Während bei einer klassischen Webanwendung alle Ressourcen durch das Absuchen aller Seiten gefunden werden konnten, können sie bei einer Web2.0-Anwendung buchstäblich "überall und nirgends" sein: Nachgeladener JavaScript-Code kann Aufrufe bisher unbekannter Ressourcen enthalten, die wiederum Aufrufe weiterer bisher unbekannter Ressourcen enthalten. Usw. usf. ...
• Auch der komplexe Client selbst muss untersucht werden.
  Das ist vor allem für Schwachstellen-Scanner neu, die konnten sich bisher auf den Server konzentrieren. Nun müssen aber auch Schwachstellen im Client wie Cross-Site-Request-Forgery und DOM-basiertes Cross-Site-Scripting berücksichtigt werden.
  Wie oben beschrieben, ist es schwierig, jeden möglichen Status des Clients zu ermitteln.

Vereinfacht ausgedrückt, wird bei herkömmlichen Webanwendungen der Client nur genutzt, um Informationen über die Anwendung auf dem Server zu erlangen und diesen danach anzugreifen. Bei Ajax-Anwendungen ist der Client dagegen außerdem selbst ein mögliches Angriffsziel, da ein Teil der Anwendungslogik in den Client ausgelagert ist.

In der nächsten Folge wird die Untersuchung eines Ajax-Clients an einem Beispiel beschrieben: Eine Nachrichtenseite kombiniert Informationen aus verschiedenen RSS-Feeds.

Carsten Eilers