[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cookies und Datenschutz



In schulung.lists.fitug-debate you write:
>>    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 könnte aber anhand der Informationen bei Kenntis des Systems 
>einen relativ leichten Hack auf diese Daten ausführen ?? 

Eher nicht, aber im Einzelfall haengt das von der Anwendung ab.

Sessiondaten werden auf dem Server gespeichert und verlassen
diesen niemals. Man kann sich die Anwendung hier wie einen
Automaten aus der klassischen Automatentheorie vorstellen und
die Sessiondaten bilden in diesem Bild den internen Zustand der
Anwendung. Durch Submit von Formulardaten kann man den internen
Zustand der Anwendung transformieren in einen der vom Automaten
zugelassenen Folgezustaende.

Waehrend also bei Systemen mit HIDDEN-Variablen der Anwender
direkten Zugriff auf den Zustand der Anwendung hat, weil dieser
immer Ping-Pong zwischen Browser und Anwendung macht, ist bei
einem System mit Sessions nur noch ein indirekter Zugriff auf
die Anwendungsdaten moeglich und der Anwendungszustand kann im
Idealfall nur noch indirekt durch Zustandsuebergaenge
beeinflusst werden.

>Ferner lassen Sich diese Daten ja auch nach Aussen
>weiterreferenzieren z.b wenn man die Ziffernfolge an ein
>befreundetes System weitergibt und die Daten so gegenseitig
>abgleicht. Wenn bei diesem Abgleich ein transparentes Protokoll
>verwendet wird ...

Die Session-ID ist in der Regel schwer ratbar und von begrenzter
Gueltigkeit, sie wird ungueltig, wenn die Session kurze Zeit
nicht mehr benutzt wird. Bei Microsoft ASP ist der Timeout fuer
eine Session per Default im Bereich von 20-30 Minuten, bei
PHPLIB liegt er per Default bei 1440 Minuten, wird aber von
vielen Anwendern auf weit niedrigere Werte eingestellt. PHPLIB
erzeugt die Session-ID als MD5-Hash mit variablen Daten und
einem geheimen Salt, sodass die ID anderer Anwender schwer zu
raten sein sollte. Einige Systeme binden eine Session ausserdem
an eine IP-Nummer oder einen IP-Nummernbereich.

Mit Kenntnis einer Session-ID kannst Du auf die Sessiondaten in
der Regel nicht zugreifen, sie taugt nur als opake Referenz auf
diese Daten. Du kannst nur mittelbar Teile der Werte der
Sessiondaten deduzieren, indem Du Schluesse aus dem Verhalten
der Anwendung ziehst oder falls die Anwendung Menues enthaelt,
die Dir diese Daten in aufbereiteter Form darstellen. Beispiele
dafuer sind ein Bestellfenster, indem die Anwenderadresse je
nach Sessiondaten schon vorab eingetragen ist oder ein
Menuepunkt "Warenkorb anzeigen".

Wenn eine boeswillige Anwendung in der Session einen Page Trail
mitfuehrt (Eine Folge von Tupeln (timestamp, URL)), wird sie
ihn Dir bestimmt nicht anzeigen und Du kannst auf der Basis
einer Session-ID auch nicht auf die Existenz eines solchen
Trails schliessen.

>Nun zumindest kann man im Zusammenhang mit WWW User
>Agent/weiterleitung auserhalb der Domäne verhindern das man
>versteckt irgendwo landet und das die verhobenen Daten korrekt
>sind ??

Eine Session-ID in der URL wird bei Verweisen in IMG-Tags im
Referer-Header mit uebermittelt.

>> 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.

>Ich finde man macht den Datensammlern das leben zumindest etwas
>schwerer.

Nicht im geringsten. Jedes Application-Server Paket, das sein
Geld wert ist, funktioniert mit oder ohne Cookies gleichermassen
gut und kann dann in der Session alle moeglichen legalen oder
illegalen Dinge anstellen.

Du kannst Cookies gerne abschalten, wenn Du Dich dann besser
fuehlst. Es bewirkt wie gesagt exakt ueberhaupt nichts in Bezug
auf die Leute, auf die es ankommt, naemlich die Datensammler im
grossen Stil. Die arbeiten bevorzugt mit Cookies, weil es eher
"non-intrusive" ist und so gegenueber dem Anwender weniger
Fehlfunktionen erzeugt. Schaltet der Anwender Cookies jedoch ab,
faellt solche Software automatisch und transparent in einen
Fallback, der auch ohne Cookies funktioniert, aber etwas
fragiler ist.

>>    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).

>Wie unter NT/2000  ??

Systeme wie Webwasher oder Junkbuster setzen sich als Proxy
zwischen Dein System und das Web. Wie Dein System funktioniert
oder worum es sich dabei handelt ist vollkommen irrelevant. Es
kommt dann darauf an, eine moeglichst sinnvolle Filterstrategie
fuer einen selbst zu erarbeiten.

>Hast du weiterführende Quellen ??

Lies die einschlaegigen RFCs zum Thema HTTP, sieh Dir einige
Weblogs an und baue Dir einen Datensammler einmal selbst. Spiele
ein wenig mit netcat herum. Eigene Erfahrung ist durch nichts zu
ersetzen.

Lies http://www.koehntopp.de/kris/artikel/webtune/. Der
Abschnitt, der fuer Dich interessant ist, beginnt ab "Grenzen
von Vertrauen". Dort findest Du weiter unten auch Beispiele fuer
den Einsatz von netcat - ein ideales Analysewerkzeug, wenn Du
sehen moechtest, was Dein Browser tatsaechlich an Informationen
uebermittelt.

Kristian