The key concept is that verbose error messages, misconfigurations, and leftover or exposed files/code can leak internal system details, enabling attackers to discover and exploit your application. See also Authentication 7 relating to different messages at the user login page to indicate that the username or the password are wrong.

Scenario: Brian’s Discovery

Imagine a situation where Brian, a potential intruder, learns about your system’s configurations, logic, and infrastructure. He does this through error messages or misconfigurations on your website. This can happen in several ways:

1. Detailed Error Messages: Error messages that inadvertently reveal software types, database structures, or even source code.
2. Default or Outdated Files: The presence of unmodified default configurations or old, test, backup files left on the server.
3. Exposed Source Code: Situations where the source code is accidentally made visible on the website.

Example

Brian attacks by accessing a server error page that is poorly configured. Instead of a generic error message, it displays detailed database error information, including software versions and file paths. This error message becomes a treasure trove of information for Brian, allowing him to identify specific vulnerabilities for targeted attacks.

Threat Modeling

STRIDE

The situation falls under the Information Disclosure category in the STRIDE threat modeling framework. Verbose error messages, default files, backup/test copies, exposed source code all give attackers extra visibility into the system’s inner workings, the risk is therefor Information Disclosure.

What can go wrong?

This kind of information leakage can lead to targeted attacks, exploitation of system vulnerabilities, and significant security breaches.

Many web applications (and other base software) usually provide error messages with information about the nature of the error by default. This is most useful to the developer, as it helps to identify where the error is happening and why. The default configuration also sometimes provides some admin functions to ease their learning curve. However, if this default behaviour is not changed in non-development environments, users (and attackers) can profit from it to acquire knowledge about the internal workings of the application and supporting systems/components.

Other sources of information disclosure are often generated by the developer. These range from messages for internal use, and are not removed when deployed in production, to simple bad programming practices. Some examples of these are:

1. Exposing sensitive information (such as session identifiers, variables references, login data, etc.) in HTTP headers, URLs, custom error messages, comments, logs, related email messages, etc.
2. Including server-side source code in outputs accessible by users.
3. Including sensitive comments in outputs accessible by users.
4. Allowing user access to configuration files.
5. Leaving default install, unused or old files in web accessible locations.
6. Revealing the application file structure (path to files in error messages or misuse of the robots.txt file).
7. Giving hints about the application workflow and/or security checks as user friendly messages.

For more things that can go wrong, see the Common Attack Patterns related to this card in the table below.

What are we going to do about it?

1. Implement generic, non-revealing error messages.
2. Ensure system configurations are secure and default installation files are removed or updated.
3. Regularly audit and clean up any old, test, or backup files.
4. Keep source code strictly protected from public exposure.

For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.