Stacktraces dangerous on a live website?

Question

We are running multiple Sitecore websites and just got feedback that it might be dangerous to have stacktraces available to users of the website when getting errors. Will the website be alot more vulnarable to hackers now that people get stacktraces?

Answer 1

Potentially. But it should never be an issue.

Answer 2

It absolutely does more harm than good. Depending on what the exception in case is, you are exposing information about your system that a visitor with ill intentions could use to look for vulnerabilities.

For example, your stack trace could be showing errors coming from the System.Data.Sql namespace, telling the person that SQL Server is to be found as part of this setup (as opposed to System.Data.MySql or Oracle, for example).

It also tells the person, which .NET calls are being made, when causing the error. Now for the sake of argument, assume that one of these had a vulnerability known only to this person - this could then be exploited to gain access.

All thought up scenarios obviously, or are they?.... ;-)

Second opinion that more or less agrees, here: http://www.expertsforge.com/Security/top-10-application-security-vulnerabilities-webconfig-files-part-one-164.asp

Answer 3

I think leaving stacktraces around can potentially help an attacker 'profile' your web site and related software. If they see a database module for example they can craft an attack based on that database software. Adding a little 'security through obscurity' in this case may be helpful and can potentially save your bacon. :-)

Answer 4

I would prefer an automated email sent to admin or logged somewhere without showing it to user. User will be shown some informative message that something broke down.

Answer 5

They should be logged on the host and absolutely not shown to the user. The user should see a sanitized and user-friendly plain language version of the error.

Answer 6

It's definately harmfull as in can be used against you. As an example take this code

Session["user"] = userName; if("denied" != getPermission(Session["user"])) redirect("login error")

I know this is not shown in the stack trace but it's a common security bug, now combined that with giving information to a possible hacker about how to (or at least whereto) provoke an exception. If he can use that information to cause an exception when calling getPermission he will no longer be redirected. Sure if there's no try-catch in that code block he might not get access (but maybe he will after all the stack trace would show that user is stored in the session)

only the stack trace is usally not that dangerous but combined with more information they will weaken your security system.