I keep reading that an ASP.NET based web site should have custom errors enabled in the web.config because exceptions will show a stack trace.
I may have a faulty memory (currently don't have access to an ASP.NET website under development), but I thought as long as Compilation debug="false" in the web.config file, then the stack trace will not be displayed.
Is my understanding correct about the debug flag and display of the stack trace? If so, then even if custom errors are not enabled, then won't the only message displayed to remote users for an exception be a the non-descriptive message:
"The page cannot be displayed because an internal server error has occurred."
If so then wouldn't it be OK, from a security perspective, to not display a custom error page for the exception?
No, a stack trace will still be shown even if the debug flag is off, but it will not have line numbers for each call in the stack.
The non-descriptive message is what the browser usually shows instead of the actual error message from the server, unless you change the configuration. Anyone wanting to expose information by causing error messages would know how to do this.
Displaying the stack trace isn't a security risk in itself, but it does expose some information that could potentially make it easier to hack the site. A hacker might for example get a clue as to what's done to sanitase the input and find a way around it.
Custom error messages should almost always be prefered over the default error thrown. It gracefully sends your user to a location where they can keep browsing your site without having to go back and try again.
Turning DEBUGGING off in your web.Config is VERY important and goes beyond just not showing the line numbers and stack trace... it also tells the compiler to build in release mode which optimizes performance dramatically. As soon as your app goes to production, all debugging should be disabled.
Related
Running Lucee server 5.2.1.9 (hosted at Vivio), and I'm unable to get it to show any run-time errors.
I have debugging enabled
I have enabled all debug info types
I've set a debug template (for all IPs); currently set to "Classic", but I've tried "Comment" and "Modern" as well.
When an error occurs, I get an empty page. If a debug template set, I get dumps of all the appropriate scopes and DB activity, as well as execution times... but no error message/details or stack trace.
Is there a setting I'm missing?
How do I insure Lucee displays my run-time errors during development?
I'm not sure if you every figured this out (kind of a necro). If you are in Dev disect your application.cfc. I had an issue in my onRequest section. Someone threw a cftry around the target page include. This ran Lucee into the catch and it showed a blank page.
If that doesn't help try removing your OnError function in there. There might be something in there that is trying to serve up a friendly error page which could prevent error output.
Also, look in Lucee server administrator and check that it is pointing to the native error.cfm that comes with the Lucee package.
I have to add it even though it isn't likely the cause. Search your code for any abort. It could be someone was testing a routine and was aborting to see how far Lucee was processing.
Hope these suggestions help.
I have a few sites in my IIS including ASP.Net and PHP. I want to define a custom pages for error handling that I can configure in IIS and it displays on errors occuring in all the sites. Say for example if error 500 is occured it displays an ASP.Net page having detailed error info of what happened actually. Is that possible?
No. = (
PHP
For your PHP sites, there are different solutions including error-logging plugins, but the standard one involves the built-in functionality of PHP's error handling. See here: http://www.nyphp.org/PHundamentals/7_PHP-Error-Handling
ASP.NET
For ASP.NET sites, this is the default behavior of the IIS error page. It will show you the exact error code, stack trace, and offending lines of code. If you wanted to, you could create your own application-level error handler to handle any and all exceptions that can occur inside your site; usually this is used to hide the nasty error message and show the user a friendlier, less-scary message instead. You can certainly re-use the code in all your different ASP.NET sites. See: http://www.codeproject.com/Articles/5977/Global-Error-Handling-in-ASP-NET
I know it's possible in asp.net to create a custom error page in a web app, by putting the following line in the web.config:
<customErrors mode="RemoteOnly" defaultRedirect="frmErrorPage.aspx" />
I have had to do this for my web app, since it is clearly much tidier than letting the program bomb out with it's ugly default error page. My custom error page just has the customer's logo and a brief message saying "Error has occurred. Please return to homepage"
The trouble now is that I have no way of knowing what caused the error, when a customer reports it.
Is there a way to make the actual error message appear on this custom error page too?
You should be using logging to know when/where/what errors occured. The POINT of the custom error page is to not allow the end user to see why it messed up because obviously that could be a security risk. Look into using ELMAH. It automatically creates a nice web gui for any uncaught exceptions. And you can also create logs when you catch the errors yourself.
If you do chose to use ELMAH, I would also strongly recommend installing it with the NuGet package manager
I'm pretty new to SharePoint and IIS, but I haven't been able to find an answer to this one. I'm deploying a custom ASPX with code-behind to my SharePoint server and need a detailed stack trace to see where my problems are.
This involves modifying the web.config file and setting three attributes of certain tags: <SafeMode CallStack="true" AllowPageLevelTrace="true" /> and <CustomErrors mode="Off" />. There are lots of different web.config files, but my error messages change when I modify a certain one, indicating that I chose the right file to edit.
Error message
The problem, however, is that when I do change these tags, I only get an error message telling me the stack trace cannot be displayed remotely, even if I try to display the page on the server itself. The error message basically tells me that in order to get the complete stack trace, I have to do what I just did: Set CustomErrors mode="Off".
I have had this happen before, but only with certain types of errors (HttpModules).
Try checking the windows event log for a more detailed message. It should be there.
Also try restarting IIS/server to make sure its clean/all services are started.
I enabled tracing in IIS7.
I set those properties to true in the ASP tab of the IIS management tool:
appAllowClientDebug,
appAllowDebugging,
errorsToNTLog,
scriptErrorSentToBrowser;
To test it, I wrote a small classic ASP test page in wich I voluntary include a bug (bad activeX name).
My asp test page is rendered until the bug line is reached. The rest of the page is not rendered. I was expecting a 500 error code, but code is always 200. There is no error file in the FailedReqLogFiles folder.
Any idea someone?
OK, i think the issue is actually with Enable Server Side Debugging. You may have it enabled, but you should disable it instead.
The server thinks it should start debugging and tries to fire up a debugger, and then doesn't find one and just gives up! I'm sure this never happened prior to IIS7.
Glood Morning,
This problem was slowing our development significantly, because sql server errors were not displayed on the browser. Our Application Service Provider tried some settings, but couldn't get it to work. They sent me the settings and I accidentally did just two at once and our problem was fixed. They told me that asp was giving return code 200 instead of the error code.
Here is what worked for us:
The combination of "Send to Browser = True" and "Enable Server Side Debugging" = False" works.
I hope that helps others.
Tom Armstrong
Look at this and see if this is stopping you from getting the 500 error. Also, If the bug is handled through an exception handler in the activeX then you might not be seeing an error on the asp response.
http://classicasp.aspfaq.com/general/why-do-i-get-a-500-internal-server-error-for-all-asp-errors.html
200 OK is a Standard response for successful HTTP requests. The status code indicates that the client's request was successfully received, understood, and accepted.
We had this same IIS7 error happening. It was not returning any kind of error. There was no error message on the screen and no 500. The page just stopped rendering.
Is that what you are seeing? I can't remember what it was unfortunately, i think it was like something was handling the error. (If this is what you are seeing, i will keep trying to remember!)
I don't think this is it but it might be: go into Error Pages > Edit Feature Settings (hidden on the right panel) and select Detailed Error? That setting is also required and you didn't mention it.