CWE-359: Exposure of Private Personal Information to an Unauthorized Actor

Description

The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.

Potential Impact

Confidentiality

Read Application Data

Demonstrative Examples

The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account.

Bad

pass = GetPassword();...dbmsLog.WriteLine(id + ":" + pass + ":" + type + ":" + tstamp);

The code in the example above logs a plaintext password to the filesystem. Although many developers trust the filesystem as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

Bad

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

Bad

locationClient = new LocationClient(this, this, this);locationClient.connect();Location userCurrLocation;userCurrLocation = locationClient.getLastLocation();deriveStateFromCoords(userCurrLocation);

While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.

Mitigations & Prevention

Requirements

Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles. Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047], Calif

Architecture and Design

Carefully evaluate how secure design may interfere with privacy, and vice versa. Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust

ImplementationOperation

Some tools can automatically analyze documents to redact, strip, or "sanitize" private information, although some human review might be necessary. Tools may vary in terms of which document formats can be processed. When calling an external program to automatically generate or convert documents, invoke the program with any available options that avoid generating sensitive metadata. Some formats have well-defined fields that could contain private data, such as

Detection Methods

Architecture or Design Review High — Private personal data can enter a program in a variety of ways: If the data is written to an external location - such as the console, file system, or network - a privacy violation may occur.
Automated Static Analysis High — 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 sea
Automated Static Analysis — Tools are available to analyze documents (such as PDF, Word, etc.) to look for private information such as names, addresses, etc.

Real-World CVE Examples

CVE ID	Description
CVE-2023-29850	Library management product does not strip Exif data from images
CVE-2020-26220	Customer relationship management (CRM) product does not strip Exif data from images
CVE-2005-0406	Some image editors modify a JPEG image, but the original EXIF thumbnail image is left intact within the JPEG. (Also an interaction error).

Taxonomy Mappings

7 Pernicious Kingdoms: — Privacy Violation
The CERT Oracle Secure Coding Standard for Java (2011): FIO13-J — Do not log sensitive information outside a trust boundary

Frequently Asked Questions

What is CWE-359?

CWE-359 (Exposure of Private Personal Information to an Unauthorized Actor) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have t...

How can CWE-359 be exploited?

Attackers can exploit CWE-359 (Exposure of Private Personal Information to an Unauthorized Actor) to read application data. This weakness is typically introduced during the Architecture and Design, Implementation, Operation phase of software development.

How do I prevent CWE-359?

Key mitigations include: Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of busine

What is the severity of CWE-359?

CWE-359 is classified as a Base-level weakness (Medium abstraction). It has been observed in 3 real-world CVEs.