summary: Praktikum 1 - Hinweis 6 id: hint_1_6 categories: Hinweise tags: Wireshark status: Draft authors: Rolf Winter analytics account: UA-50831568-1

Hinweise zum Praktikum 1

Hinweis 1

Duration: 1:00

HTTP Anfragen mir Cookies findet man mit http.cookie. Damit beinhalten insgesamt 8 Anfragen einen Cookie. Das Pendant dazu, also Server die Cookies setzen findet man übrigens mit http.set_cookie. Schauen Sie sich die Cookies, aber auch die Werte der Set-Cookie-Header genauer an. Sehen Sie, wie hier Informationen strukuriert angegeben werden?

Hinweis 2

Duration: 6:00

Die Struktur von Cookies ist relativ einfach gehalten. Im Grunde sind es Schlüsselwort/Wert-Paare, die durch ein Gleichheitszeichen (=) getrennt werden und mehrere dieser Paare werden durch ein Semikolon getrennt. Diese Cookie-Paare werden von Wireshark auch einzeln dargestellt, wenn man in der Detailansicht den Cookie-Header aufklappt.

Wenn Sie sich mal die Set-Cookie-Header genauer anschauen, wird Ihnen vielleicht auffallen, dass diese meist mehr Cookie-Paare enthalten, als die Cookie-Header. Das liegt daran, dass einige Cookie-Schlüsselworte reserviert sind, und dem Browser erklären, wie mit den Cookies umgegangen werden soll.

Auch in der vorliegenden Paketaufzeichnung gibt es ein Beispiel dazu. Wenn Sie mit dem Filter http.set_cookie arbeiten und sich einfach mal das letzte Paket anschauen (Paketnummer 1869), dann sollten Sie diesen Set-Cookie-Header sehen:

set-cookie: deuxesse_uxid=bbb5a1570fac8452ea5a621304a39a1f02567dff6d44ef3f73a1558c1e8d5ab8; Expires=Wed, 22-Apr-2020 12:22:16 GMT; Domain=.twiago.com; Path=/; SameSite=None; Secure

Darin befinden sich also folgende Cookie-Paare (wobei letzteres ohne Wert ist):

1. deuxesse_uxid=bbb5a1570fac8452ea5a621304a39a1f02567dff6d44ef3f73a1558c1e8d5ab8
2. Expires=Wed, 22-Apr-2020 12:22:16 GMT
3. Domain=.twiago.com
4. Path=/
5. SameSite=None
6. Secure

Schauen wir uns an, wie der Cookie vom Browser genutzt wird. Dazu kann man z.B. folgenden Filterausdruck verwenden:

http.cookie contains "deuxesse_uxid=bbb5a1570fac8452ea5a621304a39a1f02567dff6d44ef3f73a1558c1e8d5ab8"

(auch nur ein Bruchteil des Cookie-Strings würde reichen)

Wenn wir in den HTTP-Teil eines der angezeigten Pakete schauen und nach dem Cookie-Header ausschau halten, dann ist das einzige Cookie-Paar das vom Browser verschickt wird nur dieses:

deuxesse_uxid=bbb5a1570fac8452ea5a621304a39a1f02567dff6d44ef3f73a1558c1e8d5ab8

Die anderen sind reservierte Cookie-Schlüsselwörter, die beim Management der Cookies durch den Browser helfen, z.B. wie lange der Cookie gültig ist (Expires) oder zu welchen Servern der Cookie geschickt werden darf (Domain, hier twiago.com und beliebige Subdomains unter twiago.com). Fehlt Domain, dann wird der Cookie nur zur gleichen Origin geschickt (Origin = gleiches Schema, Host und Port). Path gibt an, für welche Pfade (Ressourcen) der Cookie gesendet werden soll (hier alles ab /, also effektiv immer). Secure bedeutet, dass der Cookie nur über HTTPS und damit (unter anderem) verschlüsselt übertragen werden darf

Der SameSite-Teil ist heutzutage ein wichitger Schutzmechanismus. Er bestimmt, ob Ressourcen die von einer anderen Seiten beinhaltet sind den Cookie zugeschickt bekommen. Also wenn z.B. www.evil.com eine Ressource von www.example.com beinhaltet, z.B. durch einen Link oder ein Bild, oder dynamisch durch JavaScript, ob in diesen Fällen der Cookie an www.example.com geschickt wird. Hier im Beispiel wird das für diesen Cookie erlaubt.

Auch interessant, es darf mehr als nur ein Set-Cookie-Headerfeld im HTTP-Header vorkommen (z.B. Paket mit der Nummer 731).