Or the UGLY or the ERRONEUS one ?

[teo]

I have to validate the user input
to prvent HTML injection.

I use validateRequest=True
and when a potentially malicious input occurs
AspNet immediately sends its ugly page
about the 'System.Web.HttpRequestValidationException',
a difficult to understand page and that compels the user
to go back to the previous page with his browser's button.

So I decided to manually track the Exception
in the Page_Error with this:

If ex.GetType().ToString() = "System.Web.HttpRequestValidationException"
Then
Response.Redirect("myPage.aspx")
End If.

But the Response.Redirect, Server.Transfer, Server.Execute commands
generate the ThreadAbortException error .
You can't avoid this, see 'Article ID : 312629' .
Also the Response.Redirect("myPage.aspx", False) command
is unuseful because the ugly page appears at last
(because the 'False' parameter allows the code to be processed
so the ugly page appears).

So what can I do?

----------------

Also,
how do you call another page
from within your code
if the Response.Redirect, Server.Transfer, Server.Execute
generate the ThreadAbortException error ?

 

[Winista]

Few things you can do..

1. You will need to set CustomError mode attribute to on in web.config.
2. Specify an Error page in that setting in web.config
3. Handle the exception in Application_Error event in global.asax and you
can redirect the user from there.

ThreadAbortException is by design. you should not be using generic
"Exception" handler. Handle sepecific exception in the handler.

catch(HttpRequestValidationException ex)
{
.......
}

 

[Guest]

You have the ability to wrap server side validation in a try ... catch, or
use a form of validation that is not "as fragile", so I am not sure where the
issue is.

As for redirect or server.transfer, you can handle the thread abort or you
can code to avoid the thread abort error (which happens because work is still
being done on a thread).

The validation controls are useful, but you have to determine a good
validation handling routine (or routines) to avoid simply throwing an
exception up the stack and getting the ugly page.

Now, if the ugly page is your primary concern, you can redirect the user
declaratively (to an error page) or use the global Application_Error event to
figure out what message to give the user.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[teo]

I have a news

I told that

.... Also the Response.Redirect("myPage.aspx", False) command
is unuseful because the ugly page appears at last
(because the 'False' parameter allows the code to be processed
so the ugly page appears)....

Well,
if after the Response.Redirect("myPage.aspx", False) command
I write Server.ClearError,
the ugly page doesn't appear and it appears myPage.aspx.
So it seems all solved,
but I d'like to know if with Server.ClearError
(that clears the error) the malicious string SURELY won't be
processed and no risk occurs.


-----

I have another little problem:
using the method described above,
I'm not able to pass any parameters to the myPage.aspx,
while I'd like to pass the malicious string that was on a Textbox
to let the user to see it again in a warning label on myPage.aspx


================================

To complete the discussion, I'd like to submit
another issue about catching the exception:

The malicious text is in the Textbox1 control.
The Button click event fires all.
I tried to catch the HttpRequestValidationException
at the very beginning of the Button click event

with

Try
Dim aaa As String = Request.QueryString(TextBox1.Text)
Catch myex As HttpRequestValidationException
Label3.Text = myex.Message
Exit Sub
End Try


I used ValidateRequest=true and validateRequest=false
I wrote a malicious input, ie: <script
but
I always catched nothing and the code following the Try...End Try
was always processed.
How can I have the Try block working?

 

[teo]

nobody here ?

 

[Damien]

I have a news

I told that

... Also the Response.Redirect("myPage.aspx", False) command
is unuseful because the ugly page appears at last
(because the 'False' parameter allows the code to be processed
so the ugly page appears)....

Well,
if after the Response.Redirect("myPage.aspx", False) command
I write Server.ClearError,
the ugly page doesn't appear and it appears myPage.aspx.
So it seems all solved,
but I d'like to know if with Server.ClearError
(that clears the error) the malicious string SURELY won't be
processed and no risk occurs.


-----

I have another little problem:
using the method described above,
I'm not able to pass any parameters to the myPage.aspx,
while I'd like to pass the malicious string that was on a Textbox
to let the user to see it again in a warning label on myPage.aspx

The malicious input validation is there to help you. One of the biggest
areas it tries to help you with is XSS attacks - where unvalidated user
input is echoed back to the user verbatim. And you want to echo the
user input back to the user verbatim?

If you *do* decide to go down this route, for some reason, I'd
recommend putting it into a Session variable so that it can be
retrieved on the second page. (The other option would be to append it
as a query string, but you'll hit size limits).

Please, have a very good reason for displaying it back to the user. If
you're wanting to see it for diagnostic purposes, write lots of
information to an error log or the event log, and just display a
generic "we were unable to process your request, we'll get back to
you".

Damien

 

[teo]

I have another little problem:

The malicious input validation is there to help you. One of the biggest
areas it tries to help you with is XSS attacks - where unvalidated user
input is echoed back to the user verbatim. And you want to echo the
user input back to the user verbatim?

If you *do* decide to go down this route, for some reason, I'd
recommend putting it into a Session variable so that it can be
retrieved on the second page. (The other option would be to append it
as a query string, but you'll hit size limits).

I don't like application variables and session variables,
because if the user opens the same page on another window
(I mean within the same session, so to have two instances of the
same aspx page on two separate browser windows,
I hope you understand what I 'm describing),
the variables are mixed !!!


Ok,
I don't want to send back the malicious text in any way,
but after I tracked the HttpRequestValidationException in the
Page_Error event (as described in the previous post)
I'd like to restore some control status back
(Radiobuttons, selected item on a Listbox...);
but I'm in the Page_Error event and from there
I'm not able to grab any status of any control on the webform page
to append to a query string to pass to the redirected page.
Note:
the redirected page is the same calling page
wich will display now a Label describig the occured exception.
How can you solve this?


Bytheway,
how much the size limit is?
(that is how many chars are allowed, I presume...)

 

[teo]

Damien, are you here?