1193
this.userRoles = userRoles;
}
MemberOf Relationships
This MemberOf relationships table shows additional CWE Catgeories and Views that reference this
weakness as a member. This information is often useful in understanding where a weakness fits
within the context of external information sources.
Nature Type ID Name Page
MemberOf 485 7PK - Encapsulation 700 2328
MemberOf 884 CWE Cross-section 884 2567
MemberOf 994 SFP Secondary Cluster: Tainted Input to Variable 888 2417
MemberOf 1416 Comprehensive Categorization: Resource Lifecycle
Management
1400 2545
Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms Public Data Assigned to Private Array-
Typed Field
Software Fault Patterns SFP25 Tainted input to variable
References
[REF-6]Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A
Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools
Techniques and Metrics. 2005 November 7. NIST. < https://samate.nist.gov/SSATTM_Content/
papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security
%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf >.
CWE-497: Exposure of Sensitive System Information to an Unauthorized
Control Sphere
Weakness ID : 497
Structure : Simple
Abstraction : Base
Description
The product does not properly prevent sensitive system-level information from being accessed by
unauthorized actors who do not have the same level of access to the underlying system as the
product does.
Extended Description
Network-based products, such as web applications, often run on top of an operating system or
similar environment. When the product communicates with outside parties, details about the
underlying system are expected to remain hidden, such as path names for data files, other OS
users, installed packages, the application environment, etc. This system information may be
provided by the product itself, or buried within diagnostic or debugging messages. Debugging
information helps an adversary learn about the system and form an attack plan.
An information exposure occurs when system data or debugging information leaves the program
through an output stream or logging function that makes it accessible to unauthorized parties.
Using other weaknesses, an attacker could cause errors to occur; the response to these errors
can reveal detailed system information, along with other impacts. An attacker can use messages
that reveal technologies, operating systems, and product versions to tune the attack against known
CWE Version 4.14
CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere
CWE-497: Exposure of Sensitive System
Information to an Unauthorized Control Sphere 1194
vulnerabilities in these technologies. A product may use diagnostic methods that provide significant
implementation details such as stack traces as part of its error handling mechanism.
Relationships
The table(s) below shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOr and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition, relationships such
as PeerOf and CanAlsoBe are defined to show similar weaknesses that may want to be explored.
Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name Page
ChildOf 200 Exposure of Sensitive Information to an Unauthorized Actor 504
ParentOf 214 Invocation of Process Using Visible Sensitive Information 549
ParentOf 548 Exposure of Information Through Directory Listing 1261
Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name Page
MemberOf 199 Information Management Errors 2312
Applicable Platforms
Language : Not Language-Specific (Prevalence = Undetermined)
Common Consequences
Scope Impact Likelihood
Confidentiality Read Application Data
Detection Methods
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST),
can find some instances of this weakness by analyzing source code (or binary/compiled code)
without having to execute it. Typically, this is done by building a model of data flow and control
flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input)
with "sinks" (destinations where the data interacts with external components, a lower layer such
as the OS, etc.)
Effectiveness = High
Potential Mitigations
Phase: Architecture and Design
Phase: Implementation
Production applications should never use methods that generate internal details such as stack
traces and error messages unless that information is directly committed to a log that is not
viewable by the end user. All error message text should be HTML entity encoded before being
written to the log file to protect against potential cross-site scripting attacks against the viewer of
the logs
Demonstrative Examples
Example 1:
The following code prints the path environment variable to the standard error stream:
Example Language: C (Bad)
char* path = getenv("PATH");
...
sprintf(stderr, "cannot find exe on path %s\n", path);
CWE Version 4.14
CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere
CWE-497: Exposure of Sensitive System
Information to an Unauthorized Control Sphere