将EnableViewStateMac设置为false时，EWL是否安全？

Question

我最近看了一个演讲（http://vimeo.com/68390507），演讲者非常认真，多次说，从不设置EnableViewStateMac = false。

使用Enterprise Web Library时，我注意到EnableViewStateMac设置为false。 EWL正在做些什么来弥补这个问题？我怎么能相信它是安全的？

Answer 1

值得注意的是，虽然EWL目前依赖于Web窗体（和视图状态），但它是弱依赖关系，我们的路线图要求完全消除依赖关系。 EWL使用Page.SavePageStateToPersistenceMedium和Page.LoadPageStateToPersistenceMedium完全覆盖保存和加载视图状态，这意味着页面上的任何控件都不可能来存储它们[可能]不安全的状态。

以下是EWL在视图状态下存储的完整列表：

• EWL“页面状态”。这是只要用户停留在页面上就需要持久的数据，但不应存储在数据库或其他持久存储中。例如，EwfTable的当前项显示限制，或需要保存在中间回发上的表单字段值，以便可以刷新页面的某些部分。这种类型的数据由用户直接操作，而不是普通的表单字段值。实际上，我们正在考虑在隐藏字段中更公开地存储它，这将使JavaScript能够在没有回发的情况下对其进行操作。

• “表单值哈希”。这是呈现页面时所有表单字段值的哈希值。它用于回发后通知用户自上次加载页面以来是否有任何数据在他们的脚下发生了变化。如果这个哈希遭到黑客入侵，可能会发生两件事。首先，即使没有数据发生变化，用户也可能收到“并发错误”。其次，即使数据 发生更改，用户也无法收到并发错误。第二种情况可能听起来很糟糕，但请记住，大多数Web应用程序一开始甚至没有这种类型的并发检查。

• 上次回发失败的数据修改ID。这可以是null，空或等于页面HTML中存在的一个post-back ID，并且在某些情况下用于重新运行数据修改，以便重新显示验证错误。最糟糕的黑客攻击结果是显示一组不同但仍可触发的验证错误。

Answer 2

不幸的是，它并不安全。 EnableViewStateMac的要点不是要防止控件发生往返不安全状态。这是为了防止攻击者注入自己的状态并让控件将其解释为有效状态。

EnableViewStateMac = false 是一种不安全的设置。完全停止。没有条件，没有例外，没有借口。应用程序绝不应在任何情况下将此开关设置为 false 。

事实上，由于应用程序没有正当理由这样做，我们（ASP.NET团队）将禁止在即将发布的ASP.NET版本中设置EnableViewStateMac = false。这可能会破坏已使用此设置部署的应用程序。通常情况下，我们不会做一些影响兼容性的事情，但事实上我们在这里做了一个例外，我希望能说明当我们说“没有人应该这样做”时我们有多严肃。