每当用户在我的web应用程序中的页面中发布包含<或>的内容时，我都会引发此异常。
我不想因为有人在文本框中输入了字符而引发异常或使整个web应用程序崩溃，但我正在寻找一种优雅的方式来处理这一问题。
捕获异常并显示
出现错误，请返回并重新键入整个表单，但这次请不要使用<
我觉得不够专业。
禁用后验证（validateRequest=“false”）肯定可以避免此错误，但这会使页面容易受到许多攻击。
理想情况下：当发生包含HTML限制字符的回发时，表单集合中的回发值将自动进行HTML编码。因此，我的文本框的.Text属性将是<；html>；
有没有办法让我从处理者那里做到这一点？
当前回答
我也遇到了这个错误。
在我的案例中，用户在角色名称中输入了重音字符á（关于ASP.NET成员资格提供程序）。
我将角色名传递给一个方法，将用户授予该角色，而$.ajaxpost请求失败得很惨。。。
我这样做是为了解决问题：
而不是
data: { roleName: '@Model.RoleName', users: users }
这样做
data: { roleName: '@Html.Raw(@Model.RoleName)', users: users }
@Html.Raw成功了。
我得到的角色名称是HTML值roleName=“Cadastro bá；s”。此值与HTML实体á；被ASP.NET MVC阻止。现在我得到了roleName参数值，它应该是：roleName=“Cadastro Básico”，ASP.NET MVC引擎不会再阻止请求。
其他回答
前面的答案很好，但没有人说过如何排除一个字段进行HTML/JavaScript注入的验证。我不知道以前的版本，但在MVC3 Beta版中，您可以这样做：
[HttpPost, ValidateInput(true, Exclude = "YourFieldName")]
public virtual ActionResult Edit(int id, FormCollection collection)
{
...
}
这仍然会验证除排除的字段之外的所有字段。这一点的好处是，您的验证属性仍然验证字段，但您没有得到“潜在危险的请求。表单值已从客户端检测到”异常。
我已经用它验证了正则表达式。我制作了自己的ValidationAttribute，以查看正则表达式是否有效。由于正则表达式可以包含类似于脚本的内容，我应用了上面的代码-正则表达式仍然在检查是否有效，但不检查是否包含脚本或HTML。
尝试使用
服务器编码
and
Server.Html解码同时发送和接收。
对于ASP.NET 4.0，您可以将标记全部放在＜location＞元素中，从而允许标记作为特定页面的输入，而不是整个站点的输入。这将确保所有其他页面都是安全的。您不需要在.aspx页面中放入ValidateRequest=“false”。
<configuration>
...
<location path="MyFolder/.aspx">
<system.web>
<pages validateRequest="false" />
<httpRuntime requestValidationMode="2.0" />
</system.web>
</location>
...
</configuration>
在web.config中控制这一点更安全，因为您可以在站点级别看到哪些页面允许标记作为输入。
您仍然需要在禁用请求验证的页面上以编程方式验证输入。
如果您确实需要特殊字符，如，>，<等，请禁用页面验证。然后确保在显示用户输入时，数据是HTML编码的。
页面验证存在安全漏洞，因此可以绕过它。此外，不应仅依赖页面验证。
参见：http://web.archive.org/web/20080913071637/http://www.procheckup.com:80/PDFs/bypassing-dot-NET-ValidateRequest.pdf
我知道这个问题是关于表单发布的，但我想为在其他情况下收到此错误的人添加一些详细信息。它也可能发生在用于实现web服务的处理程序上。
假设您的web客户端使用ajax发送POST或PUT请求，并向web服务发送json或xml文本或原始数据（文件内容）。因为web服务不需要从Content-Type头中获取任何信息，所以JavaScript代码没有将此头设置为ajax请求。但如果您没有在POST/PUT ajax请求上设置此标头，Safari可能会添加此标头：“Content-Type:application/x-www-form-urlencoded”。我在iPhone上的Safari 6上观察到了这一点，但其他Safari版本/OS或Chrome可能也会这样做。因此，当接收到此Content-Type标头时，.NETFramework的某些部分假定请求体数据结构对应于html表单发布，而不是html表单发布，并引发HttpRequestValidationException异常。显然，要做的第一件事是在POST/PUT ajax请求中始终将Content-Type头设置为表单MIME类型以外的任何类型，即使它对web服务没有用处。
我还发现了这个细节：在这些情况下，当代码尝试访问HttpRequest.Params集合时，HttpRequestValidationException异常会出现。但令人惊讶的是，当它访问HttpRequest.ServerVariables集合时，这个异常并没有出现。这表明，虽然这两个集合看起来几乎相同，但一个通过安全检查访问请求数据，另一个则没有。
