In a previous post, we covered the broken authentication security threat in detail. In this post, we’re going to talk about security threats caused due to sensitive data exposure.

Sensitive data exposure

As the name suggests, this security threat occurs when the web application doesn’t adequately protect sensitive information like session tokens, passwords, banking information, location, health data, or any other similar crucial data whose leak can be critical for the user. This threat affects users the most and can cause financial loss, access to the victim’s accounts, blackmailing which ultimately results in decreased trust in the brand.

When is the application vulnerable?

• Hardcoding data like tokens, secret_keys, passwords in the source code.

• Logging sensitive data in server logs.

• Caching sensitive data.

• Transmitting sensitive information in plain text.

• Using old or weak cryptographic algorithms.

• Using default crypto keys, generating or re-using weak crypto keys.

• User-agent (e.g. app, API) not validating received server certificate which can result in a rogue server attempting to masquerade as a legit server.

  An SSL-enabled client goes through the following steps to authenticate a server’s identity:

  • Is today’s date within the validity period?
  • Is the issuing CA a trusted CA?
  • Does the issuing CA’s public key validate the issuer’s digital signature?
  • Does the domain name in the server’s certificate match the domain name of the server itself?

Example attack scenarios

Here are a few example attack scenarios for this vulnerability given by OWASP:

1. Automatic decryption of data from database:

   • An application encrypts credit card numbers in a database using automatic database encryption. Which means — whole database encryption uses completely on-the-fly, dynamic encryption and decryption.
   • This data is automatically decrypted when retrieved via an SQL query.

   This setup opens up a possibility for SQL injection attack on the database to retrieve credit card numbers in cleartext and expose it to the attacker.

2. Use of unsalted or simple hashes to store sensitive data:

   • A password database uses unsalted or simple hashes to store everyone’s passwords.
   • Due to a file upload flaw in the application, an attacker gets access to the password database.

   The unsalted hashes obtained can be exposed with a rainbow table of pre-calculated hashes, exposing the passwords to the attacker. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.

Prevention

• It is important to identify what data collected are sensitive and classify them. This can depend on the type of application, privacy laws, regulatory requirements or business needs.

• Apply access controls on these data as per the classification.

• Don’t store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Not retaining sensitive data minimizes the risk.

• Make sure to encrypt all sensitive data at rest.

• Ensure that all encryption algorithms are latest, and strong, and that the corresponding protocols and keys are in place. Keys should be stored safely.

• Disable caching for any response that contains sensitive data.

• Store passwords using strong, adaptive and salted hashing functions with a work factor (delay factor), such as:

  • Argon2
  • scrypt
  • bcrypy
  • PBFKDF2

• Encrypt all data in transit with secure protocols such as:

  • TLS with perfect forward secrecy (PFS) ciphers.
  • Cipher prioritization by the server.

• Enforce encryption using directives like HTTP Strict Transport Security (HSTS)