views:

79

answers:

2

Can anyone shed some light on why DotNetNuke comes configured with request validation and event validation disabled? They’re both off at the web.config level for a default install which seems to be a regressive approach. Are there any sound reasons for this and what is the functional impact on DotNetNuke if they’re turned back on?

Obviously appropriate input validation should be happening in code anyway but the native .NET framework behaviour is always a nice fallback.

Update: further thoughts on this in Request Validation, DotNetNuke and design utopia

+3  A: 

Global validation of all input is a bad practice. Like most applications DotNetNuke works on a by function by function basis for input validation.

The creation of a vulnerable code is highly dependent on how the user input is being used. For instance SQL Injection and XSS both rely on very different control characters. SQL injection can be caused by not filtering one of three characters '"\, where as most XSS is caused by not filtering <>. SQL Injection can also be caused by not using control characters, for instance this code is vulnerable to SQL Injection because it doesn't have have quote marks around id:

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

Global input validation such as magic_quotes_gpc under PHP will also fail to prevent this type of attack, and that is one of the reasons why its being removed in PHP6.

Rook
Are you saying global validation itself is bad or only if it is used in place of explicitly validating input on a case by case basis? I fail to see how using it as an additional safety net is ever a bad thing. Certainly Microsoft thought it worth including.
Troy Hunt
@Troy Hunt Yes global input validation is bad. It makes programmers lazy and it will never be able to prevent all vulnerabilities. Although I admit that magic_quotes_gpc will prevent most sql injection. The problem is that *most* is not good enough, it only takes 1 vulnerability to get Pnw3d. Programmers must be responsible for the vulnerabilities they create and must know how to patch them.
Rook
+2  A: 

It turns out the folks at DotNetNuke have disabled this in order to facilitate submission of HTML content through rich text controls. Turning off both request and event validation are by design.

I would have preferred to see this done at the page level where required. Global validation in no way absolves the developer from validating input at each point where it’s captured but I still maintain having this feature is good insurance and disabling it does create a risk. I’d be very interested to see how many DNN sites out there have XSS vulnerabilities as a result of no global validation combined with poor development practice.

Troy Hunt