Bei dem “Cookie Identifier” handelt es sich um eine Erweiterung des Penetrationstest-Werkzeugs Burp Suite der Firma PortSwigger. Die Burp Suite wird häufig für technische Tests von Webanwendungen eingesetzt.

Diese Erweiterung wertet die Cookie-Nutzung einer Webanwendung statistisch aus. Der folgende Screenshot zeigt die Erweiterung in Aktion und das Ergebnis einer statistischen Auswertung der Cookie-Nutzung der Webanwendung meines Mail-Providers (Hosteurope bzw. Squirrelmail).

Ueberblick

Download

Was ist ein Cookie

Webanwendungen nutzen für den Datenaustausch mit den Web-Browsern der Anwender das Protokoll HTTP. Dieses ist zustandslos, sodass mehrere nacheinander ausgeführte Seitenaufrufe einem Benutzer nicht zugeordnet werden können. Daher sind für Webanwendung die Seitenaufrufe ohne weitere Hilfsmittel keinem Benutzer eindeutig zuordbar. Prinzipiell ist es denkbar z. B. die IP-Adresse als Identifikationsmerkmal zu nutzen, jedoch verwenden Unternehmen häufig sogenannte Proxy-Server für den Zugang zum Internet. Besuchen mehrere Anwender hinter diesem Proxy eine Webanwendung im Internet, so kommen alle Anwender von derselben IP-Adresse des Proxy-Servers und sind somit nicht eindeutig identifizierbar.

Für diesen Zweck werden sogenannte Cookies eingesetzt. Dabei handelt es sich im Wesentlichen um kurze, zufällige Zeichenketten (z. B. JSESSIONID=8BBB305DE91046A4A37A5D1EA23305E3), die von der Webanwendung bei dem ersten Aufruf einer Seite im Browser des Benutzers gespeichert werden und den Benutzer eindeutig identifizieren sollen. Bei jedem weiteren Seitenaufruf des Benutzers wird dieses Cookie als eindeutiges Benutzermerkmal erneut von dem Browser an die Webanwendung übertragen. Auf diese Weise kann die Webanwendung nachfolgende Seitenaufrufe einem Benutzer zuordnen.

Verwendung von Cookies

Ein Cookie kann für sehr vielfältige Zwecke eingesetzt werden. Im Folgenden werden einige Nutzungsmöglichkeiten vorgestellt:

  • Authentisierungsmerkmal: Häufig wird ein Cookie zur Authentisierung als die sogenannte SessionID bezeichnet. Hierbei handelt es sich um das Sicherheitsmerkmal nach erfolgter Anmeldung an der Webanwendung (ähnlich den Zugangsdaten). Beispiel:
  • Benutzerverfolgung: Cookies können zur Profilerstellung für Marketingzwecke und eine Optimierung des Web-Angebots genutzt werden (z. B. Einblendung von maßgeschneiderter Werbung). Beispiel:
  • Load Balancer: Nutzt ein Dienst zur Verteilung der Last durch Seitenaufrufe vieler Benutzer einen sogenannten Load Balancer, so kann ein solches Load Balancer-Cookie dazu dienen, dass die Anfragen eines Benutzers immer zu demselben Server und derselben Dienste-Instanz im Backend führen. Auf diese Weise gehen interne Zustände im Backend durch ungewollte Sprünge zu anderen Instanzen nicht verloren (z. B. der Warenkorb). Beispiel:
  • Konfigurationsspeicher: Ein Cookie kann auch für den Zweck einer clientseitigen Speicherung von Konfigurationseinstellungen genutzt werden (z. B. Spracheinstellungen: lang=de). Hierbei sei angemerkt, dass sicherheitsrelevante Einstellungen ausschließlich serverseitig hinterlegt sein sollten. Ein Identifikationsmerkmal (z. B. die SessionID; siehe oben) sollte in diesem Fall der Webanwendung zur Zuordnung der serverseitig gespeicherten Einstellungen zu einem Benutzer dienen.

Auswertung von Cookies

Um die Funktion eines Cookies festzustellen, werden im ersten Schritt alle durch die Webanwendung gesetzten Cookies gesammelt und in einer Datenbank (SQLite) gespeichert. Darüber werden die folgenden Auswertungen durchgeführt:

  • Auflistung der gesetzten Cookies in einer ResponseIdentifierteCookiesRequest
  • Auflistung und Anzahl aller gesetzten Cookies einer DomäneIdentifizierteCookiesDomain
  • Auflistung und Anzahl aller gesetzten Cookies mit eindeutigen URL-PfadenIdentifizierteCookiesDomainUndURL
  • Auflistung und Anzahl aller gesetzten Cookies mit gesetztem Expires-Flag auf den “1.Jan 1970” (Direktive zur clientseitigen Löschung des Cookies)IdentifizierteCookiesDomainUndURLExpires

Auf diese Weise erhält ein Pentester eine Übersicht über die Cookie-Nutzung der Webanwendung. So ist es nun möglich auf Grundlage der Auswertungen auf die Bedeutung und Funktion der unterschiedlichen Cookies zu schließen. So wird beispielsweise eine SessionID besonders bei der Login-URL häufig gesetzt werden. Dagegen werden andere Cookies gehäuft bereits auf der Startseite gesetzt, sodass es sich vermutlich um Cookies zur Benutzerverfolgung handelt. Aufgrund der letzten Statistik (Expires-Flag) lässt sich feststellen, ob Cookies auch clientseitig wieder gelöscht werden. Dies kann ein Hinweis auf ein sicherheitsrelevantes Cookie sein.

Technische Hintergründe

Bei der “Cookie Identifier”-Erweiterung handelt es sich um ein Modul für den passiven Scanner der Burp Suite. Passiv bedeutet, dass die mitgeschnittenen Requests und Responses offline ausgewertet werden. Es werden keine neuen Requests an die Webanwendung abgesandt. Die Erweiterung identifiziert Cookies anhand der Suche nach der Direktive “Set-Cookie” in den Responses. Anschließend werden diese in einer SQLite-Datenbank gespeichert. Diese Datenbank befindet sich in dem aktuellen Arbeitsverzeichnis und wird bei dem Laden der Erweiterung automatisch angelegt. Die Datei bleibt auch nach dem Beenden der Burp Suite erhalten und kann auch mit externen Tools ausgelesen werden, jedoch wird diese bei erneutem Laden der Erweiterung überschrieben.

Nutzung der Erweiterung

Zur Einbindung der Erweiterung in die Burp Suite wird die SQLite-Bibliothek “sqlite-jdbc-3.7.2.jar” benötigt, die kostenlos heruntergeladen werden kann. Diese sollte nun in dem Installationsverzeichnis der Burp Suite gespeichert werden. Anschließend muss die Burp Suite mit folgenden Java-Parameter gestartet werden, sodass die SQLite-Bibliothek der Burp Suite bekannt ist:

Bekannte Fehler

Enthalten die Cookies SQL-Metazeichen (z. B. ‘), so werden diese bei der Speicherung der Cookies in der SQLite-Datenbank nicht von der Erweiterung escaped und somit fehlerhaft als SQL-Befehl interpretiert. In der Regel sollte hier eine entsprechende Fehlermeldung ausgegeben werden. Im schlimmen Fall werden falsche Daten in die Datenbank geschrieben bzw. das Cookie von der Datenbank unvollständig erfasst. Im schlimmsten Fall wird die gesamte Datenbank gelöscht. Allerdings würde dies voraussetzen, dass ein entsprechender Angriff gegen die Datenbank gefahren wird (z. B. Set-Cookie: sqlinjection=’–; drop db;). Es ist bereits geplant dies zukünftig nachzubessern.

Über Vorschläge und Verbesserungsmöglichkeiten würde ich mich freuen (z. B. zusätzliche Auswertungen), ebenso wie über Fehlerberichte, sodass ich diese ggf. beheben kann.