ValidateRequest question

[Dilip]

I have a question on the ValidateRequest directive at the Page level.
I ran into a case where my querystring was filled with some value that
contained the '<', '>' symbols. I promptly got this error back from
IIS:

===============
403: Access Forbidden

Due to the presence of characters known to be used in Cross Site
Scripting attacks, access is forbidden. This web site does not allow
Urls which might include embedded HTML tags.
=================

What I do not understand about this error is, who is throwing it? Is
it ASP.NET or IIS? If my querystring is rejected because
ValidateRequest directive is kicking in, then the wording of the error
happens to be different in that case, right? (something starting with
"A potentially dangerous value was detected....").

On another note -- in my laptop I have set ValidateRequest to true at
the page level but a similar URL with a '<' filled querystring value
goes through just fine.

What is happening?

thanks
--Dilip

 

[Brock Allen]

ASP.NET is trying to help in making sure the user is not trying to make a
cross site scripting attack no your site. It is checked the first time you
access Request.Form or Request.QueryString collection. You can disable this
setting:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfpagessection.asp

If you do this, then it's recommended that you validate any input data to
insure the user is not sending you malicious input.

 

[Dilip]

Brock

I understand that. I guess you didn't read my post completely.

I have validateRequest set to true at the page level on my laptop --
the request URL, even if some querystring values contain dubious chars
like '<', '>', works just fine. It looks like ASP.NET doesn't bother
to check these at all.

However, on production, I get this access forbidden error I mentioned
in my original post. That leads me to believe something else (perhaps
an ISAPI filter?) is intercepting the request before it can reach my
ASP.NET app.

Another friend pointed out that it could be because of the IIS lock
down tool which employs Urlscan to filter creepy looking requests.
That is starting to make sense to me

 

[Brock Allen]

Hmm, my first reaction would be to see if there's a diff version of ASP.NET
on the two diff machines. The implementation has varied over different versions.
In ASP.NET 2.0 the rules have been relaxed quite a bit; there were odd patterns
that would be rejected by v1.1 that wouldn't pose a threat.