This entry has been deprecated because it incorporated and confused multiple weaknesses. The issues formerly covered in this entry can be found at CWE-766 and CWE-767.
Modes of Introduction:
This entry has been deprecated, as it was not effective as a weakness and was structured more like a category. In addition, the name is inappropriate, since the “container” term is widely understood by developers in different ways than originally intended by PLOVER, the original source for this entry.
Modes of Introduction:
The application inserts sensitive information into debugging code, which could expose this information if the debugging code is not disabled in production.
When debugging, it may be necessary to report detailed information to the programmer. However, if the debugging code is not disabled when the application is operating in a production environment, then this sensitive information may be exposed to attackers.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Application Data
Phase: Implementation
Description:
Do not leave debug statements that could be executed in the source code. Ensure that all debug information is eradicated before releasing the software.
Phase: Architecture and Design
Description:
A process is invoked with sensitive command-line arguments, environment variables, or other elements that can be seen by other processes on the operating system.
Many operating systems allow a user to list information about processes that are owned by other users. Other users could see information such as command line arguments or environment variable settings. When this data contains sensitive information such as credentials, it might allow other users to launch an attack against the software or related resources.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Application Data
The product’s intended functionality exposes information to certain actors in accordance with the developer’s security policy, but this information is regarded as sensitive according to the intended security policies of other stakeholders such as the product’s administrator, users, or others whose information is being processed.
Modes of Introduction:
– Policy
Confidentiality: Read Application Data
The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Files or Directories, Read Application Data
Sensitive data may be exposed to an unauthorized actor in another control sphere. This may have a wide range of secondary consequences which will depend on what data is exposed. One possibility is the exposure of system data allowing an attacker to craft a specific, more effective attack.
Phase: Requirements
Description:
Clearly specify which information should be regarded as private or sensitive, and require that the product offers functionality that allows the user to cleanse the sensitive information from the resource before it is published or exported to other parties.
Phase: Architecture and Design
Description:
Phase: Implementation
Effectiveness: Defense in Depth
Description:
Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.
This makes it easier to spot places in the code where data is being used that is unencrypted.
Phase: Implementation
Description:
Avoid errors related to improper resource shutdown or release (CWE-404), which may leave the sensitive data within the resource if it is in an incomplete state.
The application performs an operation that triggers an external diagnostic or error message that is not directly generated or controlled by the application, such as an error generated by the programming language interpreter that the software uses. The error can contain sensitive system information.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Application Data
Phase: System Configuration
Description:
Configure the application’s environment in a way that prevents errors from being generated. For example, in PHP, disable display_errors.
Phase: Implementation, Build and Compilation
Description:
Debugging information should not make its way into a production release.
Phase: Implementation, Build and Compilation
Description:
Debugging information should not make its way into a production release.
Phase: Implementation
Description:
Handle exceptions internally and do not display errors containing potentially sensitive information to a user. Create default error pages if necessary.
Phase: Implementation
Description:
The best way to prevent this weakness during implementation is to avoid any bugs that could trigger the external error message. This typically happens when the program encounters fatal errors, such as a divide-by-zero. You will not always be able to control the use of error pages, and you might not be using a language that handles exceptions.
The software identifies an error condition and creates its own diagnostic or error messages that contain sensitive information.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Application Data
Phase: Implementation, Build and Compilation
Description:
Debugging information should not make its way into a production release.
Phase: Implementation, Build and Compilation
Description:
Debugging information should not make its way into a production release.
The software generates an error message that includes sensitive information about its environment, users, or associated data.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: High
Confidentiality: Read Application Data
Often this will either reveal sensitive information which may be used for a later attack or private information stored in the server.
Phase: Implementation
Description:
Phase: Implementation
Description:
Handle exceptions internally and do not display errors containing potentially sensitive information to a user.
Phase: Implementation
Effectiveness: Defense in Depth
Description:
Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.
This makes it easier to spot places in the code where data is being used that is unencrypted.
Phase: Implementation, Build and Compilation
Description:
Debugging information should not make its way into a production release.
Phase: Implementation, Build and Compilation
Description:
Debugging information should not make its way into a production release.
Phase: System Configuration
Description:
Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function.
Phase: System Configuration
Description:
Create default error pages or messages that do not leak any information.
Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.
In security-relevant contexts, even small variations in timing can be exploited by attackers to indirectly infer certain details about the product’s internal operations. For example, in some cryptographic algorithms, attackers can use timing differences to infer certain properties about a private key, making the key easier to guess. Timing discrepancies effectively form a timing side channel.
Modes of Introduction:
– Architecture and Design
Confidentiality, Access Control: Read Application Data, Bypass Protection Mechanism