nicht angemeldet
Cookie-Blockade in der Hierarchie oberhalb des Browsers ?
0 
suit
0 0 
Der Martin
Cookie-Blockade in der Hierarchie oberhalb des Browsers ?
Hallo,
gibt es evtl. Filter / Firewalls / Antispy-Software etc., die die Übertragung
von Cookies (evtl. von nicht zugelassenen Seiten) an den Server auf Protokoll-Ebene unterbinden?
Wir schmieden seit geraumer Zeit an einer Webanwendung, die sich hier lokal auch jederzeit schön testen lässt, nun kam es jedoch dazu, dass gleich bei zwei Tests der Anwendung in anderen Firmennetzwerk nach dem Login und einem Klick auf einen Menü-Link ein Logout stattfand.
Wir haben die Szenarien durchgespielt und sind zum Ergebnis gekommen, dass der Fall eigntlich nur dann eintreten kann, wenn Cookies deaktiviert sind. Nun deaktiviert eigentlich kein normaler User absichtlich seine Cookies im Browser und so kam der Gedanke auf, dass hier irgendwelche Filter verantwortlich sein könnten... Weiß dazu jemand was?
MfG Michael
-
Nun deaktiviert eigentlich kein normaler User absichtlich seine Cookies im Browser und so kam der Gedanke auf, dass hier irgendwelche Filter verantwortlich sein könnten... Weiß dazu jemand was?
Da gibts sicher Proxy-Server oder Packet-Inspection-Firewalls die einfach dei HTTP-Header um Cookies kastrieren - das ist nicht sonderlich schwer, weil alles im Klartext läuft.
-
Kann es möglicherweise sein, dass ihr versucht habt, das Cookie in eine andere Domain zu setzen?
Wie setzt Ihr denn die Cookies? javascript:document.cookie=...? oder per HTTP-Header?
Gruß, LX
--
RFC 1925, Satz 3: Mit ausreichendem Schub fliegen Schweine ganz wunderbar. (...) -
Hi,
gibt es evtl. Filter / Firewalls / Antispy-Software etc., die die Übertragung von Cookies (evtl. von nicht zugelassenen Seiten) an den Server auf Protokoll-Ebene unterbinden?
ja, selbstverständlich. Eine Zeitlang war der Proxomitron sehr beliebt und verbreitet, aber auch jeder andere Proxy mit frei konfigurierbaren Filterregeln könnte das leisten.
Ich war übrigens selbst fast zehn Jahre in einem Unternehmen tätig, wo ich zwar Internet-Zugang hatte, jedoch der firmeneigene Proxy (ohne den es keine Verbindung gab) fleißig Cookies gefiltert hat. Anfangs alle; später, nachdem sich genug Nutzer beschwert hatten, wurden sie von ausgewählten Sites erlaubt.Und auch so manche Desktop-Firewall bietet die Möglichkeit, Cookies generell oder URL-spezifisch zu blockieren.
Ciao,
Martin--
Die letzten Worte des Fallschirmspringers:
ELENDE SCHEISSMOTTEN!!
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
[latex]Mae govannen![/latex]
ja, selbstverständlich. Eine Zeitlang war der Proxomitron sehr beliebt und verbreitet, aber auch jeder andere Proxy mit frei konfigurierbaren Filterregeln könnte das leisten.
Besser die aktuellere deutsche Distribution verwenden.
Stur lächeln und winken, Männer!
Kai--
Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken
in Richtung "Mess up the Web".(suit)
SelfHTML-Forum-Stylesheet -
Hallo zusammen, danke für Eure Hinweise!
Die eigentliche Cookie-Verwaltung läuft serverseitig (GlassFish / Struts 2), lediglich der inzwischen eingebaute Cookie-Check beim Start der Anwendung bedient sich JavaScripts.
Wenn es also an so einem Filter liegt, wäre das jetzt zwar einerseits gut (weil es dann ja höchstwahrscheinlich nicht direkt an der Anwendung liegt, es sich also zumindest mal um keinen internen Fehler handelt), andererseits aber auch wieder nicht ganz so gut, weil die Anwendung dann in derartig gefilterten Netzwerken nun mal nicht funktioniert und man bei jedem Probetermin erst den Filter beim Haus-Admin abschalten lassen muss. :)
Interessant wären für uns jetzt noch die Namen von ein paar hierbei relevanten und zugleich einigermaßen verbreiteten Produkten wie z.B. Proxomitron, welches der Martin schon erwähnt hat, um hierfür ggf. sowohl ein paar Tips in die Anwendung einzubauen (bisher kommt einfach nur ein Screen "Cookies deaktiviert, zum Starten bitte mal anschalten!" ;) ) als auch etwaige Admins (grad solche, die noch nicht so lang dabei sind) direkt darauf ansprechen zu können.
ciao Michael
-
Tach,
Die eigentliche Cookie-Verwaltung läuft serverseitig (GlassFish / Struts 2), lediglich der inzwischen eingebaute Cookie-Check beim Start der Anwendung bedient sich JavaScripts.
ich fände es logisch, statt die Schuld beim Kunden zu suchen, die Anwendung so anzupassen, dass sie die Session-ID dann halt in der URL mitschleppt statt im Cookie; gerade in einem JavaEE-Kontext ist das doch dank response.encodeURL() nicht übermäßig schwer.
mfg
Woodfighter-
Hallo, das könnte man zwar recht einfach machen, aber dadurch wird es dann über Referrer-Abfragen auch relativ einfach, die Session zu hijacken und hier gehts um sensible Daten auch, Sicherheit hat da Vorrang.
ich fände es logisch, statt die Schuld beim Kunden zu suchen, die Anwendung so anzupassen, dass sie die Session-ID dann halt in der URL mitschleppt statt im Cookie; gerade in einem JavaEE-Kontext ist das doch dank response.encodeURL() nicht übermäßig schwer.
-
Tach,
Hallo, das könnte man zwar recht einfach machen, aber dadurch wird es dann über Referrer-Abfragen auch relativ einfach, die Session zu hijacken und hier gehts um sensible Daten auch, Sicherheit hat da Vorrang.
das läßt sich zum Beispiel lösen, indem die Session-ID bei jedem Request wechselt oder externe URLs nur über einen Redirect aufgerufen werden können.
mfg
Woodfighter
-
-
-
-