5

Frameworks for web apps typically can run in either production mode or development mode. One of the major differences between the two modes is how exceptions are handled: in development mode the browser will typically be sent a detailed exception information with a stack trace, while production mode will only serve a generic (though customizable) error page that is devoid of any more detailed information.

The frameworks' documentation will also typically warn against using development mode in production for this reason; this is an example from .NET Core:

Warning Enable the Developer Exception Page only when the app is running in the Development environment. You don't want to share detailed exception information publicly when the app runs in production.

And this is a similar warning from Django docs:

Never deploy a site into production with DEBUG turned on.

One of the main features of debug mode is the display of detailed error pages. If your app raises an exception when DEBUG is True, Django will display a detailed traceback, including a lot of metadata about your environment, such as all the currently defined Django settings (from settings.py).

I'm failing to understand the reasoning behind the aforementioned security measures?

If I understand, the reasoning goes like that: Detailed error pages would allow a potential attacker to discover details about the app's source code = they might find weaknesses = bad. Isn't it the definition of security through obscurity?

In addition: What is the use of such measures if the app is open-sourced? Disabling detailed exception pages is supposed to prevent the attacker from finding out details about its source code, but these are - by design - present in a public GitHub repository. Seemingly in this case I might just as well run the app in development mode, at least if there is an unexpected bug a user finds out they will be able to give me a more detailed information that might help me fix this bug?

If the reasoning behind the documentation warnings I quoted above is correct, then this would mean to me that developing open-sourced webapps is itself a security vulnerability! Because if allowing an attacker to find some details abou the source code is such a big deal, then how worse must it be to simply give out the source code to anyone interested! And yet, AFAIK, open source is not considered an invalid and inherently insecure model.

What am I missing here? Why should detailed exception pages be disabled?

Community
  • 1
gaazkam
  • 5,607
  • 11
  • 24
  • 37
  • TL;DR, but one reason is because it is unprofessional to have a stack trace displayed to users. – meowcat Apr 01 '19 at 21:11
  • @meowcat Being unprofessional is not yet a security vulnerability though, which is what documentation warnings seem to suggest – gaazkam Apr 01 '19 at 21:16

4 Answers4

3

It can reveal details of the implementation to an attacker that can be used to mount a better attack. Quoting from the OWASP page on improper error handling:

Even when error messages don’t provide a lot of detail, inconsistencies in such messages can still reveal important clues on how a site works, and what information is present under the covers. For example, when a user tries to access a file that does not exist, the error message typically indicates, “file not found”. When accessing a file that the user is not authorized for, it indicates, “access denied”. The user is not supposed to know the file even exists, but such inconsistencies will readily reveal the presence or absence of inaccessible files or the site’s directory structure.

Swashbuckler
  • 2,115
  • 8
  • 9
  • 1
    Yes - but the problem is that, to my understanding, we are trying to deny the attacker the very information we've already published(!) by opensourcing the app (as I described in my Q) – gaazkam Apr 01 '19 at 21:15
  • Without the information in the detailed error messages, in theory the attacker should not know in which Open Source project to look for the code. Essentially, a given HTTP error message should look the same whether triggered by Apache, nginx, IIS, or some other tool. – Mike McManus Apr 01 '19 at 21:18
  • 1
    @MikeMcManus No! I mean, if I have published the code of my webapp! Not the code of the framework that my webapp uses. – gaazkam Apr 01 '19 at 21:23
  • Denying the specific debugging information to them directly from the web site means they have to go through the trouble of digging through your source code to find that out - which is considerably less convenient. – Mike McManus Apr 01 '19 at 21:34
3

There are a couple things to consider when you enable debugging mode.

  1. Information leakage: framework version number, config values, API keys. Django has some rudimentary protection to scrub off sensitive-looking settings value from its exception page, but you shouldn't rely on this feature.

  2. Memory leaks: some frameworks keeps extended debugging information in memory to allow post mortem introspection of requests. This leads to what essentially is a memory leak that may be used by an attacker to crash the webapp. Example, Django ORM stores all SQL queries ever done on a connection when DEBUG=True.

  3. Remote code execution: some debugging framework allows you to execute server side code to introspect objects in the stack after an exception. For example, Werkzeug Debugger.

  4. Performance: collecting these debug informations can cause significant performance degradation. I have some Django views that runs in less than a second in production mode, that takes almost a minute if you turn on SQL logging and DEBUG mode with django-debug-toolbar.

All of these have a common thread, which is that debugging oriented feature are usually designed for use in a localhost environment, where security is never really an issue.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
2

To take one example you quoted, the currently defined Django settings mean the values you've set for your site. The fact that those settings exist is not a secret; the values you've given to them (like the list of administrators) might be.

I think your misunderstanding is in this reasoning:

Detailed error pages would allow a potential attacker to discover details about the app's source code

The real issue is that detailed error pages will allow the potential attacker to discover details about the app's current configuration.

A separate issue is how an attacker would find details about the app's source code (for example which app is being run what version of that app, e.g. to see if an older, more-vulnerable version is being used). And yes, detailed error pages would help with that, but there are other ways to do that, too.

Also, I would note that hiding the source code of software (i.e. closed source software) is itself "security through obscurity."

  • 1
    These seems disabled even in devel mode, to quote from django docs: "As a security measure, Django will not include settings that might be sensitive, such as SECRET_KEY. Specifically, it will exclude any setting whose name includes any of the following:" – gaazkam Apr 01 '19 at 21:25
1

It's just good practice to do so, to avoid disclosing sensitive information or any useful hints to an attacker. It's not really a vulnerability to display debug info to other people, but it can be seen as a weakness anyway. In other words, your debug info might or might not display anything interesting to an attacker, but to play it safe you had better disable it. Are you really 100% sure that your debug info will never display anything that you would want to keep private instead? I bet the answer is "not really 100%", so you'd better turn it off.

Here's a very simple example I just made up:

WARNING: $accounts is not numeric, $accounts is an array;
$accounts = (user1@example.com, user2@example.com, ...)

Suppose that for some weird reason, an error like that is displayed. Oops: the users' accounts will be leaked. Of course you might say that it's impossible, that framework X doesn't dump the content of the variables, that framework Y can't have such bugs, that you would never make such a mistake, etc. But can you be sure that will never ever happen to you, in general? Play it safe and turn it off: it's easy and it costs nothing.

reed
  • 15,398
  • 6
  • 43
  • 64