In About Security #151 erfuhren Sie, wie ein Angreifer durch die Manipulation von Cookies den Zustand der Webanwendung unerwünscht ändern kann. In dieser Folge erfahren Sie, wie Sie nach derartigen Schwachstellen suchen und was Sie gegen Cookie-Poisoning-Angriffe unternehmen können.
N E U ! Security aktuell
Täglich aktuelle Security-Infos!
Schwachstellen finden
Wenn Sie eine Webanwendung auf Schwachstellen in der Zustandsverwaltung untersuchen, müssen Sie außer den eigenen Parametern der Webanwendung auch die Parameter prüfen, die vom Webbrowser automatisch an den Server gesendet werden. In diesem Fall ist es die Gültigkeitsdauer der Cookies, später kommen auch noch verschiedene HTTP-Header dazu. Die entscheidende Frage ist wieder: Ändert sich bei einer Manipulation eines solchen Parameters unerlaubt ein Zustand? Bei der Manipulation der Gültigkeitsdauer des Cookies ist das oft nicht sofort ersichtlich, im Beispiel aus About Security #151 würde die erschlichene längere Nutzungsdauer evtl. erst nach dem 16.05. auffallen. Statt so lange zu warten, ist meist ein genauer Blick auf die entsprechenden Programmteile zielführender: Wird die Lebensdauer des Cookies irgendwo als Eingabeparameter verwendet, und wenn ja, wozu?
Wurden Schwachstellen gefunden, geht es an deren Beseitigung:
Cookie-Poisoning verhindern...
... ist unmöglich: Die Cookies werden auf dem Client gespeichert, und
ein Angreifer kann alle auf dem Client gespeicherten Daten nach Belieben
manipulieren. Und das gilt nicht nur für seinen eigenen Client,
sondern mit Einschränkungen auch für die Daten eines normalen
Benutzers. Cross-Site-Scripting und Cross-Site-Request-Forgery sind in
diesem Zusammenhang die bekanntesten Probleme. Cookies lassen sich
außerdem über das sog.
Cross-Site-Cooking
manipulieren. Dabei nutzt der Angreifer eine Schwachstelle im Webbrowser
aus, um einen Cookie für eine andere Domain zu setzen. Während
normalerweise der Webserver von boese.example keinen Cookie
für eine andere Domain, z.B. gut.example, setzen darf,
führt eine Schwachstelle dazu, das ein solcher Cookie gesetzt werden
kann.
Den Erfolg des Cookie-Poisoning verhindern...
... ist eine erfolgversprechendere Strategie: Da man eine Manipulation der Cookies nicht verhindern kann, muss man die Folgen der Manipulation verhindern oder zumindest einschränken.
Dabei gilt wie immer: Den vom Client gelieferten Daten darf nicht vertraut werden. Wenn ein Benutzer z.B. nur für einen bestimmten Zeitraum auf die Anwendung zugreifen darf, dann muss die entsprechende Information auf dem Server gespeichert (und natürlich auch geprüft) werden. Das gleiche gilt für die Anzahl durchgeführter Login-Versuche sowie alle anderen derartigen Fälle: Wann immer möglich, sollten Zustandsinformationen auf dem Server gespeichert werden.
Manipulationen erkennen
Ist eine Speicherung der Daten auf dem Client unumgänglich, muss eine
Manipulation des Parameters erkannt werden. Die Frage ist nur, wie. Im
folgenden soll der zu schützende Parameter foo
heißen.
Um Manipulationen an Daten zu erkennen, verwendet man normalerweise
Authentikationssysteme (siehe About Security
#66).
Dabei wird vereinfacht ausgedrückt eine Prüfsumme berechnet,
zusammen mit den Daten gespeichert und später mit der erneut
berechneten Prüfsumme verglichen. Wurden die Daten manipuliert,
stimmen die beiden Werte nicht überein. Die Webanwendung müsste
also für alle ausgegebenen foo Prüfsummen berechnen
und diese zusammen mit foo speichern. Sendet später ein
Client ein foo samt Prüfsumme an den Server, würde
die Prüfsumme erneut berechnet und mit der gespeicherten verglichen.
Stimmen die Werte überein, wurde foo nicht manipuliert.
Das ist ziemlich aufwendig: Statt eines Werts müssen nun zwei auf dem
Client gespeichert und von der Webanwendung ausgewertet werden.
Authentikationssysteme sind in diesem Fall also nicht die erste Wahl. Wie sieht es denn mit Konzelationssystemen (siehe About Security #66) aus? Würde eine Verschlüsselung der Daten zum gewünschten Ergebnis führen? Spielen wir das doch mal durch:
1. Die Webanwendung verschlüsselt foo, bevor sie den
Parameter an den Client sendet
2. Der Client speichert den verschlüsselten Wert in einem Cookie
3. Der Client sendet den gespeicherten Wert im Rahmen eines Request an den
Server
4. Die Webanwendung entschlüsselt den empfangenen Wert und verwendet
das Ergebnis als foo
OK, das funktioniert. Und was passiert, wenn ein Angreifer den Cookie manipuliert?
3. Der Angreifer manipuliert den Wert und sendet ihn dann an den Server
4. Die Webanwendung versucht, den empfangenen Wert zu entschlüsseln.
Das schlägt fehlt - und damit auch der Angriff
Fazit: Wenn Sie die Daten vor der Übertragung an den Client verschlüsseln, kann der Angreifer sie nicht manipulieren. Eine Manipulation führt dann nur dazu, das es beim Entschlüsseln zu einem Fehler kommt und der manipulierte Wert verworfen wird.
Das auch die Verschlüsselung nicht vor jedem Angriff schützt, werden Sie in zukünftigen Folgen noch sehen. In der nächsten Folge wird ein weiterer zustandsbasierter Angriff auf die Webanwendung behandelt: Das URL-Jumping, bei dem ein Angreifer die vorgesehene Reihenfolge der besuchten Seiten verlässt.
Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!
