Auch in Cookies auf dem Client gespeicherte Zustandsinformationen sind vor Angriffen nicht sicher. Für einen Angriff, bei dem Cookies manipuliert werden, gibt es eine eigene Bezeichnung: Cookie Poisoning. Sie erfahren hier, wie ein Angreifer die Cookies vergiften kann, und was das für Folgen für die Webanwendung haben kann.

Cookies allgemein

Bevor es um mögliche Manipulationen geht, zuerst ein paar grundlegende Informationen zu Cookies. Cookies können in vier Formen ausgeliefert werden, die alle auf einer Kombination von zwei Einstellungen basieren: Persistente bzw. nonpersistente Cookies sowie als 'secure' oder 'nonsecure' markierte Cookies. Persistente Cookies werden bis zum Ablauf ihrer Gültigkeitsdauer auf der Festplatte des Clients gespeichert, während nonpersistente Cookies nur im Speicher abgelegt und beim Schließen des Browsers gelöscht werden. Ein als 'secure' markierter Cookie darf nur über verschlüsselte HTTPS-Verbindungen übertragen werden, weitere Auswirkungen auf den Aufbau oder die Speicherung des Cookies hat diese Einstellung nicht. Entsprechend werden als 'nonsecure' markierte Cookies über normale HTTP-Verbindungen übertragen.

Speicherung von Cookies

Alle Browser speichern ihre Cookies an bekannten Orten und in einem bekannten Format. Mozilla-Browser legen ihre Cookies beispielsweise gesammelt in einer Datei mit dem Namen cookies.txt ab. Jeder Cookie wird darin in einer eigenen Zeile nach folgendem Muster gespeichert:

www.server.example TRUE / FALSE 1270321513 PREF ID=9wKKFfD3c...

Die einzelnen Felder werden durch Tabulatorzeichen getrennt und haben folgende Bedeutung:

Der Internet Explorer speichert jeden Cookie in einer eigenen Datei mit einem Namen nach dem Muster username@servername[1].txt im Verzeichnis C:\Documents and Settings\[Benutzername]\Cookies. Eine Beschreibung des Dateiformats gibt es z.B. im Paper "Forensic Analysis of Microsoft Internet Explorer Cookie Files" von Keith J. Jones (als IE_Cookie_File_Reconstruction.pdf bei SourceForge).

Manipulation von Cookies

Sowohl Mozillas cookies.txt als auch die einzelnen Cookie-Dateien des Internet Explorers kann ein Angreifer nach Belieben manipulieren, bevor er eine Seite der Webanwendung aufruft, die die darin gespeicherten Informationen verwendet.

Während bei Zustandsinformationen in versteckten Feldern oder dem URL nur der Wert des Parameters manipuliert werden konnte, kann bei Cookies auch deren Gültigkeitsdauer geändert werden. Außer der Möglichkeit, z.B. auf andere Sessions, Profile oder Ähnliches zuzugreifen, gibt es bei Cookies auch die Möglichkeit, die Dauer eines Zustands zu verlängern oder zu verkürzen. Dazu zur Veranschaulichung ein Beispiel:

Die Webanwendung auf wetter.example stellt gegen Bezahlung ausführliche Wetterberichte zur Verfügung. Die Benutzer werden über einen Cookie mit einer UserID darin identifiziert. Der Cookie ist so lange gültig, bis der vom Benutzer bezahlte Zeitraum abgelaufen ist.

www.wetter.example TRUE / FALSE 1210888800 UserID 9wKKFfD3cjE6

Die Daten aus dem Cookie werden von der Webanwendung ohne weitere Prüfungen übernommen.

Der Angreifer kann wieder die UserID manipulieren, um auf Kosten eines anderen Benutzers auf die Wetterberichte zuzugreifen. Genausogut kann er aber auch versuchen, seine Session zu verlängern. Der Unix-Timestamp 1210888800 ist der 16.05.2008 - 00:00:00. Der Angreifer könnte den Timestamp z.B. auf 1213567200 ändern und hätte damit bis zum 16.06.2008 Zugriff auf die Wetterberichte.

Die Webanwendung hat auch einen personalisierten Bereich, auf den erst nach einer erfolgreichen Authentifizierung zugegriffen werden kann. Die Anzahl fehlgeschlagener Login-Versuche wird ebenfalls in einem Cookie gespeichert:

www.wetter.example TRUE / FALSE 1210888800 Logins 4

Ein Benutzer hat 3 Versuche, danach legt die Webanwendung eine Zwangspause ein, um Brute-Force-Angriffe zu erschweren. Ab dem 4. Versuch wird vor dem Prüfen der Zugangsdaten eine Wartezeit eingefügt, die aus der Anzahl fehlgeschlagener Logins multipliziert mit 30 Sekunden berechnet wird. Der Angreifer kann das umgehen, indem er den Wert im Cookie vor jedem Anmeldeversuch auf 0 setzt. Das Ganze kann problemlos automatisiert werden, wodurch einem Brute-Force-Angriff nichts mehr im Wege steht.

In dieser Folge haben Sie erfahren, wie ein Angreifer in Cookies gespeicherte Zustandsinformationen manipulieren kann. In der nächsten Folge erfahren Sie, wie Sie diese Angriffe verhindern.

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