Class · High

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

CWE-200 · Class Level ·19 CVEs ·1 Mitigations

Description

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

There are many different kinds of mistakes that introduce information exposures. The severity of the error can range widely, depending on the context in which the product operates, the type of sensitive information that is revealed, and the benefits it may provide to an attacker. Some kinds of sensitive information include: Information might be sensitive to different parties, each of which may have their own expectations for whether the information should be protected. These parties include: Information exposures can occur in different ways: It is common practice to describe any loss of confidentiality as an "information exposure," but this can lead to overuse of CWE-200 in CWE mapping. From the CWE perspective, loss of confidentiality is a technical impact that can arise from dozens of different weaknesses, such as insecure file permissions or out-of-bounds read. CWE-200 and its lower-level descendants are intended to cover the mistakes that occur in behaviors that explicitly manage, store, transfer, or cleanse sensitive information.

Potential Impact

Confidentiality

Read Application Data

Demonstrative Examples

The following code checks validity of the supplied username and password and notifies the user of a successful or failed login.
Bad
my $username=param('username');
                  my $password=param('password');
                  
                  if (IsValidUsername($username) == 1)
                  {
                  if (IsValidPassword($username, $password) == 1)
                  {
                  print "Login Successful";
                  }
                  else
                  {
                  print "Login Failed - incorrect password";
                  }
                  }
                  else
                  {
                  print "Login Failed - unknown username";
                  }
In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials.
While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as:
Result
"Login Failed - incorrect username or password"
This code tries to open a database connection, and prints any exceptions that occur.
Bad
try {openDbConnection();}
                     //print exception message that includes exception message and configuration file location
                     catch (Exception $e) {echo 'Caught exception: ', $e->getMessage(), '\n';echo 'Check credentials in config file at: ', $Mysql_config_location, '\n';}
If an exception occurs, the printed message exposes the location of the configuration file the script is using. An attacker can use this information to target the configuration file (perhaps exploiting a Path Traversal weakness). If the file can be read, the attacker could gain credentials for accessing the database. The attacker may also be able to replace the file with a malicious one, causing the application to use an arbitrary database.
In the example below, the method getUserBankAccount retrieves a bank account object from a database using the supplied username and account number to query the database. If an SQLException is raised when querying the database, an error message is created and output to a log file.
Bad
public BankAccount getUserBankAccount(String username, String accountNumber) {
                        BankAccount userAccount = null;String query = null;try {if (isAuthorizedUser(username)) {query = "SELECT * FROM accounts WHERE owner = "+ username + " AND accountID = " + accountNumber;DatabaseManager dbManager = new DatabaseManager();Connection conn = dbManager.getConnection();Statement stmt = conn.createStatement();ResultSet queryResult = stmt.executeQuery(query);userAccount = (BankAccount)queryResult.getObject(accountNumber);}} catch (SQLException ex) {String logMessage = "Unable to retrieve account information from database,\nquery: " + query;Logger.getLogger(BankManager.class.getName()).log(Level.SEVERE, logMessage, ex);}return userAccount;
                     }
The error message that is created includes information about the database query that may contain sensitive information about the database or query logic. In this case, the error message will expose the table name and column names used in the database. This data could be used to simplify other attacks, such as SQL injection (CWE-89) to directly access the database.
This code stores location information about the current user:
Bad
locationClient = new LocationClient(this, this, this);locationClient.connect();currentUser.setLocation(locationClient.getLastLocation());
                     ...
                     
                     catch (Exception e) {AlertDialog.Builder builder = new AlertDialog.Builder(this);builder.setMessage("Sorry, this application has experienced an error.");AlertDialog alert = builder.create();alert.show();Log.e("ExampleActivity", "Caught exception: " + e + " While on User:" + User.toString());}
When the application encounters an exception it will write the user object to the log. Because the user object contains location information, the user's location is also written to the log.

Mitigations & Prevention

Architecture and Design

Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least

Detection Methods

  • Automated Static Analysis - Binary or Bytecode SOAR Partial — According to SOAR [REF-1479], the following detection techniques may be useful:
  • Dynamic Analysis with Automated Results Interpretation High — According to SOAR [REF-1479], the following detection techniques may be useful:
  • Dynamic Analysis with Manual Results Interpretation SOAR Partial — According to SOAR [REF-1479], the following detection techniques may be useful:
  • Manual Static Analysis - Source Code High — According to SOAR [REF-1479], the following detection techniques may be useful:
  • Automated Static Analysis - Source Code High — According to SOAR [REF-1479], the following detection techniques may be useful:
  • Architecture or Design Review High — According to SOAR [REF-1479], the following detection techniques may be useful:

Real-World CVE Examples

CVE IDDescription
CVE-2022-31162Rust library leaks Oauth client details in application debug logs
CVE-2021-25476Digital Rights Management (DRM) capability for mobile platform leaks pointer information, simplifying ASLR bypass
CVE-2001-1483Enumeration of valid usernames based on inconsistent responses
CVE-2001-1528Account number enumeration via inconsistent responses.
CVE-2004-2150User enumeration via discrepancies in error messages.
CVE-2005-1205Telnet protocol allows servers to obtain sensitive environment information from clients.
CVE-2002-1725Script calls phpinfo(), revealing system configuration to web user
CVE-2002-0515Product sets a different TTL when a port is being filtered than when it is not being filtered, which allows remote attackers to identify filtered ports by comparing TTLs.
CVE-2004-0778Version control system allows remote attackers to determine the existence of arbitrary files and directories via the -X command for an alternate history file, which causes different error messages to
CVE-2000-1117Virtual machine allows malicious web site operators to determine the existence of files on the client by measuring delays in the execution of the getSystemResource method.
CVE-2003-0190Product immediately sends an error message when a user does not exist, which allows remote attackers to determine valid usernames via a timing attack.
CVE-2008-2049POP3 server reveals a password in an error message after multiple APOP commands are sent. Might be resultant from another weakness.
CVE-2007-5172Program reveals password in error message if attacker can trigger certain database errors.
CVE-2008-4638Composite: application running with high privileges (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).
CVE-2007-1409Direct request to library file in web application triggers pathname leak in error message.

Showing 15 of 19 observed examples.

Taxonomy Mappings

  • PLOVER: — Information Leak (information disclosure)
  • OWASP Top Ten 2007: A6 — Information Leakage and Improper Error Handling
  • WASC: 13 — Information Leakage

Frequently Asked Questions

What is CWE-200?

CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Class-level weakness. The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

How can CWE-200 be exploited?

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

How do I prevent CWE-200?

Key mitigations include: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfaci

What is the severity of CWE-200?

CWE-200 is classified as a Class-level weakness (High abstraction). It has been observed in 19 real-world CVEs.