entwickler.com

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.

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?

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.

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