C# ASP.NET表单身份验证漏洞

当我读到这篇文章时，@Slauma对@reach4thelasers所写的所选答案的链接响应（包括在内）让我大吃一惊。这是一篇关于如何在大约半小时内破解ASP.NET表单身份验证并收集远程机器密钥的博客文章

有一些回复提到，只有在你没有做一些具体的事情的情况下，这才有可能，但我不清楚这些具体的事情是什么（关于自定义错误页面，但视频似乎没有击中任何错误页面）。它还提到微软有避免此类攻击的建议，但与该建议没有联系

那么，首先，有人能清楚地解释一下，在开发ASP.NET表单身份验证系统时，为了防止像上面提到的那样的攻击，有什么必要的吗

---

第二，ASP.NET表单身份验证中是否存在其他已知的漏洞，某些最佳做法（默认情况下未实施）会减轻或防止这些漏洞？我正在建立一个包含财务数据的公共网站，因此这是我非常关心的问题。

这在很久以前就已经解决了：

斯科特·顾当时就写过这件事

因此，这个问题涵盖了该问题的一些影响

---

我想说的是，主要的收获是，框架中的补丁和升级比将生产应用程序保留在旧框架、旧补丁级别的危险要小，而大型组织的变更控制委员会恰恰相反。他们通常更担心补丁和更新，而不是现有代码中存在漏洞的可能性。

我相信你已经谈到了这一点：我提出的一个类似问题非常好。谢谢你的链接。太棒了。我被博客上的评论误导了，似乎。。。他们似乎在暗示开发人员必须采取行动来防止这种情况。几年前，我看到在3.5版本发布时安装了ASP.NET 1.0，这可能只是出于对补丁的病态恐惧。该网站可能仍然存在问题，但即使在那里，他们也必须关闭windows Update，后者提供了大部分此类补丁。当我的服务器管理员说他们想修补或更新框架时，我会告诉他们“请！”，即使这意味着需要做一些工作来检查功能是否仍然有效。我不能在这里写一本书，但我想更清楚地解释CCB在非常大的组织中的地位。我在一个非常大的组织（27K+）工作，他们进展缓慢，应用补丁也很慢。然而，这主要是因为有更多的演员参与其中，你不能指望有两只手。在一个大的组织中，没有什么是“只要去做，它就会工作——如果不行，我们就会处理它。”我就是不这样工作。所以，您首先升级较低的环境，彻底测试它们，然后安排非高峰时间进行更新。@MichaelPerrenoud啊，我不反对CCB的想法。只是我参与的那些人都在积极破坏所有变更和橡皮图章请求之间交替，在这两种情况下，与拟议变更的技术优点无关。在最好的情况下，CCB在没有监督或第二意见的情况下增加了额外的风险和努力。在最坏的情况下，CCB停止所有活动，直到团队解散，项目被终止，将开发和支持从组织中转移到合同安排中，超出CCB的能力范围。希望我们不是在同一个组织工作。