Disclosure of Secrets

Disclosure of Secrets

Overview of the Vulnerability

Disclosure of secrets occurs when sensitive data is not behind an authorization barrier. When this information is exposed it can place sensitive data, such as secrets, at risk. This can occur due to a variety of scenarios such as not encrypting data, secrets committed to GitHub within public repositories, or exposed internal assets.

Examples of secret data include, but are not limited to, vendor details, client information, Personally Identifiable Information (PII), Social Security Numbers, medical data, banking information, and credentials or authentication keys. Disclosure of secrets could be used by an attacker to sell access to databases and database content, or use credentials identified to take over accounts, amongst other attack vectors.

Business Impact

Disclosure of secrets can lead to indirect financial loss through an attacker accessing, deleting, or modifying data from within the application. This could also result in reputational damage for the business through the impact to customers’ trust. The severity of the impact to the business is dependent on the sensitivity of the data being stored in, and transmitted by the application.

Steps to Reproduce

1. Use a browser to navigate to: {{url}}/data/

2. Observe that secrets are being disclosed

Proof of Concept (PoC)

The screenshots below displays the secrets disclosed:

{{screenshot}}

Guidance

Provide steps to reproduce with screenshots on how you exploited the vulnerability. This will speed triage time and result in faster rewards.

For sensitive data exposure, try to take a screenshot of the data that is being exposed, if the data includes PII, do not access this data as there are legal consequences for doing so. Describe the impact of the sensitive data being exposed, do your best to describe what the impact for this data may be to the company.

For more information on sensitive data exposure, see OWASP here and here.

Recommendation(s)

It is recommended to encrypt sensitive data, including secrets, both when at rest and when in transit. All data that is processed, stored, and transmitted by the application should be classified by business need, regulatory and industry requirements, and appropriate privacy laws.

Additionally, it is best practice to not store sensitive data when it is no longer required, as data that is not retained cannot be accessed and used maliciously. All sensitive data including secrets should therefore be a part of a regularly reviewed maintenance cycle. This review cycle should include rotation of secrets.

For more information refer to Open Web Application Security Project (OWASP) guide relating to this vulnerability: https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere