(SICHERHEIT) Mozilla: Caching

[Cheatah]

Hi,

gibt man einer HTTP-Ressource diverse Caching-Empfehlungen mit (Pragma, Expires, Cache-Control), so wird jeder anständige Browser dies standardmäßig entsprechend würdigen. Im Detail unterscheiden sich die Programme jedoch. Am Beispiel der beiden "großen" IE und Mozilla:

Der IE stellt die Seite[1] dar und vergisst anschließend, dass er sie kennt; geht man später mit dem Back-Button zur Seite zurück, kommt eine Fehlermeldung.

Mozilla speichert zwar (AFAIK) die Seite ebenfalls nirgendwo ab, behält sie jedoch im Speicher, so dass man sie auch nach dem Verlassen per Back-Button wieder hervorholen kann. (Sie wird auch nicht neu angefordert, sondern entstammt wirklich dem lokalen Speicher).

Ich würde ohne zu zögern das Verhalten des Mozilla als deutlich userfreundlicher ansehen und denke, mir wird da kaum jemand widersprechen. Wie sieht das aber im Hinblick auf die Sicherheit aus? Man stelle sich beispielsweise einen Logout-Vorgang vor, der zu einer Bestätigungsseite führt; wenn der Benutzer diese stehen lässt, kann jeder zufällig vorbeikommende Mensch zumindest die auf den vorherigen Seiten dargestellten Informationen sehen.

Was meinen andere, Sicherheitsrisiko oder nicht? Und: Kann man eventuell - serverseitig, per Konfiguration - etwas daran ändern?

Cheatah

[1] Ich beziehe mich der Einfachheit halber mal speziell auf ein HTML-Dokument.

[Fabian Transchel]

Hi Cheatah,

Ich würde ohne zu zögern das Verhalten des Mozilla als deutlich userfreundlicher ansehen und denke, mir wird da kaum jemand widersprechen. Wie sieht das aber im Hinblick auf die Sicherheit aus? Man stelle sich beispielsweise einen Logout-Vorgang vor, der zu einer Bestätigungsseite führt; wenn der Benutzer diese stehen lässt, kann jeder zufällig vorbeikommende Mensch zumindest die auf den vorherigen Seiten dargestellten Informationen sehen.

Was meinen andere, Sicherheitsrisiko oder nicht? Und: Kann man eventuell - serverseitig, per Konfiguration - etwas daran ändern?

Das hängt selbstverständlich vom User ab. Wenn ich den Browser so stehen lasse, wie er ist, wenn ich fertig bin, kann das schon unsicher sein, wenn ich ihn aber schließe hat sich das erledigt. Abgesehen davon werden SSL-kodierte Dokumente ja ohnehin nicht gecacht, von dem her stellt das da kein Problem dar, hoffe ich!?

Grüße aus Barsinghausen,
Fabian

[Cheatah]

Hi,

Das hängt selbstverständlich vom User ab. Wenn ich den Browser so stehen lasse, wie er ist, wenn ich fertig bin, kann das schon unsicher sein, wenn ich ihn aber schließe hat sich das erledigt.

ja, nur kann sich ein Sicherheitskonzept nicht auf die Vorgabe eines Benutzerverhaltens stützen - ansonsten kann (üblicherweise) auch der ganze Rechner gesperrt werden, und gut is'. Weitergabe des Problems hilft leider nicht.

Abgesehen davon werden SSL-kodierte Dokumente ja ohnehin nicht gecacht, von dem her stellt das da kein Problem dar, hoffe ich!?

Ja, da scheint sich Mozilla "besser" zu verhalten. Ob dies zum Urteil "kein Problem" führt, sei mal dahingestellt.

Cheatah

[Thomas J.]

Tag

ja, nur kann sich ein Sicherheitskonzept nicht auf die Vorgabe eines Benutzerverhaltens stützen

Also das halte ich jetzt für ziemlich übertrieben.
Wenn jemand sein Auto nicht abschließt und außerdem noch den Zündschlüssel stecken läßt, kann er sich auch nicht über eine fehlerhafte Verriegelung beschweren, falls das Auto geklaut wird.
Ein gewisses Maß an Eigenverantwortung sollte eigentlich jeder mitbringen, ob nun auf dem Parkplatz oder Internet.

Ansonsten wird für derartige Fälle häufig einen automatische Abmeldung nach einer vorgegeben Zeit der Inaktivität verwendet.

Thomas J.

[Cheatah]

Hi,

Wenn jemand sein Auto nicht abschließt und außerdem noch den Zündschlüssel stecken läßt, kann er sich auch nicht über eine fehlerhafte Verriegelung beschweren, falls das Auto geklaut wird.

die Versicherung wird jedenfalls nicht zahlen, das ist wahr.

Ein gewisses Maß an Eigenverantwortung sollte eigentlich jeder mitbringen, ob nun auf dem Parkplatz oder Internet.

Persönlich stimme ich Dir zu. Leider sieht der Benutzer einen Internetdienst völlig anders an als sein Auto, für das er x-tausend Euro hingeblättert hat - er erwartet, dass der Dienst *ohne technisches Wissen seinerseits* sicher bedient werden kann.

Ansonsten wird für derartige Fälle häufig einen automatische Abmeldung nach einer vorgegeben Zeit der Inaktivität verwendet.

Das sowieso, aber es nützt ja nun nichts dagegen, dass der Browser die Inhalte der geladenen Seite auch nach Verfall der Session anzeigt, einfach weil er sie noch hat.

Cheatah

[Thomas J.]

N, Abend

Leider sieht der Benutzer einen Internetdienst völlig anders an als sein Auto, für das er x-tausend Euro hingeblättert hat - er erwartet, dass der Dienst *ohne technisches Wissen seinerseits* sicher bedient werden kann.

Stimmt, das ist in der Tat ein Problem.
Ich halte es aber weder von den technischen Möglichkeiten, noch vom vertretbaren Aufwand her für realisierbar, für jede denkbare Benutzeraktion (und sei sie auch noch so dämlich) eine Auffanglösung zu konstruieren.

Das sowieso, aber es nützt ja nun nichts dagegen, dass der Browser die Inhalte der geladenen Seite auch nach Verfall der Session anzeigt, einfach weil er sie noch hat.

Stimmt ebenfalls.
Doch solange es Browser gibt, die HTTP-Anweisungen ignorieren, kommt m.E. dem Prinzip Aufklärung eine höhere Bedeutung zu, als dem Versuch, Systeme idiotensicher* zu machen, die per se nicht idiotensicher sein können.
Nun wird das leider einem gestreßten Webmaster kaum helfen, wenn er von einem DAU für eventuellen persönlichen Schaden verantwortlich gemacht wird. Ich denke da z.B. an den Fall dieses ebay-Kunden, der vor einiger Zeit durch die einschlägig bekannten Boulevard-Magazine ging ...
Zum Glück herrschen hierzulande noch keine amerikanischen Verhältnisse, wo Lebensmittelhersteller vor ihren eigenen Produkten warnen, weil deren übermäßiger Verzehr zu Fettleibigkeit führen könnte.

Thomas J.

*Idiotensichere Systeme werden auch ausschließlich von Idioten bedient.
(Murphys Gesetz)

[MudGuard]

Hi,

gibt man einer HTTP-Ressource diverse Caching-Empfehlungen mit (Pragma, Expires, Cache-Control), so wird jeder anständige Browser dies standardmäßig entsprechend würdigen. Im Detail unterscheiden sich die Programme jedoch. Am Beispiel der beiden "großen" IE und Mozilla:

Das hängt meiner Erfahrung nach von den Einstellungen ab, wie oft die Seite neu angefordert werden soll
Im Mozilla (Edit - Preferences - Advanced - Cache)

• jedesmal
• einmal pro Session
• wenn abgelaufen
• nie

Im IE (Tools - Internet Options - Settings) mit praktisch den gleichen Auswahlwerten.
Opera bietet neben nie und immer noch diverse Zeitintervalle an, aber kein "wenn abgelaufen" - dafür aber das ganze getrennt nach Dokumenten, Bildern, sonstiges)...

Hast Du hier bei den Browsern die selbe Einstellung?

cu,
Andreas

[Cheatah]

Hi,

Das hängt meiner Erfahrung nach von den Einstellungen ab, wie oft die Seite neu angefordert werden soll

das steht bei mir auf "When the page is out of date", und dennoch wird die Seite nicht neu angefordert. Liegt das an meinem Mozilla, oder ist das bei anderen auch so?

Cheatah

[Chräcker Heller]

Hallo,

des englischen ja nicht so super mächtig und jede "Regelaufstellungsliste" eh immer erst einmal ignorierend, würde ich das "cachen" so verstehen. Es handelt sich hier um eine Frage des "merkens". Soll ein Browser sich eine einmal besuchte Seite merken (bzw deren Inhalt) um dann bei einem erneuten Aufruf im zweifelsfalle erst einmal diese "gemerkte" Seite anzuzeigen anstelle sie "umständlich" noch einmal aus dem netz zu "bestellen". (Jetzt sehr umgangssprachlich ausgedrückt)... DAS Browser sich die Seiten klasischerweise merken, in dem sie die auf die Festplatte speichern, mag systembedingt logisch erscheinen, ist aber nicht innerhalb der Definition wirklich zwingend notwendig. Wie der Browser sich unter zuhilfename des PC die Seite merkt, ist fürs "cachen" wurscht. Er könnte auch jede Seite ausdrucken und beim wiederholten laden die Seite vollautomatisch durch einen Scanner ziehen und somit unter zuhilfenname eines ocr-html-erstellprogramm die Seite wieder darstellen ,-) Oder sie immer in einem usb-Flashspeicher(?) speichern oder wie auch immer. "gecached" ist "gecached"....

Will ich, das eine Seite nicht "vorerst zwischengespeichert" werden soll, ist es also unerheblich, ob der PC sich die Daten normalerweise mittels Technik in den schwarzen Speicherreigeln auf meinem Motherboard sich merkt, im temporären Windows-Swapauslagerungsverzeichniß, auf meiner Festplatte oder einem Druck-Scan-Speichergerät wie oben skiziert. Er hat sie sich nicht zwischenzuspeichern.... (Anders ausgedrückt: das der Cache ein Platz auf der Festplatte ist ist ja nur Systembedingt....)

Alles nur Bauchmeinung eines Ahnungslosen ,-)))

Chräcker

[Cheatah]

Hi,

des englischen ja nicht so super mächtig und jede "Regelaufstellungsliste" eh immer erst einmal ignorierend, würde ich das "cachen" so verstehen.

für das Verstehen des Begriffes "cache" sind Englischkenntnisse nicht erforderlich, weil er vom französischen "caché" kommt ;-)

Es handelt sich hier um eine Frage des "merkens". [...]

Eine IMHO gute Beschreibung. Ein Gegenargument ist allerdings, dass der Server sich nicht zu erdreisten hat, dem Client irgendetwas vorschreiben zu wollen - er ist höchstens bemächtigt, Empfehlungen auszusprechen. Von daher sind wir beim Sicherheitsaspekt nicht wirklich weitergekommen ... Dennoch danke.

Cheatah

[Henryk Plötz]

Moin,

Mozilla speichert zwar (AFAIK) die Seite ebenfalls nirgendwo ab, behält sie jedoch im Speicher, so dass man sie auch nach dem Verlassen per Back-Button wieder hervorholen kann. (Sie wird auch nicht neu angefordert, sondern entstammt wirklich dem lokalen Speicher).

Was auch der Sinn des Back-Buttons ist, wie RFC 2616 ausführlich darlegt:

| 13.13 History Lists
|
|   User agents often have history mechanisms, such as "Back" buttons and
|   history lists, which can be used to redisplay an entity retrieved
|   earlier in a session.
|
|   History mechanisms and caches are different. In particular history
|   mechanisms SHOULD NOT try to show a semantically transparent view of
|   the current state of a resource. Rather, a history mechanism is meant
|   to show exactly what the user saw at the time when the resource was
|   retrieved.

Der korrekte Weg ist in jedem Fall die History zu zerstören, indem man das Fenster oder den Tab schliesst.