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
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.
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.
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).
Related
I'm testing an ASP.NET application using JMeter. Occasionally there will be an exception caused somewhere, and the page will redirect to an screen displaying the exception message.
How can I get JMeter to recognise this as a error? At the moment its showing as a green indicator, since I'm successfully getting a response.
I want to be able to recognise this as an error so it shows later on in the reporting/aggregation listeners.
Thanks.
You need to add an assertion as a child to the request which can check the contents of the reply and raise an error if needed.
http://jmeter.apache.org/usermanual/component_reference.html#Response_Assertion
Whats difference between return new HttpStatusCodeResult(500) and cause a real error in the action (like division by zero)?
I'm asking because my customErrors works fine when a error like division by zero ocurred, but if i return new HttpStatusCodeResult(500) the customError dont show my page
HttpStatusCodeResult is for notifying the browser of the result of an action, using an actual HTTP status code. For example, if the browser tries to load an image that is no longer available, you could send a 404. If the user is attempting to access a resource that requires authentication, you could return a 401.
Errors caused by your code often don't need to inform the browser of an error, but instead need to inform the user, using an error page with a message. This error page though, would (most likely) be sent to the browser with an HTTP status code of 200.
tldr; these are two different types of errors with different meanings, meant for different recipients.
I have read a lot about this error message.
I've learned that the most common causes for this error are
when the response is modifed by calls to Response.Write(), response filters, HttpModules
server trace is enabled.
There are some suggestions like to use a web debugger (ie. Fiddler) to get the server's response, set the EnableEventValidation="false" to the page that this error came up, set the cookie timeout and the likes.
My question, is there any other way to avoid this like doing something on the settings of the browser?
What is the point in hiding the error altering the browser settings? Your end user would still get that error as you wont be able to change their browser settings.
The key to the answer is in your question itself. You find out what is causing the error and then rectify it.
Useful read: Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it
I’ve had a bit of feedback from some threat and vulnerability folks relating to websites returning HTTP 500 response codes. Essentially the advice is that all possible measures must be taken to avoid the server throwing a 500 (i.e. extensive form input validation) which is fine.
However, the advice also suggested that attempts to compromise security by means such as inserting a tag into a random query string causing ASP.NET request validation to fire or manipulating viewstate also should not return an HTTP 500. Obviously the native framework behaviour is to interpret the request and possibly throw to a custom error page but even this will return a 500 response code.
So I’m after some thoughts on how to approach this. Is there any way to configure the app at either the .NET level or IIS level to return an HTTP 200 when a 500 is raised? Or does this become a coding exercise at global.asax level in one of the application events? Are there other consequences to consider?
BTW, the rationale from the security side is that apps which return HTTP 500 may be viewed as “low hanging fruit” by bots randomly scanning for vulnerabilities and prompt further malicious activity. attempts I’m personally not convinced that changing response codes offers any real security gains but am happy to hapy to take the advice of the pros.
To answer your question: global.asax is the correct place, in particular, the Application_Error event handler. You should be able to do something like
Response.StatusCode = 200
Response.StatusDescription = "OK"
there.
PS: Don't do it. :-) To me, this sounds like yet another security-by-obscurity-by-violating-standards approach. I really don't think the (possibly marginal) security increase is worth breaking correct HTTP behavior (think about Google indexing your error pages, etc.).
Why? Sending back a 500 code without any other information does not give an attacker much information.
Provided you don't throw stack trace, state dumps etc, back to the client then you're fine. And I doubt very much you want to do that.
Seriously, just create a "500" page (picture of a whale optional) and return that with your status 500 - it gives nothing away.
Sending a 200 status when the page was NOT generated successfully is plain wrong and may cause bad things to happen - such as bots thinking it is a genuine page. You don't want your "500 error" page showing up on Google because you sent back a 200 status instead.
You can set custom error pages in config - and you could re-set the response status in your custom error page
<customErrors mode="On" defaultRedirect="~/DefaultErrorPage.htm" >
<error statusCode="500" redirect="~/CustomError.aspx"/>
</customErrors>
Serious warning...!
Make sure there aren't any errors EVER in your custom error page. Usually, you would use a html page, not an aspx page - but if you want to change the response headers you may need to use the aspx page. Don't do anything else on there except change the headers (i.e. don't display any data from a database or try to run any logic) and error on your custom error page will cause a "maximum number of redirects" error.
Good day, everyone.
I found strange behavior within ASP.NET engine when it handles non-existent URL with whitespace.
When we have normal URL like this one: https://stackoverflow.com/questions/tagged1/c%23
we get normal custom 404 page as was intended by developers (if any).
But here's the bug. Just add some white space like this:https://stackoverflow.com/questions/tagged /c%23
and you'll see nasty ASP.NET 404 error page. Whether such a page should ever be displayed is another story. I've already made some heavy googling, made debugging research, and I can say that in this situation all custom handlers are ignored, global application class (Application_Error in global.asax) are just not reached. Actually, I don't see how can this situation be handled by ASP.NET. Any ideas?
Just as a note, this behavior is related to ASP.NET and ASP.NET MVC (as show on StackOverflow.com example). I tried other sites and found that even Microsoft.com falls into this category (see this: http://www.microsoft.com/en/us%20/default.aspx). Also, we can replace whitespace with %20 sequence with no better result.
Workaround is found.
HttpException is thrown with 'Error executing child request for pageName.aspx' message.
First of all, ASP.NET can't find requested page or route. Then exception is thrown from System.Web.CachedPathData.GetVirtualPathData (actually, from System.Web.CachedPathData.GetConfigPathData, but GetVirtualPathData makes things clear).
Then if we have any error handler, it provides some actions and tries to do something. Here we usually have Server.Transfer or Request.Redirect that moves user to page 404 or more common error page. But. In current situation HttpException is thrown anyway and we get ASP.NET error page. And in this situation Server.ClearError and Server.RewritePath can help: exception is not thrown this way. BUT! Such error handling crashes normal business logic exceptions thrown by our application.
And to resolve new trouble we have to use if/else depending on whether we receive HttpException (so we use ServerRewrite with ClearError) or some exception from our own code. But again, that's good if you provide your own exception classes, but what if not...
Anyway, I consider this a very strange case, especially that Application_Error handler is ignored whilst other application code is still executed.
Edit
As code-way was not the best selection (we can only guess that we have THIS error when exception Message is empty and InnerException is null) the better solution lies within ISAPI rewriter with rule like (\s+(\.aspx).*)|(\s+/) to custom 404 page. Here we catch all requests like /somePage .aspx and /somePath /. When we have whitespace not preceding .aspx or slash but within page name or path part we don't have mentioned problem.
Isn't it just that the request never reaches the asp.net pipeline. If you set up error documents in IIS, wouldn't they be displayed instead of the "nasty page" ?