Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
A potentially dangerous Request.Path
Message
From
02/09/2011 09:44:51
 
 
To
02/09/2011 09:15:12
General information
Forum:
ASP.NET
Category:
Other
Environment versions
Environment:
VB 9.0
OS:
Windows 7
Network:
Windows 2003 Server
Database:
MS SQL Server
Application:
Web
Miscellaneous
Thread ID:
01522446
Message ID:
01522575
Views:
23
>>Hmm. AFAICS you're right. Even with the replacement validator in effect the default validator still fires first. All the documentation I can find indicates that the custom version should *replace* the default - and there are even a few posts around indicating that this works as a solution. But regardless of the settings for requestValidationMode and any Page validateRequest settings the default fires first. The only way I found to prevent it was to modify the requestPathInvalidCharacters string (and handle any modified check for the removed characters to the custom validation)
>>
>>Bottom line : I couldn't find any way to completely disable the default request validator.
>>I also read that, contrary to what I thought, it is only possible to have *one* custom validator in effect per site - different ones at different levels won't work.....
>>
>>NOTE: all my testing was done using the dev server. Didn't deploy anything to a full IIS site.
>
>Thanks, this is very detailed.
>
>The only think I could see would be to change the requestPathInvalidCharacters in the httpruntime tag in the Web.Config to bypass the default. In it, I could keep all the invalid characters but the & character. Then, I can have the framework to validate on that on the path. Is this pretty much the only way you can see as well?

Yes

>But, that implies that the request would go further into the application dll. Thus, I am not sure if this & character could cause any damage before it reaches the point where I can verify on it. Because, if this is identified as an invalid character, there is probably a security reason for it.

I can't find any info on what might happen in the pipeline between the occurrence of the default validation and the custom validation. I'd guess 'not a lot' but that's not much help :-}
In fact, I'm still mystified as to why we are both seeing this behaviour when everything a read leads me to expect the opposite order of events........

I see Rick Strahl blogged about it (but doesn't mention the role of custom validators):
http://www.west-wind.com/weblog/posts/2010/Aug/19/RequestValidation-Changes-in-ASPNET-40
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform