我在处理包含“危险字符”作为 Web API URL 一部分的请求时遇到问题。Url 包含一个 & ,它是正确编码的 Url,但仍会导致请求验证 ASP.NET 错误。
与 MVC 不同,似乎没有 [ValidateInput(false)] 属性来强制和禁用此功能。
我在处理包含“危险字符”作为 Web API URL 一部分的请求时遇到问题。Url 包含一个 & ,它是正确编码的 Url,但仍会导致请求验证 ASP.NET 错误。
与 MVC 不同,似乎没有 [ValidateInput(false)] 属性来强制和禁用此功能。
原来答案是在 web.config 中使用:
<system.web>
<httpRuntime requestPathInvalidCharacters="" />
</system.web>
您可以在全局或子目录级别进行设置。您可以利用该<location path="">
元素仅在某些路径下指定此设置。例如,如果受影响的 Web API 路由位于api/images下,您可以执行以下操作:
<location path="api/images">
<system.web>
<httpRuntime requestPathInvalidCharacters="" />
</system.web>
</location>
更多信息:https ://msdn.microsoft.com/en-us/library/e1f13641(v=vs.100).aspx
在配置中将 RequestValidation 设置为 4.0 时,答案是否定的。但是,您可以恢复到 2.0 请求验证,在这种情况下,MVC 属性按您的预期工作:默认验证并在需要时显式覆盖。
<httpRuntime executionTimeout="300" requestValidationMode="2.0" />
在这里详细讨论了这个和一些选项: http ://www.west-wind.com/weblog/posts/2010/Aug/19/RequestValidation-Changes-in-ASPNET-40
requestValidationType
您可以通过将元素的属性设置为httpRuntime
继承System.Web.Util.RequestValidator
并覆盖的自定义类型来对此进行更细粒度的控制IsValidRequestString
。
不幸的是,这不是 WebAPI 管道的一部分,因此不能直接检查动作过滤器(即控制器方法上的属性)之类的东西。
但是,如果您特别关心表单字段的验证,则在您访问它们之前不会调用验证器,这发生在触发操作过滤器之后,因此您可以通过创建类来选择退出使用属性的验证以下...
public class AllowFormHtmlAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(HttpActionContext actionContext)
{
HttpContext.Current.Items["AllowFormHtml"] = true;
}
}
public class CustomRequestValidator : RequestValidator
{
protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex)
{
if (context.Items["AllowFormHtml"] as bool? == true && requestValidationSource == RequestValidationSource.Form)
{
validationFailureIndex = 0;
return true;
}
return base.IsValidRequestString(
context, value, requestValidationSource, collectionKey, out validationFailureIndex);
}
}
...然后只需注释您的控制器方法[AllowFormHtml]
但是,如果您直接从 HttpRequest 访问表单字段,使用起来会更简单HttpRequest.Unvalidated
,它会绕过验证。
每个@Levi我们的网络安全人员:
配置是执行此操作的唯一方法。即使是 MVC 的[ValidateInput (false)] 对这种特殊情况也无济于事。
在Web.config中禁用它并不是一个糟糕的主意。如果您通过验证和编码不受信任的数据来遵循良好的安全实践,那么在应用程序范围内应用它是非常好的。