asp.net 使用 requireSSL 并且仍然能够检查用户是否在非 SSL 页面上进行了身份验证
我有一个带有混合 SSL 的 Web 应用程序 (asp.net 3.5)。所有帐户相关页面均通过 SSL 传送。大多数其他页面都是通过非 SSL 传递的。为了在 HTTPS 和 HTTP 之间自动切换，我使用此组件。最近有一条新闻报道了在不安全的 Wifi 网络上劫持用户会话的能力。这应该可以通过捕获通过非 ssl 连接传输的 Cookie 来实现。
这促使我重新审视我在此 Web 应用程序中的安全选择。我（再次）从 MSDN 中获取了这篇文章并尝试了我的 Formsauthentication 上的 requireSSL=true 属性。在我启动 Web 应用程序之前，我意识到我的 User.Identity 在非 SSL 页面上将为空，因为包含此信息的 cookie 不会从 Web 浏览器发送或发送到 Web 浏览器。
我需要一种通过 SSL 连接对用户进行身份验证的机制...并记住此身份验证信息，即使在非 SSL 页面上也是如此。
在搜索时，我发现了这篇文章。在我看来，这是一个很好的解决方案。但是，我想知道是否可以找到将登录信息存储在Sessionstate中的解决方案？我正在考虑捕获 Global.asax 中的 Application_AuthenticateRequest 。检查连接是否安全并检查 authcookie 或 Session。我还不知道我将如何实现这一点。也许你可以和我一起思考一下这个问题？
I have a webapplication (asp.net 3.5) with mixed SSL. All account related pages are delivered over SSL. Mostly all other pages are delivered over non-ssl. To automatically switch between HTTPS and HTTP I use this component. Lately there was a news item regarding the ability toch hijack user sessions on non-secure Wifi networks. This should be possible by catching the Cookie that is transmitted over non-ssl connections.
This triggered me to review my security choices in this webapplication. I've (again) grabbed this article from MSDN and tried the requireSSL=true property on my Formsauthentication. Before I've even started the webapplication I realized that my User.Identity will be null on non-SSL pages because the cookie containing this information isn't sent from and to the webbrowser.
I need a mechanism that Authenticates the user over a SSL connection... and remembers this authentication info, even on non-SSL pages.
While searching SO, I've found this post. It's seems to me that this is a good solution. But, I wonder if a solution can be found in storing login information in the Sessionstate? I'm thinking of catching the Application_AuthenticateRequest in the Global.asax. Checking if the connection is secure and check either the authcookie or Session. I don't know exactly how I'm going to implement this yet. Maybe you can think with me on this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不幸的是，您的要求是相互冲突的。您无法通过非 SSL 进行安全会话，因此我想挑战您的基本假设：为什么不让整个网站都使用 SSL？
Unfortunately, you have conflicting requirements. You can't have a secure session over non-SSL, so I'd like to challenge your underlying assumption: why not have the whole site use SSL?
来自 MVC FAQ（安全专家 Levi 回答的类似问题），要求属性不使用 SSL。
• [RequireHttps] 属性可用于控制器类型或操作方法，表示“只能通过 SSL 访问”。对控制器或操作的非 SSL 请求将被重定向到 SSL 版本（如果是 HTTP GET）或被拒绝（如果是 HTTP POST）。如果您愿意，您可以重写 RequireHttpsAttribute 并更改此行为。没有内置的 [RequireHttp] 属性可以起到相反的作用，但如果您愿意，您可以轻松创建自己的属性。
还有 Html.ActionLink() 的重载，它采用协议参数；您可以明确指定“http”或“https”作为协议。这是有关此类重载的 MSDN 文档。如果您未指定协议或者调用没有协议参数的重载，则假定您希望链接具有与当前请求相同的协议。
我们在 MVC 中没有 [RequireHttp] 属性的原因是它没有太多好处。它不像[RequireHttps]那么有趣，而且它鼓励用户做错误的事情。例如，许多网站通过 SSL 登录，并在登录后重定向回 HTTP，这绝对是错误的做法。您的登录 cookie 与您的用户名 + 密码一样保密，现在您可以通过网络以明文形式发送它。此外，在 MVC 管道运行之前，您已经花时间执行握手并保护通道（这是使 HTTPS 比 HTTP 慢的主要原因），因此 [RequireHttp] 不会发出当前请求或将来的请求请求速度更快。
From the MVC FAQ (similar question answered by security guru Levi) asking for an attribute to not use SSL.
•The [RequireHttps] attribute can be used on a controller type or action method to say "this can be accessed only via SSL." Non-SSL requests to the controller or action will be redirected to the SSL version (if an HTTP GET) or rejected (if an HTTP POST). You can override the RequireHttpsAttribute and change this behavior if you wish. There's no [RequireHttp] attribute built-in that does the opposite, but you could easily make your own if you desired.
There are also overloads of Html.ActionLink() which take a protocol parameter; you can explicitly specify "http" or "https" as the protocol. Here's the MSDN documentation on one such overload. If you don't specify a protocol or if you call an overload which doesn't have a protocol parameter, it's assumed you wanted the link to have the same protocol as the current request.
The reason we don’t have a [RequireHttp] attribute in MVC is that there’s not really much benefit to it. It’s not as interesting as [RequireHttps], and it encourages users to do the wrong thing. For example, many web sites log in via SSL and redirect back to HTTP after you’re logged in, which is absolutely the wrong thing to do. Your login cookie is just as secret as your username + password, and now you’re sending it in cleartext across the wire. Besides, you’ve already taken the time to perform the handshake and secure the channel (which is the bulk of what makes HTTPS slower than HTTP) before the MVC pipeline is run, so [RequireHttp] won’t make the current request or future requests much faster.