Bild-Caching, Httphandler und FormsAuthentication

Question

Das Setup:

ich auf einer Website bin arbeiten, die Formsauthentication, die Cookies verwendet das Login-Ticket zu speichern. Die Website verfügt auch über eine HTTPHandler, die in der Datenbank gespeicherte Bilder verwaltet. Der Handler speichert die Bilder als öffentlich und läuft in 20 Minuten ab. Wir haben festgestellt, dass die Bilder, da die Bilder den gleichen Lebenszyklus wie eine Seite haben, auch den Cookie Formsauthentication enthalten. Die Konfiguration ist IIS 6, Win2k-Server, Inhaltsablauf ist nicht aktiviert.

Das Problem:

Was wir erleben, ist Person A anmeldet und trifft auf ein paar Seiten. Dann trifft Person B die Standardseite, die sich nicht anmeldet, und erhält das Cookie für Person A und kann alle Daten der Person A sehen. Wir haben das Problem einmal reproduziert, indem wir Content Expiration in IIS aktiviert haben, aber nicht konsistent reproduziert, so dass wir nicht sicher sind, ob Content Expiration uns geholfen hat, es zu reproduzieren. Wir nehmen an, da die Bilder als öffentlich zwischengespeichert werden und sie auch das Cookie mit der FormsAuthentication enthalten, ist es irgendwie möglich, dass Person B ungewollt den Cookie von Person A erhält. Wir wissen, dass dies kein Angriff auf die Website ist.

Hat jemand etwas ähnliches mit diesem Verhalten erlebt? Wenn ja, können Sie einen Rat geben, wie Sie dieses Problem konsequent reproduzieren können?

Answer 1

Warum erhält Person B den Cookie von Person A? Ich gehe davon aus, dass Sie meinen, dass Session-Cookie von Person B mit der Login-ID von A verknüpft ist. Das ist der Kern des Problems.

Es klingt für mich, dass die Login-ID von A an einem Ort gespeichert wird, an dem Anfragen - wie z. B. eine temporäre Datei oder in der Datenbank - ausgetauscht werden können, ohne sie einem Session-Cookie zuzuordnen. (Zugehöriges Problem: Die Seitenausgabe wird zwischengespeichert, aber nicht ordnungsgemäß mit dem Sitzungscookie verknüpft oder abgerufen.) Wenn Sitzungsinformationen gespeichert oder zwischengespeichert werden, muss mit dem Cookie verknüpft sein (). Denken Sie an Sitzungsdaten, die zu einem Browser gehören, und nicht an ein Login.

Ich würde die Firefox-Erweiterung LiveHTTP installieren und die Request/Response-Header untersuchen. Meine Wette ist, dass A und B verschiedene Cookies haben werden, aber auf dem Server sind sie beide mit der gleichen Login-ID verbunden.

Answer 2

Wir nehmen an, dass der Cookie im Response-Header ist und den gleichen Cookie ausgibt, der auf Person A auf Person B existiert. Es ist wichtig zu beachten, dass dieses Problem bei Person A in IE 7 und Person B in FireFox aufgetreten ist . Auch wenn sich Person A abgemeldet hat, die ausgeloggt war, wurde auch Person B ausgeloggt, da das Formsauthentifizierungs-Ticket auf dem Server nicht mehr gültig war. Also ja, sie hatten verschiedene Cookies, aber das gleiche Formular Authentifizierungsticket in jedem ihrer Cookies. Eine wurde jedoch generiert, ohne sich anzumelden.

Wir haben diesen Artikel auch gefunden, konnten aber nicht bestätigen, ob dies die Ursache ist. http://support.microsoft.com/default.aspx?scid=kb;EN-US;917072

Ich werde sehen, was LiveHTTP mir erzählt und wird zurück melden. Vielen Dank.

Answer 3

Sicher, wenn diese Bilder (und CSS und statische JS-Dateien, etc ...) nicht als HTTPS dienen, werden sie von ISPs oder anderen Proxys (na ja, Caches tatsächlich) zwischengespeichert werden mit ihren Keksen.

Es gibt eine Caching-Richtlinie etwas wie folgt aus:

Cache-control: no-cache="set-cookie,set-cookie2" 

... die Caches soll anweisen, nicht die „Set-Cookie“ Antwort-Header zu cachen, aber ich bin nicht sicher, wie diese breite Unterstützung ist (obwohl es Standard ist).

Vermeiden Sie Set-Cookie-Antwort-Header bei der Bereitstellung von Bildern, wenn Sie können (möglicherweise nicht einfach, wenn Sie nicht die vollständige Kontrolle über die Sitzungsverwaltung haben). Wenn ein Benutzer authentifiziert werden muss, um bestimmte Bilder zu sehen, sollten diese Bilder nicht öffentlich zwischengespeichert werden.

Answer 4

Leider habe ich vergessen zu erwähnen, dass der gesamte Datenverkehr über Port 443 als SSL ging. Wir planen, den gesetzten Cookie für Bilder zu entfernen. Wir sind jedoch wenig verwirrt, wie dies passieren könnte, wenn der gesamte Datenverkehr über SSL verarbeitet wird.

Answer 5

Der gesamte Datenverkehr war SSL ... Überprüfung der IIS-Protokolle alles durch Port 443 ging. Das einzige Caching, das eingestellt wurde, war auf den Bildern zu öffentlichkeit, wie bereits erwähnt. Unsere Annahme ist, dass dies in Ergebnis-Ausgabe-Caching das Problem verursacht.

Answer 6

Sind Sie sicher, dass auf der Seite nicht so etwas wie Ausgabe-Caching aktiviert ist?

Answer 7

Es kann hilfreich sein, Fiddler zu installieren, um Ihre HTTP-Anfragen wie oben beschrieben zu untersuchen. Bestätigen Sie außerdem, dass die Cookies identisch sind. Verwendet Ihr Handler oder Formularauthentifizierungssystem eine statische Objektreferenz? Möglicherweise hast du eine Wettlaufbedingung in deinem Code. und sperren Ihre Ressourcen nicht ordnungsgemäß.