views:

468

answers:

3

Here's an interesting one for you.

I've got my custom 500.aspx setup which is called when a 500 error occurs in my application. The 500.aspx also sends me an email with the error details.

I've noticed one small problem.

If you attempt an xss attack on the 500.aspx itself, the 500 page is not called.

This is obviously some sort of logic issue.

In fact, microsoft themselves suffer from the same issue.

See it in action here

http://www.microsoft.com/500.aspx?aspxerrorpath=%3Cscript%3Ealert(%22XSS%22)%3C/script%3E

How can I prevent this?

Ed

A: 

It appears that once you define a page to handle specific(or non specific?) errors, it is no longer available directly via its url, sorta like the Web.Config cant be called via the browser.

I would set up a 500Test.aspx which throws an exception causing a 500 error (and thus fires the 500.aspx)

That might work.

Neil N
+1  A: 

If you attempt an xss attack on any page, the custom error page will not be called (here's another random page on Microsoft.com with xss in the querystring).

The behavior appears to be intentional to stop the attack dead in its tracks. Even the error message indicates this behavior:

Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted.

The only workaround appears to be to disable validation or to capture and handle the error in your global on Application_Error.

Chris Pebble
A: 

You might want to think about handling your errors in the Application_Error event in Global.asax.cs instead of the 500.aspx page. You could put the email code there, then redirect the user to an error page after you've done your error handling (this is how we do it where I work).

Kevin Tighe