我最近看了一个演讲 (http://vimeo.com/68390507)，演讲者很严肃，说了好几遍，永远不要设置 EnableViewStateMac=false。
在使用 Enterprise Web Library 时，我注意到 EnableViewStateMac 设置为 false。 EWL 正在做什么来弥补这一点？我怎么能相信它是安全的？
【问题讨论】：
标签： asp.net security xss viewstate enterprise-web-library
请务必注意，虽然 EWL 目前依赖于 Web 窗体（和视图状态），但它是一个弱依赖关系，我们的路线图要求完全消除这种依赖关系。 EWL 使用Page.SavePageStateToPersistenceMedium 和Page.LoadPageStateToPersistenceMedium 完全覆盖了视图状态的保存和加载，这意味着页面上的任何控件不可能存储自己的[可能不安全]状态。
以下是 EWL 在视图状态中存储的完整列表：
EWL“页面状态”。只要用户停留在页面上，这些数据就需要持续存在，但不应存储在数据库或其他持久存储中。例如，EwfTable 的当前项显示限制，或者需要在中间回发时保存的表单字段值，以便可以刷新页面的某些部分。这种类型的数据由用户直接操作，并不比普通表单字段值更秘密。事实上，我们正在考虑将其更公开地存储在隐藏字段中，这将使 JavaScript 无需回发即可对其进行操作。
“表单值哈希”。这是呈现页面时所有表单字段值的哈希值。它用于回发通知用户自上次加载页面以来是否有任何数据在他们的脚下发生了变化。如果这个哈希被黑客入侵，可能会发生两件事。首先，即使没有数据更改，用户也可能收到“并发错误”。其次，即使数据确实发生了变化，用户也不会收到并发错误。第二种情况可能听起来很糟糕，但请记住，大多数 Web 应用程序一开始就没有这种类型的并发检查。
上次回发失败的数据修改的 ID。这是 null、空或等于页面 HTML 中存在的一个回发 ID，用于在某些情况下重新运行数据修改，以重新显示验证错误。最糟糕的黑客攻击结果是显示一组不同但仍可触发的验证错误。
【讨论】：
不幸的是，它并不安全。 EnableViewStateMac 的重点不是防止控件往返不安全状态。这是为了防止攻击者注入自己的状态并让控件将其解释为有效。
EnableViewStateMac=false 是一个不安全的设置。句号。没有条件，没有例外，没有借口。应用程序在任何情况下都不应将此开关设置为 false。
事实上，由于应用程序没有正当理由这样做，我们（ASP.NET 团队）将禁止在即将发布的 ASP.NET 版本中设置 EnableViewStateMac=false。这可能会破坏使用此设置部署的应用程序。通常我们不会做对兼容性造成如此大影响的事情，但我希望我们在这里破例这一事实表明，当我们说“任何人都不应该这样做”时，我们是多么认真。
【讨论】：