0

已经写了很多关于不只依赖客户端验证的文章。这只是为用户提供方便，并减少了服务器处理。这不是这个问题的内容。

我不知道这是否特定于 ASP.NET MVC 或所有 JQuery 验证，但这就是我的问题的来源。当您使用启用了客户端验证的 ReqularExpressionAttribute 时，HTML 输出类似于： data-val-regex-pattern="^[0-9a-zA-Z]{3,12}$" 只是为了抛出一个基本示例。

这不是相当不安全，明确地放弃你的表达式正在检查和不检查的内容吗？当用户可以轻松准确地阅读验证方案时，似乎更容易利用验证方案中的漏洞。而且它与服务器使用的表达式相同，因此他们也可以看到服务器检查的内容。

更新

我的示例表达式不太适合描述问题。这是关于具有非常严格格式的更复杂的数据值，并且您无意中忽略了一些漏洞

4

3 回答 3

1

您所描述的是通过默默无闻的安全性。也就是说，如果攻击者不知道如何利用它，它就是安全的。

这不是安全，如果存在漏洞，它就不安全。有句谚语：“默默无闻的安全根本就不是安全”。

它是否使它更容易被剥削？也许，但老实说..解决方案是修复您的代码。

让我们换一种说法，攻击者也可能意外发现您的漏洞。你仍然很脆弱，它仍然一样不安全。

于 2012-04-14T21:18:12.347 回答
0

这可能是一个安全漏洞，具体取决于您要验证的内容。但大多数时候，在 N 层应用程序中，您的前端模型与后端模型不同。你的后端仍然会验证它并抛出适当的异常。

关于不显眼的验证的一些信息：

jQuery 不显眼的验证利用了 data- 属性。

如果您不想要不显眼的验证，您可以在 web.config 中禁用它

尝试去 web.config 并找到这个：

<appSettings>
   <add key="ClientValidationEnabled" value="true" />
   <add key="UnobtrusiveJavaScriptEnabled" value="true" />
</appSettings>

并将 UnobtrusiveJavaScriptEnabled 设置为 false。不过，它可能还有更多的钥匙。

于 2012-04-14T20:49:45.663 回答
0

在问了这个问题一年后，我会对以前的自己说，我认为答案是验证的目的是验证输入的数据类型，而不是验证请求。因此，这不是一个值得担心的问题。

于 2013-07-31T03:31:50.343 回答