Web11: HTTP-Cookies und einige Sicherheitsprobleme

1. Einleitung

Cookie oder HTTP-Cookie, Web-Cookie, Browser-Cookie ist ein kleines Datenelement, das von der Website gesendet und im Browser des Benutzers gespeichert wird, wenn er diese Website durchsucht. Jedes Mal, wenn ein Benutzer eine Website lädt, sendet der Browser automatisch Cookies an den Webserver, um die Website über die vorherigen Aktionen des Benutzers zu informieren.

Cookies sind als zuverlässiger Mechanismus konzipiert, der Websites dabei hilft, sich Statusinformationen zu merken (z. B. Artikel im Warenkorb) oder Benutzeraktivitäten (einschließlich Klicks) zu speichern. Ein Link, ein Login, im Laufe der Woche, im Monat oder im Jahr besuchte Seiten usw. ).

Obwohl Cookies weder Viren übertragen noch Malware auf Ihrem Computer installieren können, wird die Verwendung von Tracking-Cookies und insbesondere Cookies von Drittanbietern als eine Möglichkeit angesehen, persönliche Informationen aus dem Browserverlauf der Benutzer zu identifizieren. Cookies können Passwörter oder Inhalte speichern, die Benutzer in HTML-Formulare eingeben, beispielsweise Kreditkartennummern oder persönliche Adressen.

Wenn ein Benutzer eine Website zum ersten Mal besucht, wird ein Cookie vom Webserver an den Browser gesendet und auf seinem Computer gespeichert. Wenn er dann auf die Website zurückkehrt, erkennt die Website ihn anhand der im Cookie gespeicherten Informationen.

Authentifizierungscookies sind eine gängige Methode, um festzustellen, ob ein Benutzer auf einer Website angemeldet ist oder nicht. Ohne einen solchen Mechanismus wird es für die Website schwierig sein, zu wissen, wann persönliche Informationen an den Benutzer gesendet werden müssen, und den Benutzer dazu zwingen, sich mehrmals anzumelden. Obwohl Authentifizierungscookies sehr praktisch sind, bieten sie Hackern die Möglichkeit, sensible Daten in Cookies auszulesen und so Aktionen auszuführen, die den Benutzern schaden.

2. Übersicht über HTTP-Cookies

2.1. Geschichte

Der Begriff Cookie leitet sich vom Begriff „Magic Cookie“ ab, bei dem es sich um unveränderliche Daten handelt, die von einem Computerprogramm gesendet und empfangen werden. Ein Programmierer namens Lou Montuli hatte 1994 die Idee, magische Cookies in der Webkommunikation einzusetzen. Damals arbeitete er für Netscape Communications an einem Projekt zur Entwicklung von E-Commerce-Anwendungen für MCI. Als Lösung beim Aufbau virtueller Einkaufswagen wurden Cookies eingesetzt, die dazu beitragen, dass die Server von MCI den Status von Transaktionen nicht speichern müssen, sondern diese stattdessen auf dem Computer des Benutzers gespeichert werden.

Zusammen mit John Giannandrea schrieb Montuli die erste Spezifikation für Netscape-Cookies. Version 0.0beta von Mosaic Netscape, veröffentlicht am 13. Oktober 1994, unterstützte Cookies. Bei der ersten Verwendung von Cookies (außerhalb des Labors) wurde überprüft, ob ein Kunde, der die Website von Netscape besuchte, die Website bereits zuvor besucht hatte oder nicht. Montuli erhielt 1995 ein Cookie-Patent. Und Internet Explorer Version 2 (veröffentlicht im Oktober 1995) beinhaltete die Verwendung von Cookies.

Die Einführung von Cookies war zu dieser Zeit noch nicht weit verbreitet. Insbesondere werden Cookies standardmäßig akzeptiert, der Benutzer wird nicht über deren Anwesenheit informiert. Die Öffentlichkeit erfuhr von Cookies erst, nachdem am 12. Februar 1996 ein Artikel darüber in der Financial Times veröffentlicht wurde. Seitdem haben Cookies große Aufmerksamkeit erhalten, insbesondere die darin enthaltenen privaten Informationen. Cookies wurden 1996 und 1997 in zwei Anhörungen der US-amerikanischen Federal Trade Commission diskutiert.

Die erste Diskussion über eine formelle Cookie-Spezifikation begann im April 1995. Zur Durchführung dieser Arbeit wurde eine spezielle Gruppe innerhalb der Internet Engineering Task Force (IETF) gebildet. Schließlich wurde die Spezifikation im Februar 1997 von der Gruppe veröffentlicht. Die Spezifikation definierte Cookies von Drittanbietern als entweder nicht für alle akzeptabel oder zumindest nicht standardmäßig aktiviert. Im April 2011 wurde im Dokument RFC 6265
die Standardspezifikation für Cookies im praktischen Einsatz veröffentlicht .

2.2. Terminologie

Sitzungscookies

Sitzungscookies, auch In-Memory-Cookies oder transiente Cookies genannt, bleiben nur im temporären Speicher bestehen, während der Benutzer auf der Website navigiert. Wenn zum Zeitpunkt der Cookie-Erstellung kein Ablaufdatum oder Gültigkeitsintervall festgelegt ist, wird ein Sitzungscookie gesetzt. Normalerweise löschen Webbrowser Sitzungscookies automatisch, wenn der Benutzer den Browser schließt.

Dauerhafte Cookies

Permanente Cookies verlängern die Sitzung des Benutzers. Wenn ein dauerhaftes Cookie auf ein maximales Alter von 1 Jahr eingestellt ist, wird während dieses Zeitraums der im Cookie festgelegte Anfangswert bei jedem Besuch der Website durch den Benutzer an den Server gesendet. Damit können wichtige Informationen erfasst werden, beispielsweise wie der Benutzer die Website zum ersten Mal besucht hat. Aus diesem Grund werden persistente Cookies auch Tracking-Cookies genannt.

Sichere Cookies

Sicheres Cookie ist ein Sicherheitsattribut, das bei der Verwendung von HTTPS aktiviert wird und sicherstellt, dass das Cookie bei der Übertragung vom Client zum Server immer verschlüsselt ist und so ein Abhören und die Preisgabe von Informationen verhindert wird. Darüber hinaus müssen alle Cookies der Same-Origin-Richtlinie des Browsers entsprechen.

HttpOnly-Cookies

Das HttpOnly-Attribut von Cookies wird von den meisten Browsern unterstützt. Ein HttpOnly-Sitzungscookie wird nur in einer HTTP- (oder HTTPS-)Anfrage verwendet, wodurch der Zugriff durch Nicht-HTTP-APIs wie Javascript eingeschränkt wird. Diese Einschränkung mildert den Cookie-Diebstahl über Cross-Site-Scripting (XSS)-Schwachstellen, beseitigt sie jedoch nicht.

Cookies von Drittanbietern

Erstanbieter-Cookies sind Cookies, die zur selben Domain (oder Subdomains innerhalb derselben Domain) gehören und in der Adressleiste des Browsers angezeigt werden. Cookies von Drittanbietern sind Cookies, die zu verschiedenen Domänen gehören und in der Adressleiste des Browsers angezeigt werden. Websites können Inhalte von Drittanbieter-Domains enthalten (z. B. Bannerwerbung), über die der Browserverlauf der Benutzer verfolgt werden kann. Die Datenschutzeinstellungen der meisten Browser blockieren Tracking-Cookies von Drittanbietern.

Angenommen, ein Benutzer besucht die Website example1.com . Diese Website enthält Werbung von ad.foxytracking.com. Beim Laden werden Cookies von ad.foxytracking.com gespeichert. Anschließend besucht er eine andere Website (example2.com), die ebenfalls eine Anzeige von ad.foxytracking.com enthält und dort ebenfalls ein Cookie von ad.foxytracking.com setzt. Schließlich werden beide Cookies an den Werbetreibenden gesendet, wenn er Anzeigen lädt oder auf seine Website zugreift. Werbetreibende können diese Cookies verwenden, um den Browserverlauf eines Benutzers auf allen Websites zu erstellen, die ihre Anzeigen enthalten.

Im Jahr 2014 gab es einige Websites, die Cookies setzten, die von mehr als 100 Domains Dritter gelesen werden konnten. Im Durchschnitt werden auf einer Website etwa 10 Cookies gesetzt, wobei die maximale Anzahl an Cookies bei über 800 liegt.

Supercookie

Ein Supercookie ist ein Cookie, das von einer Top-Level-Domain wie .com oder einem öffentlichen Suffix wie .co.uk stammt. Aus Sicherheitsgründen ist es wichtig, dass Supercookies von Browsern blockiert werden. Wenn die Blockierung aufgehoben wird, kann ein Angreifer, der eine bösartige Website kontrolliert, ein Supercookie einrichten, um sich als Benutzeranfragen auszugeben und Anfragen an andere Websites zu senden, die dieselbe Top-Level-Domain oder dasselbe öffentliche Suffix verwenden. Beispielsweise könnte ein Supercookie, der von der .com-Domain stammt, Anfragen an example.com beeinträchtigen, selbst wenn der Cookie nicht von example.com stammt. Es kann ausgenutzt werden, um Anmeldungen zu fälschen oder Benutzerinformationen zu ändern.

Zombie-Kekse

Zombie-Cookies sind Cookies, die automatisch neu erstellt werden, nachdem der Benutzer sie gelöscht hat. Dies erfolgt durch ein Skript, das den Inhalt des Cookies an einem anderen Ort speichert, beispielsweise in einem Flash-Content-Store, einem HTML5-Store oder einem anderen clientseitigen Mechanismus.

2.3. Cookie-Struktur

Ein Cookie mit einer Größe von 4 KB umfasst 7 Hauptkomponenten:

1. Name
2. Wert
3. Läuft ab (Ablaufdatum)
4. Pfad (Pfad dorthin, wo das Cookie gültig ist; „/“ bedeutet, dass das Cookie in jedem Pfad gültig ist)
5. Domain
6. Sicher
7. HttpOnly

Die ersten beiden Komponenten (Name und Wert) sind erforderlich.

2.4. Verwenden

Sitzungsverwaltung

Mithilfe von Cookies können benutzerbezogene Daten über mehrere Website-Besuche hinweg gespeichert werden. Cookies sind eine Lösung zum Erstellen eines Warenkorbs, eines virtuellen Warenkorbs, der Benutzern hilft, die von ihnen ausgewählten Artikel beim Durchsuchen von Produkten zu speichern.

Aktuelle Warenkorbanwendungen speichern die Liste der Artikel im Warenkorb häufig in der serverseitigen Datenbank, anstatt sie in einem clientseitigen Cookie zu speichern. Der Webserver sendet normalerweise ein Cookie mit der Sitzungskennung – der Sitzungs-ID (die eindeutig ist). Der Webbrowser gibt diese Sitzungs-ID mit der Einkaufsanfrage jedes Benutzers zurück.

Eine weitere Anwendung von Cookies besteht darin, Benutzern die Anmeldung auf Websites zu ermöglichen. Normalerweise sendet der Webserver dem Client beim ersten Login ein Cookie mit der Sitzungs-ID. Benutzer übermitteln ihre Informationen und die Webanwendung authentifiziert die Sitzung und ermöglicht dem Benutzer dann die Nutzung ihrer Dienste.

Cookies bieten einen schnellen und bequemen Client/Server-Interaktionsmechanismus. Einer der Vorteile von Cookies besteht darin, dass sie Benutzerinformationen in einer Datei auf dem Computer des Benutzers speichern. Dies reduziert den Speicherplatz und die Verarbeitungszeit des Servers erheblich.

Personalisiert

Cookies können verwendet werden, um sich die persönlichen Daten eines Benutzers zu merken, wenn er eine Website besucht, um diesem Benutzer bei jedem erneuten Besuch der Website relevantere Inhalte anzuzeigen.

Ein prominentes Beispiel ist die Buchempfehlungsfunktion von amazon.com. Wenn ein Benutzer auf ein Buch klickt, macht Amazon Vorschläge für die nächsten Bücher, die der Benutzer lesen sollte. Diese Vorschläge basieren darauf, welche Bücher Benutzer zuvor durchgesehen haben und welche Bücher sie zum Kauf ausgewählt haben.

Ein weiteres Beispiel ist die Suchvorschlagsfunktion der Google-Suche. Wenn Sie sich mit Ihrem persönlichen Konto anmelden und eine Suche durchführen, macht Google Vorschläge „nur für Sie“ und die gewünschten Ergebnisse erscheinen immer oben in der Liste.

Monitor

Tracking-Cookies können verwendet werden, um den Browserverlauf eines Benutzers zu verfolgen. Dies kann auch über die IP-Adresse des Computers erfolgen, der die Anfrage an die Website sendet, oder über das Referrer-Feld des HTTP-Anfrage-Headers, Cookies bieten jedoch eine höhere Präzision. Dies geschieht wie folgt:

1. Wenn ein Benutzer eine Website besucht, diese Anfrage jedoch kein Cookie enthält, geht der Server davon aus, dass der Benutzer diese Website zum ersten Mal besucht. Der Server generiert eine zufällige Zeichenfolge und sendet sie zusammen mit der angeforderten Webseite als Cookie an den Browser zurück.
2. Von diesem Zeitpunkt an wird das Cookie jedes Mal, wenn eine neue Webseite dieser Website angefordert wird, automatisch vom Browser an den Server gesendet. Der Server sendet die angeforderte Webseite wie gewohnt zurück, jedoch mit der URL dieser Webseite und dem Der Zugriff wird in einer Protokolldatei gespeichert. Durch die Analyse der in dieser Protokolldatei gespeicherten Informationen können der Browserverlauf der Person, häufig besuchte Websites und Surfgewohnheiten ermittelt werden.

2.5. Einsatz

Cookies sind Daten, die vom Server an den Browser gesendet werden. Der Browser sendet es dann jedes Mal, wenn der Benutzer eine Anfrage an die Website sendet, an den Server zurück, ohne den darin enthaltenen Inhalt zu ändern. Cookies können auch durch eine Skriptsprache, wie zum Beispiel Javascript, gesetzt werden.

Jeder Webbrowser kann mindestens 300 Cookies in einer 4-KB-Datei und mindestens 20 Cookies pro Server oder Domäne speichern.

Cookies einrichten

Webserver und Browser kommunizieren über HTTP (HyperText Transfer Protocol) miteinander. Um beispielsweise auf die Seite http://www.example.org/index.html zuzugreifen, stellt der Browser eine Verbindung zum Server her, indem er eine HTTP-Anfrage wie diese sendet:

Der Server antwortet, indem er dem Browser ein einfaches Textpaket, eine sogenannte HTTP-Antwort, sendet. Dieses Paket kann eine Zeile mit dem Inhalt des Cookies enthalten:

Set-Cookie ist ein Feld, das den Browser anweist, das Cookie zu speichern und es in Zukunft jedes Mal an den Server zu senden, wenn eine Anfrage an den Server erfolgt (sofern das Cookie noch abgelaufen ist). Beispielsweise sendet der Browser eine Anfrage an http://www.example.org/spec.html, indem er eine HTTP-Anfrage wie diese sendet:

Dies ist eine Anfrage an eine andere Seite, die zum selben Server gehört. In diesem Fall erkennt der Server, dass diese Anfrage mit der vorherigen Anfrage zusammenhängt, und antwortet, indem er die angeforderte Webseite an den Browser sendet und möglicherweise weitere Cookie-Werte hinzufügt.

Der Wert des Cookies kann vom Server geändert werden, indem er das Feld Set-Cookie: name=value in der HTTP-Antwort an den Browser sendet. Der Browser ersetzt dann den alten Cookie-Wert durch diesen neuen Wert.

Der Cookie-Wert kann jedes druckbare ASCII-Zeichen außer „“, „;“ enthalten. und Leerraum. Cookie-Namen dürfen außerdem nicht das Zeichen „=“ enthalten, da dies das Zeichen ist, das den Namen und den Wert trennt.
Der Begriff „Krümel-Cookie“ wird manchmal verwendet, um sich auf das Name-Wert-Paar eines Cookies zu beziehen.

Cookies können auch durch Javascript oder eine ähnliche Skriptsprache gesetzt werden. In Javascript wird das document.cookie-Objekt zum Setzen von Cookies verwendet. Das HttpOnly-Attribut ist dafür verantwortlich, zu verhindern, dass fehlerhafte Skripte Cookie-Inhalte lesen.

Cookie-Eigenschaften

Neben dem Name-Wert-Paar kann der Server auch eine Reihe weiterer Cookie-Eigenschaften festlegen: Domain, Path, Expirse, Max-Age, Secure und HttpOnly. Der Browser sendet diese Attribute nicht an den Server, sondern nur das Name-Wert-Paar. Anhand dieser Attribute bestimmt der Browser, wann Cookies gelöscht, blockiert oder an den Server gesendet werden sollen.

Domäne und Pfad

Domäne und Pfad bestimmen den Umfang des Cookies. Sie ermöglichen dem Browser zu bestimmen, wann Cookies an den Server gesendet werden. Wenn nicht angegeben, werden standardmäßig die Domäne und der Pfad des angeforderten Objekts verwendet. Es gibt jedoch einen Unterschied zwischen einem Cookie-Set für foo.com ohne das Domain-Attribut und einem Cookie-Set mit dem Domain-Attribut foo.com. Im ersten Fall wird das Cookie nur gesendet, wenn eine Anfrage an foo.com vorliegt. Im letzteren Fall wird das Cookie an alle Subdomains von foo.com gesendet. Das Folgende ist ein Beispiel für eine Set-Cookie-Anweisung von einer Website, nachdem sich der Benutzer angemeldet hat, von einer Anfrage an docs.foo.com:

Die erste Cookie-LSID hat kein Domänenattribut und hat den Pfad /accounts. Der Browser sendet nur dann Cookies, wenn die angeforderte Seite in docs.foo.com/accounts enthalten ist. Die verbleibenden zwei Cookies, HSID und SSID, werden an den Server zurückgesendet, wenn eine Anfrage an eine Subdomain von foo.com gestellt wird.
Cookies können auch nur für die Top-Domain und deren Sub-Domains gesetzt werden. Das Setzen von Cookies auf www.foo.com von www.bar.com aus ist aus Sicherheitsgründen nicht gestattet.

Läuft ab und Höchstalter

Das Expires-Attribut teilt dem Browser mit, wann das Cookie gelöscht werden soll. Das Datum in Expires sieht so aus: „Wdy, DD Mon YYYY HH:MM:SS GMT“. Max-Age wird auch verwendet, um das Ablaufdatum eines Cookies anzugeben. Betrachten wir das folgende Beispiel:

Das erste Cookie läuft am 15. Januar 2013 ab und wird vom Browser verwendet, wenn es abläuft. Das zweite Cookie made_write_conn läuft nicht ab und wird als Sitzungscookie verwendet. Es wird gelöscht, wenn der Browser ausgeschaltet wird. Das dritte Cookie, reg_fb_gate, hat ein Ablaufdatum in der Vergangenheit und wird sofort gelöscht.

Sicher und HttpOnly

Die Eigenschaften „Secure“ und „HttpOnly“ sind null; stattdessen zeigt ihr Vorhandensein an, dass die Basen „Secure“ und „HttpOnly“ angewendet werden.

Das Secure-Attribut sorgt dafür, dass die Cookie-Übertragung innerhalb einer verschlüsselten Verbindung erfolgt. Wenn der Webserver aus einer nicht sicheren Verbindung ein Cookie mit dem Secure-Attribut setzt, kann das Cookie dennoch von einem Man-in-the-Middle-Angriff abgefangen werden.

Das HttpOnly-Attribut weist den Browser an, Cookies nicht über eine andere Verbindung als HTTP (oder HTTPS), wie z. B. Javascript, offenzulegen, und erschwert daher den Erhalt von Cookies durch Ausnutzung von Cross-Site Scripting (XSS)-Schwachstellen. .

3. Einige Sicherheitsprobleme bei der Verwendung von Cookies

Wenn eine Website die Sitzungs-ID verwendet, um die Sitzung eines Benutzers zu identifizieren, könnte ein Angreifer möglicherweise das Cookie stehlen, um sich als Benutzer auszugeben. Hier sind einige häufige Szenarios für Cookie-Diebstahl:

Lauschen

Der Datenverkehr in einem Netzwerk kann von Dritten (außer dem Empfänger und dem Absender) abgefangen und gelesen werden. Dieser Datenverkehr beinhaltet Cookies. Erfolgt die Übertragung nicht verschlüsselt, kann ein Angreifer die im Cookie enthaltenen sensiblen Informationen auslesen. Und unter Ausnutzung dieser Informationen geben sich Angreifer als Benutzer aus, um gefährliche Aktionen wie Banktransaktionen durchzuführen.

Dieses Problem kann durch die Verwendung eines sicheren Protokolls zwischen dem Computer des Benutzers und dem Server gelöst werden – dem HTTPS-Protokoll. Der Server kann beim Setzen von Cookies das Secure-Flag verwenden. Das Cookie wird dann nur über einen verschlüsselten Kanal, beispielsweise eine SSL-Verbindung, gesendet.

Cross-Site-Scripting

Skriptsprachen wie Javascript dürfen Cookie-Werte lesen und an beliebige Server senden.

Angenommen, eine Website weist einen Cross-Site-Scripting-Fehler auf, dann können Hacker bösartigen Code wie den folgenden einfügen:

Wenn das Opfer auf den obigen Link klickt, führt der Browser das Skript im onclick-Attribut aus: Senden des Cookies des Opfers an den Server attacker.com.

Cross-Site-Scripting ist eine der häufigsten Schwachstellen von Websites (Platz drei der zehn häufigsten Schwachstellen im Jahr 2013 – laut OWASP).

Das Risiko dieser Schwachstelle kann durch Setzen des HttpOnly-Flags für Cookies begrenzt werden. Zu diesem Zeitpunkt werden Cookies nicht von Skriptsprachen abgerufen.

Fälschung standortübergreifender Anfragen

CSRF (Cross-Site Request Forgery) oder Ein-Klick-Angriff ist eine Methode zur Ausnutzung von Website-Schwachstellen, bei der nicht autorisierte Befehle von Opfern ausgeführt werden – Benutzern, die ohne ihr Wissen von der Website autorisiert wurden.

CSRF wird den Browser des Opfers dazu verleiten, HTTP-Anfragen an Webanwendungen zu senden. Falls die Sitzung des Opfers noch nicht abgelaufen ist, werden die oben genannten Anfragen mit den Authentifizierungsrechten des Opfers gestellt.

Beispielsweise tätigt das Opfer Bob Transaktionen auf der Website einer bestimmten Bank X. Fred ist der Angreifer. Dieser Typ weiß, wie die Website von Bank X funktioniert, wenn er wie folgt Geld von Konto A auf Konto B überweisen möchte:

http://bank.example.com/withdraw?account=accountA&amount=100&for=accountB

Er wird Bob eine böswillige Nachricht senden.

Wenn Bank X Benutzerauthentifizierungsinformationen in einem Cookie speichert und Bob auf den obigen Link klickt, wird Bobs Geld an Fred überwiesen.

Um dieses Risiko zu begrenzen, können Ablaufparameter für Cookies festgelegt werden.

4. Fazit

Cookies werden heutzutage in den meisten Webanwendungen verwendet. Es birgt auch potenzielle Risiken, die die Benutzer erheblich beeinträchtigen. Daher müssen wir auf Seiten des Entwicklers Cookies genau verstehen und wissen, wie man die notwendigen Parameter einstellt, damit die Anwendung sicherer gegen Hackerangriffe ist.