ASP.NET verwenden Anforderungen und können weiterhin prüfen, ob der Benutzer auf Nicht-SSL-Seiten authentifiziert ist

Question

Ich habe eine Webapplication (ASP.NET 3.5) mit gemischtem SSL. Alle Kontoseiten werden über SSL geliefert. Meistens werden alle anderen Seiten über Nicht-SSL geliefert. Um automatisch zwischen HTTPS und HTTP zu wechseln, verwende ich Diese Komponente. In letzter Zeit gab es eine Nachricht über die Fähigkeit, die Benutzer-Benutzersitzungen in nicht sicheren WLAN-Netzwerken zu entführen. Dies sollte möglich sein, indem Sie den Keks fangen, der über Nicht-SSL-Verbindungen übertragen wird.

Dies löste mich aus, meine Sicherheitsauswahl in dieser Webapplication zu überprüfen. Ich habe (wieder) gepackt Dieser Artikel von msdn und versuchte die Bedarf = true Eigentum auf meinen Formsauthentifizierungen. Bevor ich überhaupt mit der Webapplication begonnen habe, wurde mir klar, dass mein Benutzer. Identität auf Nicht-SSL-Seiten null sein, da das Cookie, das diese Informationen enthält, nicht an den Webbrowser gesendet wird.

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

Während der Suche habe ich festgestellt dieser Beitrag. Es scheint mir, dass dies eine gute Lösung ist. Aber ich frage mich, ob eine Lösung beim Speichern von Anmeldeinformationen im SessionState gefunden werden kann. Ich denke darüber nach, die Anwendung zu fangen. Überprüfen Sie, ob die Verbindung sicher ist, und überprüfen Sie entweder den Authookie oder die Sitzung. Ich weiß genau nicht genau, wie ich das umsetzen werde. Vielleicht kannst du mit mir darüber nachdenken?

Answer 1

Leider haben Sie widersprüchliche Anforderungen. Sie können keine sichere Sitzung über Non-SSL haben, daher möchte ich Ihre zugrunde liegende Annahme in Frage stellen: Warum nicht die gesamte Website SSL verwenden?

Answer 2

Aus den MVC -FAQ (ähnliche Frage, die vom Sicherheitsguru Levi beantwortet wurde) bittet ein Attribut, SSL nicht zu verwenden.

• Das Attribut [requiredhttps] kann bei einer Controller -Typ- oder Aktionsmethode verwendet werden, um zu sagen: "Auf diese kann nur über SSL zugegriffen werden." Nicht-SSL-Anfragen an den Controller oder die Aktion werden in die SSL-Version (falls ein HTTP erhalten) oder abgelehnt (falls ein HTTP-Post) umgeleitet. Sie können die RequiredHttpSattribute überschreiben und dieses Verhalten ändern, wenn Sie dies wünschen. Es gibt kein integriertes [RequiredHttp] -attribut, das das Gegenteil bewirkt, aber Sie können Ihre eigene leicht herstellen, wenn Sie es gewünscht haben.

Es gibt auch Überladungen von HTML.ActionLink (), die einen Protokollparameter entgegennehmen. Sie können "http" oder "https" als Protokoll explizit angeben. Hier ist die MSDN -Dokumentation zu einer solchen Überladung. Wenn Sie kein Protokoll angeben oder eine Überladung aufrufen, die keinen Protokollparameter hat, wird davon ausgegangen, dass der Link das gleiche Protokoll wie die aktuelle Anfrage hat.

Der Grund, warum wir in MVC kein [RequiredHttp] -attribut haben, ist, dass es nicht wirklich viel Nutzen gibt. Es ist nicht so interessant wie [forderthttps] und ermutigt die Benutzer, das Falsche zu tun. Zum Beispiel melden sich viele Websites über SSL an und leiten Sie nach der Anmeldung zu HTTP zurück, was absolut falsch ist. Ihr Login -Cookie ist genauso geheim wie Ihr Benutzername + Passwort, und jetzt senden Sie es in ClearText über das Kabel. Außerdem haben Sie sich bereits die Zeit genommen, den Handshake durchzuführen und den Kanal zu sichern (was der Großteil dessen ist, was HTTPS langsamer macht als HTTP), bevor die MVC -Pipeline ausgeführt wird. fordert viel schneller an.