Montag, 2. Januar 2012


Topthema

Donnerstag, 17. April 2008 | Topthema

About Security #151: Schwachstellensuche: Cookie Poisoning

(Link zum Artikel: http://www.entwickler.de/business-technology/kolumnen/042738)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

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

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

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:

www.server.example Der Name des Webservers, der den Cookie gesetzt hat
TRUE Flag: Kann der Cookie von anderen Rechnern der Domain gelesen werden (hier: Ja)
/ Verzeichnis, für das der Cookie relevant ist (hier: Das Webroot-Verzeichnis /)
FALSE Flag für 'secure' (Übertragung nur über verschlüsselte Verbindung, hier: Nein)
1270321513 Zeitpunkt, zu dem der Cookie ungültig wird (in Sekunden seit 1. Januar 1970, 0 Uhr (Unix-Timestamp))
PREF Der Name des Cookies
ID=9wKKFfD3c... Der Wert des Cookies

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.

About Security: Die komplette Serie

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.

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

Gravatar myope 06.08.2008
um 14:46 Uhr
sollte es nicht JA heißen:

TRUE Flag: Kann der Cookie von anderen Rechnern der Domain gelesen werden (hier: Nein)
#zitieren
Gravatar Carsten Eilers 06.08.2008
um 17:42 Uhr
Allerdings.

Da habe ich wohl beim Bearbeiten einmal nicht aufgepaßt und es danach beim Korrekturlesen immer übersehen.

Vielen Dank für den Hinweise, der Fehler wird korrigiert.

MfG
Carsten Eilers
#zitieren

Folgende Links könnten Sie auch interessieren