2

Ich habe eine Webapplikation (asp.net 3.5) mit gemischten SSL. Alle kontobezogenen Seiten werden über SSL ausgeliefert. Meistens werden alle anderen Seiten über Nicht-SSL ausgeliefert. Um automatisch zwischen HTTPS und HTTP zu wechseln, verwende ich this component. In letzter Zeit gab es eine Nachricht bezüglich der Fähigkeit, Benutzer-Sessions in ungesicherten WLAN-Netzwerken zu entführen. Dies sollte möglich sein, indem das Cookie abgefangen wird, das über Nicht-SSL-Verbindungen übertragen wird.asp.net Verwendung requireSSL und immer noch in der Lage zu überprüfen, ob der Benutzer auf Nicht-SSL-Seiten

Dies veranlasste mich, meine Sicherheitsoptionen in dieser Webapplikation zu überprüfen. Ich habe (wieder) this article von MSDN ergriffen und versucht, die requireSSL = true Eigenschaft auf meiner Formsauthentication. Bevor ich die Webapplikation gestartet habe, habe ich festgestellt, dass meine User.Identity auf Nicht-SSL-Seiten null ist, da der Cookie, der diese Informationen enthält, nicht von und an den Webbrowser gesendet wird.

Ich brauche einen Mechanismus, der den Benutzer über eine SSL-Verbindung authentifiziert ... und merkt sich diese Authentifizierungsinformationen auch auf Nicht-SSL-Seiten.

Während der Suche nach SO habe ich this post gefunden. Es scheint mir, dass dies eine gute Lösung ist. Aber ich frage mich, ob eine Lösung beim Speichern von Login-Informationen im Session-Status gefunden werden kann? Ich denke, das Application_AuthenticateRequest in dem Global.asax abzufangen. Überprüfen Sie, ob die Verbindung sicher ist, und überprüfen Sie entweder den Authcookie oder die Sitzung. Ich weiß nicht genau, wie ich das noch umsetzen werde. Vielleicht kannst du mit mir darüber nachdenken?

Antwort

3

Leider haben Sie widersprüchliche Anforderungen. Sie können keine sichere Sitzung über Nicht-SSL durchführen. Deshalb möchte ich Ihre zugrunde liegende Annahme in Frage stellen: Warum sollte die gesamte Site keine SSL verwenden?

+0

Hallo Brad, danke für deine Antwort. Zwei Gründe, warum wir http und https mischen. Erstens ist es eine Anwendung, von der auch Bilder an E-Mail-Nachrichten geliefert werden. Bilder, die in HTML-E-Mail-Nachrichten verwendet werden, sollten aufgrund von Kompatibilitätsproblemen besser nicht über HTTPS gesendet werden. Da wir diese Bilder über eine Nicht-ssl-Verbindung bereitstellen, wird auch ein Popup in der Anwendung angezeigt, in dem die Benutzer gefragt werden, ob sie gemischte Inhalte zulassen.Dieselben Bilder für die E-Mail-Nachrichten werden innerhalb der Anwendung verwendet. – JonHendrix

+0

Zweitens werden Assets (CSS, JS, Bilder usw.) nicht zwischengespeichert, wenn sie über SSL geliefert werden. Das heißt, jede Anfrage sendet jedes Mal eine Menge an Assets. Obwohl dies mit einer gewissen Neuausrichtung und Optimierung gelöst werden könnte, denke ich dennoch, dass die Anwendung besser reagieren wird, wenn die meisten Ressourcen zwischengespeichert werden. – JonHendrix

+0

Ich spreche wirklich nur über die Anwendung selbst, nicht die Vermögenswerte. Die Möglichkeit, Bilder sowohl über SSL als auch über Nicht-SSL zuzustellen, sollte kein großes Problem sein, vorausgesetzt, dass die nicht-SSL-Bilder, die bedient werden, keine Authentifizierung zum Anzeigen benötigen (da sie in E-Mail-Nachrichten eingebettet sind) Ich schätze, das tun sie nicht). –

2

Von der MVC FAQ (ähnliche Frage vom Sicherheitsguru Levi beantwortet), die nach einem Attribut fragt, das SSL nicht verwendet.

• Das Attribut [RequireHttps] kann für einen Steuerungstyp oder eine Aktionsmethode verwendet werden, um zu sagen, dass "nur über SSL zugegriffen werden kann". Nicht-SSL-Anfragen an den Controller oder die Aktion werden an die SSL-Version weitergeleitet (bei einem HTTP-GET) oder zurückgewiesen (bei einem HTTP-POST). Sie können das RequireHttpsAttribute überschreiben und dieses Verhalten ändern, wenn Sie möchten. Es gibt kein eingebautes [RequireHttp] -Attribut, das das Gegenteil tut, aber Sie können leicht Ihr eigenes erstellen, wenn Sie es wünschen.

Es gibt auch Überladungen von Html.ActionLink(), die einen Protokollparameter nehmen; Sie können explizit "http" oder "https" als Protokoll angeben. Hier ist die MSDN-Dokumentation zu einer solchen Überlastung. Wenn Sie kein Protokoll angeben oder eine Überladung aufrufen, die keinen Protokollparameter hat, wird davon ausgegangen, dass die Verbindung das gleiche Protokoll wie die aktuelle Anforderung haben soll.

Der Grund, warum wir in MVC kein [RequireHttp] -Attribut haben, ist, dass es nicht wirklich von Vorteil ist. Es ist nicht so interessant wie [RequireHttps], und es ermutigt Benutzer, das Falsche zu tun. Zum Beispiel melden sich viele Websites über SSL an und leiten nach der Anmeldung wieder zurück zu HTTP, was absolut falsch ist. Dein Login-Cookie ist genauso geheim wie dein Benutzername + Passwort und jetzt sendest du ihn im Klartext über den Draht. Außerdem haben Sie sich bereits die Zeit genommen, den Handshake durchzuführen und den Kanal zu sichern (was der Hauptteil dessen ist, was HTTPS langsamer als HTTP macht), bevor die MVC-Pipeline ausgeführt wird. Daher wird [RequireHttp] nicht die aktuelle Anfrage oder Zukunft machen Anfragen viel schneller.