为什么DotNetNuke禁用了验证?

时间:2010-02-25 01:47:57

标签: asp.net security dotnetnuke

任何人都可以了解为什么DotNetNuke配置了请求验证和禁用事件验证?对于默认安装,它们都处于web.config级别,这似乎是一种回归方法。是否有任何合理的理由,如果重新开启,对DotNetNuke的功能影响是什么?

显然,应该在代码中进行适当的输入验证,但原生的.NET框架行为总是一个很好的后备。

更新:Request Validation, DotNetNuke and design utopia

中对此进一步提出了想法

2 个答案:

答案 0 :(得分:4)

对所有输入进行全局验证是一种不好的做法。像大多数应用程序一样,DotNetNuke按功能为基础进行输入验证。

易受攻击代码的创建在很大程度上取决于用户输入的使用方式。例如,SQL Injection和XSS都依赖于非常不同的控制字符。不能过滤三个字符'"\中的一个来导致SQL注入,其中大多数XSS是由不过滤<>引起的。 SQL注入也可能由使用控制字符引起,例如,此代码易受SQL注入攻击,因为它没有id周围的引号:

SqlCommand("SELECT username FROM users where id="+id)

全局输入验证(例如PHP下的magic_quotes_gpc)也会失败以防止此类攻击,这也是在PHP6中删除它的原因之一。

答案 1 :(得分:4)

事实证明DotNetNuke的人已禁用此功能,以便通过富文本控件提交HTML内容。关闭请求和事件验证是设计使然。

我希望在必要时在页面级别完成此操作。全局验证绝不会免除开发人员在捕获它的每个点验证输入,但我仍然坚持认为这个功能是很好的保险并且禁用它确实会产生风险。我非常有兴趣看到有多少DNN网站存在XSS漏洞,因为没有全局验证和糟糕的开发实践。