Handle HttpRequestValidationException gracefully

G

Guest

Hello,
I'm trying to handle HttpRequestValidationException. If a hacker enters
certain values into a textbox, like "<script>", it will trigger this error. I
understand why .Net has this, but I need a way to gracefully handle it.
Ideally the app would catch it as invalid input, and then return control to
the user instead of throwing an exception. This is a problem is a legitimate
user enters it into a long description box as part of a rare, but possible,
description.

I see the following options:
1 - put a regular expression validator on each file. Have the regexVal only
pass if the textbox does not contain the string "<script>".
Problem is that I can't find how to make such a regex - one that checks that
a sentence does not contain a string as opposed to just a single char.

2 - write my own custom validator that uses JavaScript to check for
occurence of the string "<script>". Then apply this new custom validator to
all the textboxes.
Problem - messy to write my own validator.

3 - disable this by setting validateRequest=false, and then do the check on
the server.
Problem - lot of extra work for the server.

4 - Treat it as a hacker error because there shouldn't be any legitimate
reason to enter those values.
Problem - this throws an exception, which bubbles up and goes to the apps
global error page. If ever there was a legitimate reason, this could annoy
the user.

As almost every ASP.Net app needs to handle this, I would expect that
there's already a standard solution.

Thanks,
Mark
 
P

Peter Blum

I have built a commercial solution to replace the
HttpRequestValidationException with powerful validators that you can
customize the rules on a field-by-field basis. Visual Input Security
(http://www.peterblum.com/vise/home.aspx) also detects SQL Injection attacks
and other input attacks on fields, querystrings and cookies.

--- Peter Blum
www.PeterBlum.com
Email: (e-mail address removed)
Creator of "Professional Validation And More" at
http://www.peterblum.com/vam/home.aspx
 
R

recoil

9 out of 10 times there should be NO reason what so ever that a user
should be submitting any type of tags.
Remember that <script> is not the only malicious form of injection and
that is why ASP.NET is so strict about this.

What I personally do, and this allows me to do so on a control by
control basis and allows me to control what gets submitted and what
does not get submitted is I use client side JavaScript to do regex
replacements.

For example I will replace all <b> <p><h1> tags to <p> <b><h1>. Now
beacuse I use regex i can take <p onload="alert('hi')"> and make sure
it gets replaced as a <p> thus eliminating various forms of javascript
injections of that nature. This also allows me to control what gets
submitted to the server and what does not get submitted to the server.

Then on the Server side I have a function that translatges the posted
&lt;p&gt; back to <p> or compatible form for client side postback, once
again using specialized regex to ensure that only elements that i want
get converted. This prevents hack attempts made through a clever POSt
request.

Imho, it would be nice if there was a better way to handle this but
from my experience there are very few solutions that fit one scenario,
and when it comes to injectionj of this nature, one really needs to
approach with a take-no-prisoner attitude.
 
W

William F. Robertson, Jr.

In my applications I wire to the client side - onBlur event and place a
space between the < and the next character.

"<script>" will become "< script>".

Of course it is a 20,000 user internal ap, so disabling client side script
is not an option. Well, they can do it, but we don't have to support their
problem. The HttpRequestValidationException will be thrown if they enter
the wrong information.

Then if the situation is there they need to be able to enter this
information, I can do a replace on the .Text propery and remove the space.

bill
 
R

recoil

once again < script> is not the only form of malicious Injection and
should NOT be the only thing that you are looking for. read my prior
reply for a small window into the different avenues for potential
injection.
 
W

William F. Robertson, Jr.

What other injections should I be worried about other than '<' followed by a
character? ie <html, <script, <etc.

I have read your previous post and that is very similiar to what I do.
Maybe you should tell me a third time what else to avoid.

bill
 
G

Guest

Hello,
Thank you all for feedback. Seems like a lot of work for something that
should be so standard, Just had another idea - what if I disabled
HttpRequestValidationException for the page, and then in the Page Error
event, caught that type of exception and swallowed it?

Although, I'm not sure how to not bubble up the exception (bubbling it up
would eventually go to a error page or display the unfriendly default error
page).

Does anyone know how to swallow the exception at the Page-Error level to
prevent it from bubbling up?

Thanks,
Mark
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top