Montag, 2. Januar 2012


Topthema

Donnerstag, 3. April 2008 | Topthema

About Security #149: Schwachstellensuche: Zustandsinformationen (1)

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/042451)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

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.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

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.

About Security: Die komplette Serie

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.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

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

Kommentare

Folgende Links könnten Sie auch interessieren