ASP.NET 中的基本表单身份验证有多安全？
想象一下，您有一个只有 2 个页面的简单网站：login.aspx 和 Secret.aspx。 仅使用 ASP.net 表单身份验证和 login.aspx 上的 ASP.net 登录服务器控件来保护您的站点。 详细信息如下：
- 站点配置为使用 SqlMembershipProvider
- 站点拒绝所有匿名用户
- Cookie 被禁用
显然，关于安全性需要考虑很多事情，但我更感兴趣的是 .网框架。
对于这个问题，如果唯一的攻击点是 login.aspx 中的用户名/密码文本框，那么黑客是否可以注入代码来允许他们访问我们的 Secret.aspx 页面？
Microsoft 提供的零代码开箱即用体验有多安全？
Imagine that you have a simple site with only 2 pages: login.aspx and secret.aspx. Your site is secured using nothing but ASP.net forms authentication and an ASP.net Login server control on login.aspx. The details are as follows:
- The site is configured to use the SqlMembershipProvider
- The site denies all anonymous users
- Cookies are disabled
The are obviously many things to consider regarding security but I am more interested in the zero code out of box experience that comes with the .net framework.
If, for the sake of this question, the only attack points are the username/password textboxes in login.aspx, can a hacker inject code that will allow them to gain access to our secret.aspx page?
How secure is the zero code out-of-box experience that Microsoft provides?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您仍然有一些未考虑到的变量：
并非所有这些问题都是 MS 特有的，但它们值得一提，因为如果不加以处理，其中任何一个问题都可能很容易超过您所询问的问题。 但是，出于您提出问题的目的，我假设它们没有任何问题。
在这种情况下，我很确定表单身份验证会完成它应该做的事情。 我认为目前没有任何活跃的漏洞利用。
You still have some variables that aren't accounted for:
Not all of those issues are MS specific, but they're worth mentioning because any of them could easily outweigh the issue you're asking about, if not taken care of. But, for the purpose of your question I'll assume there aren't any problems with them.
In that case, I'm pretty sure the forms authentication does what it's supposed to do. I don't think there's any currently active exploit out there.
据我所知，密码将以纯文本形式发送（但经过编码）。 因此，最重要的是在登录屏幕上使用 HTTPS 协议。
其他设置对我来说似乎是安全的。
As far as I know password will be sent as plain text (but encoded). So the most important thing to do is to use HTTPS protocol on login screens.
The other setting seems to be secure for me.
通过 HTTP 基本身份验证（即 .NET 基本表单身份验证所使用的身份验证），为了查看 Secret.aspx 页面，浏览器必须发送用户名和密码的 Base64 编码串联。
除非您使用 SSL，否则任何有权扫描服务器和浏览器之间网络的人都可以读取此信息。 他们可以解码用户名和密码。 他们可以在将来重播用户名和密码来访问 Secret.aspx 页面。
也就是说，除非您使用 SSL，否则某人还可以使用 Secret.aspx 扫描其他人的整个会话，因此实际上，他们也可以访问该页面的内容。
With HTTP Basic Authentication, which is what the .NET basic forms authentication is using, in order to view the secret.aspx page, the browser must send a Base64 encoded concatenation of the username and password.
Unless you utilize SSL, anyone who has access to scan the network between the server and the browser can read this information. They can decode the username and password. They can replay the username and password in the future to gain access to the secret.aspx page.
That said, unless you use SSL, someone can also scan the whole session of someone else using secret.aspx, so in effect, they would have access to the content of the page as well.
好吧，尝试看看幕后：
因此，您的安全强度（开箱即用）将取决于您使用的密码保护格式策略：
我不知道是否可以使用某种彩虹表破解默认的哈希基系统。
欲了解更多详细信息，请查看此链接：
http://msdn.microsoft.com/en-us/library/aa478949。 ASPX
Well, try and look behind the scenes:
So the strength of your security (out of the box) will depend on which password protection format strategy you are using:
I do not know if it is possible to use some sort of rainbow table hack into the default Hash-base system.
For more details, check out this link:
http://msdn.microsoft.com/en-us/library/aa478949.aspx
如果通过会员提供商正确配置，您将拥有足够的安全级别。 除此之外，对该页面的访问可能可以通过规范攻击进行访问，但这与您的总体安全有关。 我演示了如何使用安全企业应用程序块。 您可能需要阅读这些内容，并在站点上实施安全性时进行研究，并了解常见的安全威胁。 没有一个网站是 100% 不可破解的，因为您处于开放的共享网络上，并且总体安全性将是一台未插电的服务器锁定在由军方 24/7 全天候守卫的保险箱中（大约是国防部“A”级安全性，基于橙皮书） ）。 但是，会员资格提供者的开箱即用功能（如果配置正确）将提供良好的安全性。
编辑：是的，我同意其他评论，如果您想保护用户名/密码免受数据包嗅探器和网络监视器的侵害，至少在登录屏幕上使用 HTTPS 是给定的。
If configured correctly through the membership provider, you will have a adequate level of security. Outside of that, access to that page might be accessible through cannonical attacks, but that has to do with your general security. I gave a presentation on using the Security Enterprise Application Blocks. You might want to read up on those and look into that when implementing security on your site, and just be aware of common security threats. No site will ever be 100% unhackable, given that you are on an open shared network and total security would be an unplugged server locked in a safe guarded 24/7 by the military (around DoD "A" level security, based of Orange book). But the out of the box functionality of the Membership Providers (when configured correctly) will offer a good amount of security.
Edit: Yeah, I agree with the other comment that was made, HTTPS on at least the log in screens is a given, if you want to protect the username/passwords from packet sniffers and network monitors.
Asp.Net 支持 cookieless 会话，如此博客文章所示。 它使用 url 中的标识符来跟踪用户，而不是会话 cookie。
我不确定这有多安全，但我认为它是安全的，因为很难暴力破解身份字符串。
它看起来或多或少是开箱即用的，但是当重定向用户并想要维护会话状态时，您必须包含会话 ID。 该博客文章以及网络上的许多其他文章展示了如何做到这一点。
Asp.Net supports cookieless sessions, as this blog post shows. Instead of a session cookie, it uses an identifier in the url to track users.
I am not sure how secure this is, but I would think it is a secure as the difficulty to brute force the identity string.
It looks like it works more or less out of the box, however when redirecting a user and wanting to maintain session state you must include the session id. The blog post shows how to do that, as well as many other articles on the web.
以下是 Microsoft 关于该主题的两篇好文章：
如何：保护表单身份验证ASP.NET 2.0
信息：帮助保护表单身份验证通过使用安全套接字层 (SSL)
Here are two good articles from Microsoft on the subject:
How To: Protect Forms Authentication in ASP.NET 2.0
INFO: Help Secure Forms Authentication by Using Secure Sockets Layer (SSL)
URL 上的 Cookie 不够安全，它存在很多不同的问题（尤其是引用者泄漏，如果有的话）以及 HTTPS 的使用。
Cookies over URL is not secure enough, there are so many different problems with it (especially referrer leakage if you've got any) and usage of HTTPS.