Nachdem alle verfügbaren Informationen über die zu untersuchende Webanwendung zusammengetragen wurden, geht es darum, diese Informationen gegen die Anwendung einzusetzen. Den Anfang machen dabei zustandsbasierte Angriffe.

Zustände in Webanwendungen

Jede Webanwendung hat eine Startseite, von der aus sich die Benutzer über Links auf verschiedene andere Seiten mit verschiedenen Funktionen weiterbewegen. Theoretisch. Denn statt sich von Seite zu Seite bis zu einer bestimmten Seite anhand der Links "durchzuhangeln", können die Benutzer die Unterseiten auch direkt aufrufen: Im Web gibt es keine Möglichkeit, irgendeine Information darüber zu speichern, von welchen Seiten aus auf eine bestimmte Seite gesprungen werden darf und von welchen Seiten aus nicht. Jede Seite wird ohne Informationen darüber ausgeliefert, von wo der Benutzer kam und wohin er gehen kann. Daher wird das Übertragungsprotokoll HTTP auch als zustandsloses Protokoll bezeichnet. Möchte eine Webanwendung die Aktionen eines Benutzers nachverfolgen und miteinander verbinden, muss sie das selbst übernehmen. Daher werden Benutzer oft mit einer Session-ID (Sitzungs-ID) identifiziert, um sie auch nach mehreren Requests wiedererkennen zu können.

Ist die Reihenfolge der besuchten Seiten für die Webanwendung von Bedeutung, muss sie sich selbst um die Einhaltung dieser Reihenfolge kümmern. Nichts und niemand hindert einen Benutzer daran, eine beliebige Seite direkt aufzurufen, z.B. indem er den URL in seinen Browser eintippt oder einen Bookmark-Eintrag aufruft. Was für das normale Surfen völlig ohne Belang ist, kann für Webanwendungen eine Gefahr sein. Das typische Beispiel ist ein Webshop, bei der ein Benutzer Waren in den Warenkorb legt und dann die Seite für die Eingabe der Zahlungsinformationen überspringt, um direkt zum Abschluss der Bestellung zu gelangen. Achtet die Webanwendung nicht auf das Einhalten der korrekten Reihenfolge, hat der Benutzer danach eine Bestellung aufgegeben, ohne das seine Konto- oder Kreditkartendaten erfasst wurden.

Es ist also Aufgabe der Webanwendung, Zustandsinformationen zu verwalten, wenn sie darauf angewiesen ist. Dafür gibt es zwei Ansätze:

• Die Zustandsinformationen werden auf dem Server gespeichert, die Benutzer werden über eine Session-ID identifiziert.
• Die Zustandsinformationen werden auf dem Client gespeichert.

Unabhängig davon, welcher Ansatz verfolgt wird, müssen Informationen auf dem Client gespeichert werden – entweder die Zustandsinformationen oder die Session-ID. Dafür stehen drei Methoden zur Verfügung, die im folgenden der Reihe nach untersucht werden: versteckte Formularfelder, Parameter in dem URL und Cookies.

Schritt 4: Angriffe auf Zustandsinformationen

Schritt 4a: Versteckte Felder

Um versteckte Felder ging es bereits in About Security #147, jetzt werden die dort gesammelten Informationen verwendet. Die Zustandsinformation kann z.B. in einem Eintrag nach folgendem Muster gespeichert sein:

<input name="id" value="1234" type="hidden">

Die einfachste Möglichkeit, diesen Eintrag zu manipulieren, ist das Speichern der betroffenen Seite in einer Datei, in der dann das 'type="hidden"' gelöscht wird. Außerdem müssen wieder alle relativen Links in passende absolute umgewandelt werden. Danach ist aus dem versteckten Feld ein normales Textfeld geworden, das nach Belieben manipuliert werden kann. Alternativ können die Daten auch nach dem Senden "on the fly" über einen Proxy wie Paros oder ein Tool wie die Firefox-Erweiterung Firebug manipuliert werden. Im Folgenden wird zwischen beiden Ansätzen nicht unterschieden: Wenn es heißt "Wird der Parameter manipuliert und das Formular abgesendet..." ist genauso auch "Wird das Formular abgesendet und der Parameter 'on the fly' manipuliert" gemeint.

Alle gefundenen versteckten Felder müssen daraufhin untersucht werden, wie sich die Webanwendung bei einer Änderung der Werte verhält. Das klassische Beispiel ist hierbei immer noch die Speicherung von Preisen eines Webshops im Formular statt auf dem Server. Wird der entsprechende Parameter manipuliert und das Formular abgesendet, ändert sich auf der nächsten Seite der Warenwert im Warenkorb. Das Gleiche gilt entsprechend für versteckte Felder, die den Status eines Benutzers speichern: Wird so ein Parameter geändert und die Webanwendung akzeptiert diese Änderung, ist der Angreifer danach nicht mehr Gast, sondern ein Benutzer, oder aus einem Benutzertyp wird ein anderer. Außerdem kann in versteckten Parameter z.B. auch die letzte besuchte Seite gespeichert werden, um das Einhalten einer gewünschten Reihenfolge sicher zu stellen. Wird so ein Parameter geändert, können Seiten angesprungen werden, die eigentlich zu dem Zeitpunkt nicht zugänglich sein sollten. Um in versteckten Formularfeldern gespeicherte Session-IDs geht es in einem separaten Punkt.

In der nächsten Folge geht es um die Abwehr derartiger Angriffe sowie um Angriffe auf in URL-Parametern übertragene Zustandsinformationen.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Schwachstellensuche – II. Zustandsbasierte Angriffe"

• About Security #149: Schwachstellensuche: Zustandsinformationen (1)
• About Security #150: Schwachstellensuche: Zustandsinformationen (2)
• About Security #151: Schwachstellensuche: Cookie Poisoning
• About Security #152: Schwachstellensuche: Contra Cookie Poisoning
• About Security #153: Schwachstellensuche: URL Jumping
• About Security #154: Schwachstellensuche: Der Referer Header
• About Security #155: Schwachstellensuche: Session Hijacking
• About Security #156: Schwachstellensuche: Session Hijacking verhindern
• About Security #157: Schwachstellensuche: Session Fixation