HttpRequestValidationException question

[Mike Dee]

Hi - I recently took my site live and I'm getting quite a lot of
HttpRequestValidationException errors "A potentially dangerous Request.Form
value...".

I'm seeing quite a lot of these various various places so I'm quite sure
this is not something malcious but rather a problem with the way the
validation works.

Unfortunately it doesn't show me what the offending input was - is there any
way I can log this so I can see exactly what people are entering in so I can
try and reproduce it? At least its not showing in the unhandled exception
in event viewer output

I googled and it seems the only solution I've come across is to turn
Validation off, which I would rather not do. I certanly want the added
protection, but not at the expense of legitmate users not being able to
register!

My biggest question is this - If I turn off validation and then later pass
uses the inputted values as inputs for a paramaterized query, am I sill
prevented from injection attacks? In other words I'm not building my sql
using string concat. Rather I'm using parameterized queries. I think that
protects you even if the form itself is not validated, but wanted to make
sure.

Anyway I'd certainly appreciate hearing about how others have dealt with
this and if there is lots of known valid input that can cause false
positives here. My form is very basic.

--- Mike

 

[Guest]

Hi Mike,

There are two ways to stop the error.

1. Turn off validation.
2. Before postback, on the client (javascript), encode the string of the
offending textbox, then convert it back on the server--I think the javascript
function encode and the Server.HtmlDecode functions are what you will need.

You are safe from the SQL injection attacks, because it is the parameter
objects of the data provider themselves that protect from SQL injection, not
the validation. The validation protects more against cross-site scripting.

Tim

 

[Mike Dee]

Thanks Tim. The problem is that I do not know what the offending field is.
When I look at the logged exception in the event viewer it doesn't have a
field name. It shows stuff with lots of "..." and has some funny characters
in it. I think it may be special unicode chars like from a special char set
in use by the browser. Is there something special that needs to be done for
validation related to international charsets or anything like that?

Anyway in the logged exception it references something about 'a
href="...partofdomain" ' like that. I have no idea how it is picking up an
a href but it most certainly is not being typed in by users - its just
happening too frequently.

Ideas?

--- Mike

 

[PL]

There are hords of articles on the web on this so you couldn't have searched very hard.

This is MS way of making the developer aware of cross site scripting issues, usually
the first time you get the error you turn it OFF and then make sure you use HTMLEncode
in your receiving code unless of course you actually want them to submit HTML.

Of course this is entered by your users, there is no way it can just happen by itself, they are
entering HTML like the link you saw and that causes the error.

Personally I think throwing this error is like throwing a nuke on a fly, although cross site
scripting potentially could be used to spoof a website or redirect users so they enter passwords somewhere
else the issue is not that serious and most developers are not so stupid so they display unprocessed
user submissions directly on their website.

Also, I could be wrong but we have yet to see ONE single report of a serious cross site
scripting issue anywhere on the web.

PL.

 

[Guest]

Hi Mike,

It comes from user input (or anything else in the Request.Form collection,
like hidden fields) and there is a handful of cases that cause it:
1. "script" (case insensitive)
2. "expression" (case insensitive)
3. "onanything=" (could have whitespace between word and equals)
4. "&#"
5. "<x" (where x is any a-z, case insensitive, or "!")

Now to answer your question, yes it is possible it is caused by the
browser's language. I have heard of double byte languages where the first
byte is equivalent to "<" setting off the validation. I have not witnessed
this though and if this is the case, you have to decide if support for those
languages is worth doing validation yourself.

However, it seems clear from your error that someone is putting in a link
tag. The "a href=" only makes sense as part of a hyperlink, that is not
something that a user puts in alone. So the question is, is your app the
type that a user might need to post a link (or any html), or is somebody
putting benign html where it doesn't belong to check and see if your app is
vulnerable ("testing the waters"). If you are accepting a username and
password for instance, or how many widgets they need, you definitely have
people messing with your site. If you have a forum or a blog chances are it
is legit.

Tim

Tim