Wie Sie die in About Security #151 vorgestellten Cookie-Poisoning-Schwachstellen finden und was Sie gegen derartige Angriffe unternehmen können, erfahren Sie in dieser Folge.

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 Poisonings 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 aufwändig: 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 Requests 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 fehl – 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, dass es beim Entschlüsseln zu einem Fehler kommt und der manipulierte Wert verworfen wird.

Dass 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.

Carsten Eilers

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

• About Security #149: Schwachstellensuche: Zustandsinformationen
• 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