【问题标题】:Alternative to ValidateInput("false") when passing HTML to a controller将 HTML 传递给控制器​​时替代 ValidateInput("false")
【发布时间】:2010-01-14 05:02:47
【问题描述】:

我有一个非常简单的 ASP.NET MVC 页面,并且正在使用 TinyMCE 允许用户输入 cmets。但是,当我将数据传递给控制器​​时,我会收到以下错误消息:

一个潜在危险的 Request.Form 从客户端检测到值

共识是 ValidateInput("false") 应该设置在 Action 方法上,但不知何故,这对我来说并不合适。我试图通过订购我的操作方法并通过我的 ActionExecitomgContext ActionParameters 清理数据来拦截此错误,但是此错误一次又一次地发生。有谁知道在不禁用 ValidateInput 的情况下允许此内容通过(或正确拦截)的方法

【问题讨论】:

  • 您对该属性有什么特别关心的问题?

标签: asp.net-mvc validation


【解决方案1】:

您是否详细说明了为什么它坐得不好? ValidateInput("false") 在接受 HTML 的一个操作上是正确的方法。输入验证是一项旧的 ASP.NET 功能,默认情况下为了深度安全而启用,但它就像一把大锤。它不理解允许的 HTML 的细微差别。

对于那个操作方法,您可以编写自己的 ValidateSafeHtmlAttribute 操作过滤器并将其放在方法上。也许那个内部封装了一个设置为 false 的 ValidateInput,然后针对您的场景进行自己的验证。这是我的建议。

【讨论】:

  • 感谢您的建议。我担心的本质上是当你移除大锤时留下的洞......我宁愿尽可能保留内置的安全机制而不是插入我自己的......看起来在这种情况下,特别是因为 validateInput 充当 IAuthorizationFilter ,我必须自己动手。再次感谢!
  • 嗯,在这种情况下,大锤正在保护一个 Faberge 蛋,在保护它的同时,它会破坏你正在保护的东西。 ;)(好吧,不好的比喻)。您还可以查看 codeplex.com/AntiXSS 库,您可以调用它来尝试手动清理输入。
猜你喜欢
  • 2017-03-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-09-30
  • 2012-11-24
  • 1970-01-01
  • 1970-01-01
  • 2019-10-14
相关资源
最近更新 更多