Subject: Re: Cookies und Datenschutz
From: Kristian Koehntopp (kris@koehntopp.de)
Date: Sun Nov 28 1999 - 10:57:00 CET
In schulung.lists.fitug-debate you write:
>Die cookies-Datei dient AFAIK dazu, die Informationen
>zwischen zwei Sessions zu erhalten. Solange Netscape läuft,
>werden die cookies genutzt.
So ist es.
Es gibt zwei Sorten von Cookies: Die mit einer Zeitangabe
(lifetime) und solche ohne. Cookies mit einer Zeitangabe haben
eine Lebensdauer bis zum Ablauf des Verfallsdatum. Sie werden in
der cookies.txt gespeichert, wenn der Browser beendet wird, um
dann beim naechsten Neustart erneut gelesen (und ggf. garbage
collected) zu werden. Cookies ohne Zeitangabe haben eine
Lebensdauer, die mit der Lebensdauer des Browserprozesses
identisch ist. Sie werden niemals in der cookies.txt gespeichert
und sie haben kein festes Ablaufdatum.
Wenn man die cookies.txt schreibschuetzt oder nach /dev/null
linked, verhindert man die Speicherung von Cookies mit
Lebensdauer. Man behaelt also Warenkorbfunktionalitaet, weil man
"Session-Cookies" weiter akzeptiert und zuruecksendet. Man
verliert aber Autologin-Cookies und GUID-Cookies.
Wenn man stattdessen Cookies im Browser abschaltet, verliert man
alle Cookie-Funktionalitaet. Warenkoerbe, die sich bei der
Korrelation von Seiten ausschliesslich auf Cookies verlassen,
funktionieren dann nicht mehr. Ausgefeiltere Systeme lassen sich
auch davon nicht beirren, sondern schalten transparent auf eine
Weitergabe der Session-ID in der URL um (PHPLIB, Microsoft ASP
mit Cookie Munger Extension, Apple/Next Webobjects und andere).
Damit hat man dann die Funktionalitaet von Session Cookies mit
anderen Mitteln, es sei denn, der Anwender bookmarked eine
solche Session-ID-haltige URL - in diesem Fall hat man eine
GUID.
Warum setzen Webanwendungen Session-IDs als Cookies oder Teile
der URL ein?
Sie wollen eine Folge von Zugriffe Deines Systems korrelieren,
also alle Zugriffe Deines Browsers von den Zugriffen aller
anderen Browser im gleichen Zeitraum unterscheiden koennen,
Deinem Browser also eine unverwechselbare Identitaet geben. Man
kann sich diese unverwechselbare Identitaet als Kennnummer
vorstellen, PHPLIB verwendet zum Beispiel einen MD5-Hash eines
Timestamps mit einem geheimen Saltwert. Ueber diese Kennung kann
die Anwendung dann einen Datensatz mit Variablen in einer
Datenbank referenzieren, etwa einen Warenkorb oder andere Daten,
die im Laufe einer Folge von Zugriffe akkumuliert worden sind.
+-#19--+
+-#18--+|
+-#17--+<----- GET /shop/index.php3?ID=17 --- Browser
| Cart |||
| ||+
| |+
+------+
An diesem Szenario sind verschiedene Dinge wichtig, wenn man
lernen moechte, seine Privatsphaere zu schuetzen:
1. In dem Cookie selbst sind keine personenbezogenen Daten
gespeichert. Es ist nicht der Cookie oder sein Wert, der
gefaehrlich ist oder der geschuetzt werden muss. Der Cookie
selbst enthaelt nur irgendeine zufaellige, aber eindeutige
Nummer.
Die personenbezogenen Daten sind in einer Datenbank auf
dem Webserver gespeichert und verlassen dieses System auch
niemals; jedenfalls nicht in Richtung Browser des Anwenders.
Man selbst bekommst also auch niemals zu sehen, was genau
in der Anwendung auf dem Webserver gespeichert ist, man kann
diese Daten mit der ID nur referenzieren.
2. Cookies sind nur eine von mehreren Moeglichkeiten, Browser
so zu brandmarken, dass eine Folge von Zugriffen
unterscheidbar von allen anderen konkurrenten Folgen wird.
Bekannt sind die folgenden drei Verfahren:
a) Cookies
GET /shop/index.php3
Cookie: ID=17
b) GET-Parameter in der URL
GET /shop/index.php3?ID=17
c) PATH_INFO-Komponenten in der URL oder an anderen Stellen
im URL-String (unter Einsatz von mod_rewrite)
GET /shop/index.php3/id/17
PHPLIB und Microsoft ASP verwenden standardmaessig Verfahren
a. PHPLIB kann automatisch auf Verfahren b umschalten, wenn
der Anwender Cookies abgeschaltet hat. Microsoft ASP kann
optional mit dem Microsoft Cookie Munger ausgeruestet werden
und verhaelt sich dann wie c (glaube ich). Amazon verwendet
Verfahren c.
Cookies abzuschalten nuetzt also exakt nichts, wenn man
die Erfassung von Sessiondaten verhindern moechte, da gute
Installationen dann automatisch auf ein Fallback mit Hilfe
eines anderen Verfahrens zurueck schaltet. Diese Verfahren
sind fragiler als Cookies; Cookies sind genau fuer diese
Aufgabe (eine Session-ID zur Referenzierung von Session-Datensaetzen
in einer Datenbank transportieren) geschaffen worden.
Schlechte Webshops funktionieren mit abgeschalteten Cookies
gar nicht mehr. Man beraubt sich also im Namen einer nicht
funktionierenden Methode zur Wahrung der eigenen Privacy der
Moeglichkeiten, im Internet Einkaufen zu gehen oder
komplexere Webanwendungen zu nutzen (es gibt schliesslich
noch mehr sinnvolle Anwendungen fuer Session-Variablen als
Warenkoerbe).
Man propagiert auf diese Weise auch schlechte Webanwendungen,
weil viele schlechte Installationen nun dazu uebergehen,
Anwendungsdaten eben nicht in einer Datenbank lokal auf dem
Server zu halten, sondern als Hidden-Variablen von Seite zu
Seite mitzuschleppen - bei diesem Verfahren kreuzen interne
State-Variablen einer Anwendung bei jedem Seitenwechsel die
Trust-Boundary eines Systems und muessen entweder jedesmal
neu validiert werden (macht niemand) oder werden zu einem
Sicherheitsrisiko, weil sie benutzt werden koennen, um die
Site aufzumachen. Das nuetzt dem Kunden, dessen
Kreditkartennummer auf dem Server gespeichert ist, auch
nicht.
3. Seine Privacy schuetzt man also nicht durch das Abschalten
von Cookies: Zum einen koennen Gute wie Boese mit anderen
Verfahren als Cookies weiter korrelieren, zum anderen macht
man sich das Leben nur unnoetig unbequem.
Seine Privacy schuetzt man, indem man mit den Leuten, die
ungewollt Daten ueber einen Speichern nicht mehr redet. Das
bedeutet, man installiert sich einen Junkbuster oder
Webwasher als lokalen Proxy und erdet dort alle Zugriffe, die
in Richtung von Systemen gehen, die man als Rogue erachtet,
z.B. Doubleclick, Adfly, Flycast und wie sie alle heissen.
(Blocken von allen Zugriffen auf *doubleclick* und so weiter)
Man kann ausserdem sein System so konfigurieren, dass es
Set-Cookies, die nicht an HTML-Dateien haengen, automatisch
ausfiltert und dass es vorhandene Cookies ausfiltert, wenn
diese an Requests von Bilddateien haengen. (Ausfiltern von
Set-Cookie-Zeilen in allen Responses, wenn der Content-Type
nicht text/html ist schaltet ankommende Cookies an
GIF-Bildern und dergleichen aus; Ausfiltern von
Cookie-Zeilen in Requests, wenn es sich um einen "GET /*gif"
handelt, schaltet abgehende Cookies in GIF-Bildern und
dergleichen aus).
Man kann zusaetzlich verhindern, dass das eigene System
Requests fuer Bilddateien absendet, wenn die letzten zwei
Komponenten der Domain im GET-Request nicht mit den letzten
zwei Komponenten der Domain des Referers uebereinstimmt.
(Blocken von Requests fuer "GET /1x1.gif; Host:
www27.doubleclick.com", wenn "Referer:
http://www.kunde.de/artikel/art17.html").
Die Grundidee ist es wie gesagt, nicht den Mechanismus
auszuschalten, denn der ist _nicht_ boese und das ist auch
nicht wirksam, sondern stattdessen korrekterweise und viel
wirksaber die Abuser des Mechanismus zu schneiden.
4. Ausserdem kann bei der Gelegenheit auch gleich noch die
Animation in animierten Gifs wegschneiden und alle remoten
1x1 Placeholder-GIFs durch lokale welche ersetzen. :-)
Kristian (Autor PHPLIB; http://phplib.netuse.de, Anwender von
Junkbuster und auf der Suche nach einem besseren Tools als JB)
This archive was generated by hypermail 2b25 : Tue Dec 28 1999 - 12:40:42 CET