对于隐藏字段篡改保护：Id，RowVersion，我使用Adam Tuliper AntiModelInjection的版本。
我目前正在研究一种防止篡改选择列表/下拉列表中的有效选项的方法。考虑一个多租户共享数据库解决方案，其中fk不够安全，并且在级联下拉列表中动态筛选选项。
在ASP.NET网页表单的旧时代，有一种免费添加防篡改功能的视图状态。ajax时代如何防止选择列表篡改？有没有一个通用的解决方案，通过比较哈希而不是从数据库中重新获取选项值并手动进行比较？
ViewState在ASP.NET MVC中是否相关？
如果可以，这里的唯一解决方案是根据当前用户id对该数据的权限进行筛选，然后在保存时再次验证这些权限。
如果这是不可能的（服务器端有多种方法可以通过记录中的CustomerId fk、添加到服务器端的临时安全缓存等来实现这一点），那么客户端的值可以提供一个额外的选项。
如果提供了与Web窗体类似的客户端选项，则考虑基于a.）用户id加上另一个密钥b.）SessionId（会话必须提前建立，或者会话ID可以根据请求更改，直到会话由存储在会话对象中的值建立。c.）其他一些不同的值
HTTPS在这里非常重要，所以这些值不会被嗅探。此外，理想情况下，您希望使它们每页都是唯一的。这可能是上面A中的第二把钥匙。为什么？我们不希望攻击者找到一种方法在您的网络应用程序中的其他地方创建新记录，并能够找出1、2、3、4、5、6等的哈希或加密值，并创建一个彩虹值表来伪造。
Leblanc，根据我的经验，客户端验证主要是为了方便用户。不必POST，只需发现问题所在。
最终验证需要在服务器端进行，而不能操作HTML。普通用户不会继续使用选择列表和下拉列表。这是由试图破坏你的页面或非法访问数据的人完成的。我想我的观点是，最终的安全性需要存在于服务器端，而不是客户端。
我认为，只要有一些假设，就可以创建一个全局解决方案。在构建任何东西之前，我想提出一个开放的解决方案，看看是否有人能发现缺陷或潜在问题。
考虑到所有下拉列表都可以远程检索数据。-在ajax时代和级联框中，这种情况现在更为常见。（我们正在使用剑道下降。）
public SelectList GetLocations(int dependantarg);
SelectList将作为json返回，但在让newtonsoft序列化转换器自动注入之前：（在全局级别完成）
- EncryptedAndSigned属性添加到json。此属性将包含完整SelectList的序列化版本，其中包含所有也经过加密的有效值
- json的EncryptedName属性。此属性将具有控制器actionname-在本例中，EncryptedName值将为"GetLocations"
当http发布时，EncryptedName:EncryptedAndSigned也必须在帖子中发送。对于这个JSON POST示例，它将是：
{
Location_Id: 4,
GetLocations: 'EncryptedAndSigned value'
}
在服务器端：
[ValidateOptionInjection("GetLocations","Location_Id")
public ActionResult Update(Case case)
{
//access case.Location_Id safety knowing that this was a valid option available to the user.
}