views:

36

answers:

1

We're running a site with roughly 6000-7000 visitors online concurrently (this is to indicate the size)

Having switched from ASP.Net 3.5 to 4.0 we suddenly face a mass of these:

A potentially dangerous Request.Path value was detected from the client (>).

They're all corrupted URLs, and seem to contain some sort of HTML or javascript thrown onto an otherwise valid URL.

For instance we have one like this:

/UI/Forms/Users/Photos/function(val){ var result = null; for(var i = 0; i < this.length; i++){ if( this[ i ] === val ){ result = this[ i ]; this.splice( i

As you can see it's a relative URL, and it's valid up to /Photos/. However the function(val) etc. is a function from prototype.js which is included ordinarily on the page.

We cannot recreate the issue, however this causes tens of thousands of exceptions, which we'd rather be without as the logging process takes time. Also the plethora of "irrelevant" exceptions causes our log to be much harder to read for actual issues.

Therefore I'm figuring we have little else options than disabling the validation - so the question is just how ?

I do not want to disable Request validation entirely, since that'd also disable the validation of posted form values.

Thanks a lot for any help in advance :-)

+2  A: 

If this functionality is part of your site (posting special characters to some pages) then you could add the following to your web.config:

<httpRuntime requestValidationMode="2.0" />

This will disable request validation for pages marked with ValidateRequest="false". In ASP.NET 4.0 you need this attribute or even if you disable page request validation you will get exceptions.

If on the other hand those exceptions are attacks against your site then simply do nothing and leave the ASP.NET framework drop those dangerous requests.

Darin Dimitrov
I forgot to mention I already did set this up :-/ However this functionality is definately not part of the site - but the common users are, frankly, not smart enough to perform XSS attacks, so I think it's some kind of browser issue.
Steffen
The common users might not be smart enough to perform XSS attacks but are smart enough to type `<` in an address input field for example.
Darin Dimitrov
Heh true, however the script that's included in the URL is small parts of prototype.js so I doubt it comes from users. How it gets into the URL I've no idea though.
Steffen
Maybe a bug in the code? Looking at the log files can you reproduce the problem?
Darin Dimitrov
Alas no, I've looked through all our logs to no avail. I simply cannot reproduce it. Initially I thought it was an IE 7 issue, however later I saw logs for both firefox and Chrome as well :-(
Steffen
Doesn't work with HttpHandlers ?!
Xaqron