Handle HttpRequestValidationException gracefully

microsoft.public.dotnet.framework.aspnet

21 Mar 2005 3:27 PM

Mark

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

21 Mar 2005 4:45 PM

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: PLB***@PeterBlum.com
Creator of "Professional Validation And More" at
http://www.peterblum.com/vam/home.aspx

Show quoteHide quote

"Mark" <M***@discussions.microsoft.com> wrote in message
news:BE734C08-086E-40E3-B16B-062B9D0E5CAF@microsoft.com...
> 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

Are all your drivers up to date? click for free checkup

21 Mar 2005 4:55 PM

recoil@community.nospam

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
<p> 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.

21 Mar 2005 4:57 PM

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

Show quoteHide quote

"Mark" <M***@discussions.microsoft.com> wrote in message
news:BE734C08-086E-40E3-B16B-062B9D0E5CAF@microsoft.com...
> 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

21 Mar 2005 5:12 PM

recoil@community.nospam

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.

21 Mar 2005 5:26 PM

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

Show quoteHide quote

"recoil@community.nospam" <marc.deri***@gmail.com> wrote in message
news:1111425166.008790.225600@z14g2000cwz.googlegroups.com...
> 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.
>

21 Mar 2005 5:37 PM

Mark

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

Show quoteHide quote

"Mark" wrote:

> 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