471,122 Members | 1,125 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,122 software developers and data experts.

How do I handle possible (but undesired) HTML in input?


I have a number of pages where it is valid for the user to enter HTML.
On these pages, I have turned off RequestValidation ("ValidateRequest =
false" in the page directive) so that the HttpRequestValidationException
that gets thrown if HTML is included in the Form, doesn't get thrown.

This is fine.

However, on some of those pages, there are fields where I don't want
it to be possible for the user to enter HTML. There are also other
pages where I don't want the user to enter HTML, but I *don't* want
the exception to get thrown - I want to handle it nicely, preferably
with a nice validation message.

This exception gets thrown by System.Web.HttpRequest.ValidateInput,
and its message is "A potentially dangerous Request.Form value was
detected from the client [name of control][value causing problem]".
This method validates the querystring, form, and cookies. Thus, it
gets thrown well before execution starts on any of my own code -
before Page.OnInit, that is.

As far as I can see, there are a couple of ways I can proceed:
* I can turn off Request Validation, and Server.HtmlEncode all the
values in the Form that are not allowed to be HTML. This will
translate "<" to "&lt;" and so on - this is problematic because I use
fixed-length varchars in my database (it's a DB-driven site), and .NET
currently truncates them silently. So I someone typed "<b>Headline
for fantastic article</b>" in a field that allowed 40 characters, it
would get stored as "&<lt;b&gt;Headline for fantastic article" -
without the trailing "&lt;/b&gt;". I would have to change my text
length validation to validate the Encoded strings (which would mean
encoding them client-side, or doing without client-side validation),
or I would have to make all my DB fields four times as big as they
needed to be. Neither solution is very attractive to me.

* I can turn off Request Validation, and instead call the method that
throws it inside of a Custom Validator that returns invalid if it
catches the HttpRequestValidationException. I'm worried about how to
repopulate the fields after a postback if they potentiall contain HTML
- what would it do to my page layout? Also, this would only tell me
that there is HTML in the Form, not which field it's in - ideally
(since we're doing this *properly*! :) ), I want to be able to
return a validation-error for each field that contains HTML (where
it's not allowed). This is because once the method finds a Form
variable that has HTML, it throws the exception; so it'd only be able
to point at the first field that has HTML, not all of them. Unless
it's possible to validate individual Form variables with the method -
I don't know yet.

* I can turn off Request Validation, and write (or more likely find) a
Regular Expression to validate each text input for HTML (probably just
matched pairs of angle brackets with text inside, not a check against
a list of W3C tags), and add a client-side validator to all of my text
inputs. This strikes me as maybe the simplest, but relies on finding
such an Expression, and also that the multiple calls to it are not too
heavy. It also means that if the user has Javascript turned off, my
Form will have potential HTML in it, which it will write back to the
fields from their ViewState on PostBack. However, the error message
from the serverside Condition for the RegexValidator should still be
displayed in such a case - I'm just worried about what the page might
look like, past the field with the HTML in.

For reference, the site uses Javascript, and I'm in the happy position
of being able to make "turn Javascript on" a requirement of using it -
it's primarily for corporate intranet use, where the environment is
pretty controlled.

I'm not entirely certain how to proceed - does anyone have any
comments or suggestions? Thanks in advance.

Nick Gilbert
Software Developer, X-RM Ltd
PS I've bought and am using the excellent "Professional Validation and
More" package by Peter Blum - this is why some of the validation
controls I've named are not the same as the .NET basic ones.
Nov 18 '05 #1
2 2057
Hi Nick,

As for the validation problem on the input values of the web page, I think
this is just the cross-site scritping issue and in ASP.NET1.1 it provide
the "RequestValidation" attribute which can be set to auto validate the
comming request's Form, querystring, cookie collection. Also, there is a
certain tech article written by Scott Hanselman discussing on manually do
the RequestValidation (for ASP.NET1.0 since in 1.0 there is no buildin
Request Validation for this). No sure whether you've read it before, I
think it'll be helpful:

#Adding Cross-Site Scripting Protection to ASP.NET 1.0

In addition, as you mentioned that you want some for the input fields be
validted and some other not. If so, I'm afraid we have to manually do the
validation on those certain input fields in the page's codebehind events
(such as Page_Load, Init ...).



Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no

Get Preview at ASP.NET whidbey
Nov 18 '05 #2
Hi Nick,

Have you had a chance to check out the suggestions in my last reply or have
you got any further ideas on this issue? If there're anything else we can
help, please feel free to post here. Thanks.


Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no

Get Preview at ASP.NET whidbey

Nov 18 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by NeverLift | last post: by
39 posts views Thread by tydbowl | last post: by
5 posts views Thread by mareeus | last post: by
1 post views Thread by webmasterATflymagnetic.com | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.