nicht angemeldet
Cookies durch Firewall blockiert?
Hi out there,
kann mir jemand von euch genau erklären, auf welchen verschiedenen Wegen eine Website Cookies setzen (und lesen) kann?
Hintergrund: Ich sitze an meinem Arbeitsplatz hinter einer Firewall, die einige Netzwerkprotokolle (z.B. POP3, SMTP) blockiert. Auf einigen Web-Seiten werde ich darauf hingewiesen, dass ich scheinbar "Cookies disabled" hätte. In den Browsereinstellungen (MS IE5) sind aber sowohl Session- als auch dauerhafte Cookies erlaubt. Ich habe daher den Verdacht, dass auch Cookies über unsere Firewall blockiert werden. Unser Admin bestreitet das allerdings ("Ja, POP3 und SMTP haben wir blockiert, Cookies müssten aber gehen").
Und als Beinahe-Insider kann ich das Phänomen sowieso nicht richtig nachvollziehen. AFAIK werden Cookies durch Skripte innerhalb des HTML-Codes gesetzt und gelesen. Okay, der Code kann natürlich durch serverseitige Skripte dynamisch generiert sein, aber er wird auf jeden Fall erst von meinem Browser interpretiert. Also wie kann die Firewall dazwischen überhaupt Cookies aufspüren? Gibt es außer Skripten noch andere Möglichkeiten, diese Kekse zu erzeugen bzw. zu lesen? Komisch ist auch, dass trotz aller Blockaden eben doch ab und zu etwas im Cookie-Verzeichnis auftaucht, aber da kann ich keine Regelmäßigkeit erkennen.
Wer kennt sich mit dem Thema aus?
Danke im Voraus,
Martin
-
Hoi,
kann mir jemand von euch genau erklären, auf welchen
verschiedenen Wegen eine Website Cookies setzen (und lesen)
kann?Es gibt zwei Moeglichkeiten: HTTP-Kommunikation und JavaScript. Man
kann Cookies mit JavaScript setzen, schreiben und
lesen (http://selfhtml.teamone.de/javascript/objekte/document.htm#cookie)
oder ueber die HTTP-Header 'Set-Cookie' schreiben. Ausgelesen werden
koennen sie serverseitig nur ueber den Antwort-Header: 'Cookie'.Hintergrund: Ich sitze an meinem Arbeitsplatz hinter einer
Firewall, die einige Netzwerkprotokolle (z.B. POP3, SMTP)
blockiert.Cookies sind kein Protokoll. Sie sind vielmehr eine Erweiterung
des HTTP-Protokolls. Wenn das ungefiltert durchgelassen wird, dann
funktionieren Cookies auch wie gewohnt.Und als Beinahe-Insider kann ich das Phänomen sowieso nicht
richtig nachvollziehen. AFAIK werden Cookies durch Skripte
innerhalb des HTML-Codes gesetzt und gelesen.Das HTML hat damit nichts zu tun, bzw. nur bedingt, naemlich nur
dann, wenn Cookies per JS gesetzt werden. Ansonsten laeuft alles
auf HTTP-Ebene ab.Okay, der Code kann natürlich durch serverseitige Skripte
dynamisch generiert sein, aber er wird auf jeden Fall erst von
meinem Browser interpretiert. Also wie kann die Firewall
dazwischen überhaupt Cookies aufspüren?Natuerlich. Eine Firewall/ein Proxy kann die Pakete, die ueber sie/
ueber ihn laufen, beliebig veraendern. Unser Firmen-Proxy z. B.
downgraded HTTP/1.1 auf HTTP/1.0 und enfernt aus dem Accept-Encoding
das gzip, damit er die Inhalte filtern kann.Gibt es außer Skripten noch andere Möglichkeiten, diese Kekse zu
erzeugen bzw. zu lesen?Natuerlich. Einige HTTP-Server senden in ihrer Default-Konfiguration
einen Cookie (Lotus Domino).Komisch ist auch, dass trotz aller Blockaden eben doch ab und zu
etwas im Cookie-Verzeichnis auftaucht, aber da kann ich keine
Regelmäßigkeit erkennen.Dann stimmt vielleicht etwas mit deinem System nicht.
Gruesse,
CK-
Hi Christian,
aus Deiner Antwort und aus der von Henryk kriege ich so langsam eine recht klare Vorstellung von der Geschichte.
Komisch ist auch, dass trotz aller Blockaden eben doch ab und zu
etwas im Cookie-Verzeichnis auftaucht, aber da kann ich keine
Regelmäßigkeit erkennen.Dann stimmt vielleicht etwas mit deinem System nicht.
Oder es sind Cookies, die per JS dort gelandet sind.
Danke fürs Nachdenken,
Martin
-
-
Moin,
Hintergrund: Ich sitze an meinem Arbeitsplatz hinter einer Firewall, die einige Netzwerkprotokolle (z.B. POP3, SMTP) blockiert. Auf einigen Web-Seiten werde ich darauf hingewiesen, dass ich scheinbar "Cookies disabled" hätte. In den Browsereinstellungen (MS IE5) sind aber sowohl Session- als auch dauerhafte Cookies erlaubt. Ich habe daher den Verdacht, dass auch Cookies über unsere Firewall blockiert werden. Unser Admin bestreitet das allerdings ("Ja, POP3 und SMTP haben wir blockiert, Cookies müssten aber gehen").
Wenn er es nicht weiss dann hat er keine Cookies blockiert, s.u.
Und als Beinahe-Insider kann ich das Phänomen sowieso nicht richtig nachvollziehen. AFAIK werden Cookies durch Skripte innerhalb des HTML-Codes gesetzt und gelesen. Okay, der Code kann natürlich durch serverseitige Skripte dynamisch generiert sein, aber er wird auf jeden Fall erst von meinem Browser interpretiert. Also wie kann die Firewall dazwischen überhaupt Cookies aufspüren? Gibt es außer Skripten noch andere Möglichkeiten, diese Kekse zu erzeugen bzw. zu lesen? Komisch ist auch, dass trotz aller Blockaden eben doch ab und zu etwas im Cookie-Verzeichnis auftaucht, aber da kann ich keine Regelmäßigkeit erkennen.
Jein, die Cookies kommen normalerweise als HTTP-Header ("Set-Cookie: ") ins Haus respektive den Browser geflattert und verlassen ihn auf die selbe Weise wieder. Normalerweise macht also der Server was damit. Darüberhinaus gibt es noch die Möglichkeit in JavaScript mit document.cookie auf den Keks für das aktuelle Dokument zuzugreifen.
Eine stinknormale Firewall, also ein Paketfilter, kann da nicht drin rumpfuschen. Da kann man bestenfalls HTTP ganz und gar verbieten.
Um an den HTTP-Header rumzuspielen, müsste die Firewall auch auf dieser Ebene arbeiten, also eine Application Layer Firewall oder ein transparenter Proxy.Wenn euer Admin sowas betreibt, dann weiss er mit ziemlicher Sicherheit davon (das Ding war dann nämlich teuer oder zumindest kompliziert selbst zu bauen).
Ich tippe mal auf andere Ursachen:
- Das Skript dass dir das sagt ist falsch programmiert. (wahrscheinlich)
- Du hast deinen Browser angewiesen bestimmte Cookies nicht zu aktzeptieren
- Du hast noch was anderes auf deinem Rechner laufen was dir deine Privatsphäre sichern will.
--
Henryk Plötz
Grüße aus Berlin-
Hallo Henryk,
du hast mich auf jeden Fall schon mal auf eine neue Fährte geführt.
... Cookies kommen normalerweise als HTTP-Header ("Set-Cookie:") ins Haus respektive den Browser geflattert und verlassen ihn auf die selbe Weise wieder. Normalerweise macht also der Server was damit.
Verdammt! :-|
Darüberhinaus gibt es noch die Möglichkeit in JavaScript mit document.cookie auf den Keks für das aktuelle Dokument zuzugreifen.
Das mit dem HTTP-Header für Cookies war mir nicht so ganz klar, danke. Die JS-Methode dagegen kannte ich.
... bestenfalls HTTP ganz und gar verbieten.
Und das wäre ja kompletter Quatsch.
... oder ein transparenter Proxy.
Sorry, das hatte ich wirklich nur oberflächlich erwähnt: Ich weiß nicht genau, was da läuft (unsere Leute geben sich da auch recht zugeknöpft), aber es ist auf jeden Fall Firewall und Proxy in einem.
Wenn euer Admin sowas betreibt, dann weiss er mit ziemlicher Sicherheit davon (das Ding war dann nämlich teuer oder zumindest kompliziert selbst zu bauen).
Teuer, nehme ich an. Und ich nehme auch an, dass er recht genau weiß, was er da hat. Aber ich denke, er mauert, will das Fußvolk dumm halten.
Ich tippe mal auf andere Ursachen:
- Das Skript dass dir das sagt ist falsch programmiert. (wahrscheinlich)
Eher unwahrscheinlich, da es viele verschiedene Sites sind (u.a. Google News)
- Du hast deinen Browser angewiesen bestimmte Cookies nicht zu aktzeptieren
Nicht dass ich wüsste... ;)
- Du hast noch was anderes auf deinem Rechner laufen was dir deine Privatsphäre sichern will.
Höchstens wenn unsere hausinterne EDV meinem Windows NT "administrativ" was aufzwängt - aber dann hätte ich keinen Einfluss darauf.
Aber vielen Dank für die ausführliche Info!
Gruß aus dem Schwobaländle,
Martin