So verstehen Sie eine Sicherheitswarnung in Google Chrome für eine statische Ressource, die von Asp.net bereitgestellt wird

9

Ich habe unsere Webanwendung mit der Prüffunktion in den Google Chrome-Entwicklertools überprüft.

Zuerst habe ich eine Warnung erhalten, die darauf hinweist, dass wir unseren statischen Inhalt nicht cachefähig bereitstellen: "Die folgenden Ressourcen sind explizit nicht cachefähig. Ziehen Sie in Betracht, das Cache möglichst zu machen".

Um das zu beheben, habe ich dieses Snippet zu unserer Web-Konfiguration hinzugefügt

%Vor%

wie in diesem Blogpost empfohlen: Ссылка

Wenn ich jetzt ein neues Audit in Google Chrome starte, bekomme ich eine neue Warnung:

  

Die folgenden öffentlich zwischenspeicherbaren Ressourcen enthalten einen Set-Cookie   Header. Diese Sicherheitslücke kann dazu führen, dass Cookies geteilt werden   mehrere Benutzer.

Können Sie die mögliche Sicherheitsbedrohung erklären und was ist eine mögliche Lösung in Asp.net?

[Update]

Nach ein paar weiteren Recherchen könnte das mit dieser Frage zusammenhängen:

Warum ist ASP? .NET Formularauthentifizierungs-Einstellungs-Cookies für eine statische Bildanforderung?

Aber ich kann das Puzzle nicht zusammensetzen. Die Situation ist nicht genau die gleiche, während unsere Anwendung konfiguriert werden konnte, um die Formularauthentifizierung zu verwenden, bekam ich die Warnung während der Verwendung der Windows-Authentifizierung.

    
stefan.s 02.07.2012, 13:42
quelle

1 Antwort

4

Es sieht so aus, als ob das Problem wirklich mit der Formularauthentifizierung zusammenhängt. Nach der Authentifizierung des Benutzers haben wir einen Formular-Authentifizierungs-Coockie eingerichtet. Dieser Coockie hat keinen Pfad gesetzt, daher wird er für jede Anfrage gesendet, auch für statische Bilder.

Es sieht so aus, als hätte ich das Coockie-Set von einer vorherigen Debug-Sitzung gesetzt, obwohl ich die Windows-Authentifizierung getestet habe.

Ich denke, die beste Lösung wäre, einen Pfad für den Coockie festzulegen, um zu verhindern, dass er nach statischen Ressourcen gesendet wird. Leider kann ich keinen Pfad für alle unsere Serviceanforderungen definieren, da wir WCF Ria Services verwenden und die Dienste einen virtuellen Pfad haben, der eine Laufzeitumgebung erstellt.

Die Lösung für jetzt ist das Coockie nur im Browser eingestellt. Der aktualisierte Eintrag in der Webkonfiguration lautet:

%Vor%

Der wichtige Teil ist das neue Attribut cacheControlCustom.

Ich denke, das könnte immer noch ein Sicherheitsproblem sein, wenn ein Browser von mehr als einem Benutzer geteilt wird (z. B. in einem Internetcafe?), aber dies ist kein gültiges Szenario für unser Projekt.

    
stefan.s 05.07.2012, 08:30
quelle