Montag, 2. Januar 2012


Topthema

Donnerstag, 10. April 2008 | Topthema

About Security #150: Schwachstellensuche: Zustandsinformationen (2)

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

Bevor im n�chsten Schritt URL-Parameter auf m�gliche, zustandsbasierte Angriffe untersucht werden k�nnen, m�ssen zuvor bereits gefundene Schwachstellen beim Umgang mit Zustandsinformationen (siehe About Security #149) behoben werden. Das Grundproblem besteht dabei darin, dass die Zustandsinformationen auf dem Client gespeichert werden, wodurch sie von einem Angreifer manipuliert werden k�nnen.

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

Um derartige Angriffe abzuwehrenn, kann also auf den alten Grundsatz "Traue nie dem Client" zur�ckgegriffen werden: Informationen, die vom Benutzer und insbesondere einem Angreifer nicht manipuliert werden d�rfen, d�rfen nicht auf dem Client gespeichert werden. Zur�ckgegebene Werte m�ssen immer gepr�ft werden. In diesem Fall auch darauf, ob es sich um erwartete Werte handelt. Was manchmal ziemlich schwierig ist: Preise d�rften z.B. in den seltensten F�llen negativ werden, aber wie niedrig d�rfen sie denn sein? Daf�r eine Regel aufzustellen, d�rfte in den allermeisten F�llen unm�glich sein. Um festzustellen, ob der zur�ckgelieferte Preis korrekt ist, muss man ihn mit dem auf dem Server gespeicherten Wert vergleichen. Dann kann man aber auch gleich den auf dem Server gespeicherten Wert verwenden, wodurch eine Manipulation des Clients durch den Angreifer zwecklos wird. Dasselbe gilt entsprechend f�r die meisten anderen Einsatzzwecke auf dem Client gespeicherter Zustandsinformationen: Wann immer es m�glich ist, sollten Informationen auf dem Server gespeichert werden. Manchmal ist es aber trotz aller Bedenken notwendig, Informationen auf dem Client zu speichern, z.B. im Fall von Session-IDs (auf die sp�ter eingegangen wird). Einen vorget�uschten Schutz bietet dabei die Verwendung kryptischer Namen f�r die Parameter. Ein Name wie z.B. "vdf7dg" ist im Quelltext zwar weniger auff�llig als z.B. "Preis" oder "Status", da seine Bedeutung aber gleich bleibt, ist es f�r einen Angreifer kein Problem, sie zu ermitteln. Mehr Schutz bietet die Verschl�sselung oder das Hashen der Werte, da sie dann vom Angreifer nicht mehr so leicht manipuliert werden k�nnen.

Schritt 4b: URL-Parameter

Der Vorteil der �bertragung der Zustandsinformationen �ber den URL besteht darin, das sie dann auch beim Anklicken eines normalen Links �bertragen werden, w�hrend Formulare, egal ob mit oder ohne versteckte Felder, das Anklicken eines Buttons erfordern. Die in Links enthaltenen Parameter k�nnen vor dem Anklicken �ber die Statuszeile und nach dem Anklicken in der Adresszeile des Webbrowsers beobachtet werden, und auch die Manipulation kann direkt in der Adresszeile erfolgen. Ein Angreifer nutzt entweder die zuvor gesammelten Informationen oder beobachtet die �nderungen an den Parametern in dem URL, w�hrend er sich durch die Webanwendung klickt. Danach l�uft ein Angriffe wie bei der Manipulation versteckter Felder ab: Was passiert, wenn ein Parameter manipuliert wird? Ein typisches Beispiel ist ein Parameter, �ber den bestimmte Daten ausgew�hlt werden, z.B. ein Benutzerprofil:

http://www.webanwendung.example/editprofil.cgi?id=456

Was passiert, wenn der Wert f�r "id" ge�ndert wird? Kann das Profil eines anderen Benutzers ge�ndert oder auf Daten zugegriffen werden, die eigentlich nicht zug�nglich sein sollten? Entsprechend wird mit allen anderen Parametern verfahren: Wo �ndert sich unerwartet und unerlaubt ein Zustand?

About Security: Die komplette Serie

Evtl. gibt es auch Parameter, die aktuell gar nicht in dem URL enthalten sind, z.B. zum Einschalten der Ausgabe von Debug-Informationen. Die k�nnte durch eine Parameter-Wert-Kombination wie debug=on, debug=1, debug=true oder so �hnlich aktiviert werden. Beim Testen der eigenen Webanwendung kennt man den notwendigen Parameter, ein Angreifer kann nur systematisch m�gliche Kombinationen ausprobieren. Nat�rlich wurde die entsprechende Funktion entfernt, bevor die Webanwendung auf das Produktivsystem �bertragen wurde � oder? Wenn nicht, sollte das jetzt nachgeholt werden. Um einen Angreifer das Erraten des Parameters zu erschweren, kann man statt "debug" eine zuf�llige Bezeichnung wie "fghzq" verwenden. Das nutzt aber nur etwas, wenn der Parameter keine Auswirkungen auf den Client hat. Sonst erkennt der Angreifer seine Bedeutung bei der Analyse des Clients und wird dann nat�rlich auch dessen Auswirkungen auf den Server testen.

Die Gegenma�nahmen gegen solche Angriffe beginnen wieder mit dem alten Lied "Traue nie dem Client", sprich: Alle Werte m�ssen vor ihrer Verwendung �berpr�ft werden. Wie auch beim Schutz vor Angriffen �ber manipulierte Formularfelder kann die Verschl�sselung oder das Hashen der Werte den Angreifer zumindest behindern.

Schritt 4c: Cookie-Parameter

Cookies sind die einzige M�glichkeit, Daten f�r l�ngere Zeit auf dem Client zu speichern. Ein verbreiteter Anwendungszweck ist das Erkennen des betreffenden Benutzers bei einem erneuten Besuch, um ihn z.B. direkt eine personalisierte Version der Webanwendung zu pr�sentieren. F�r einen Angriff, bei dem Cookies manipuliert werden, gibt es eine eigene Bezeichnung: Cookie Poisoning. Das ist ein Thema der n�chsten Folge.

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