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.
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.
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:
Here are a few example attack scenarios for this vulnerability given by OWASP:
Automatic decryption of data from database:
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.
Use of unsalted or simple hashes to store sensitive data:
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.
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:
Encrypt all data in transit with secure protocols such as:
Enforce encryption using directives like HTTP Strict Transport Security (HSTS)