Sensitive Data Exposure Back

What is sensitive data?

  • Passwords
  • Credit card numbers
  • Credentials
  • Social Security Numbers
  • Health information
  • Personally identifiable information
  • Other personal information
  • ...

It is important to recognize the importance of protecting such sensitive data and privacy, in order to comply with (遵循) local privacy laws. Responsible sensitive data collection and handling have been paid more attention to after the privacy law, the General Data Protection Regulation (GDRP) released by the European Union in May 2018.

There are two types of data to protect:

  • stored data
  • transmitted data

When it comes to how to protect data in transit, one way is on a web application is by having a SSL certificate, which has protected the integrity of data in transit between the host (web server or firewall) and the client (web browser). For more detailed, you can check out "How to Install an SSL Certificate".

According to OWASP, there are some examples of what can happen when sensitive data is exposed:

Scenario #1 : An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text.

Scenario #2 : A site doesn't use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker then replays this cookie and hijacks the user's (authenticated) session, accessing or modifying the user's private data. Instead of the above they could alter all transported data, e.g. the recipient of a money transfer.

Scenario #3 : The password database uses unsalted or simple hashes to store everyone's passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.

Not encrypting sensitive data is the main reason why these attacks are still so widespread. Even encrypted data can be broken due to weak:

  • key generation process
  • key management process
  • algorithm usage
  • protocol usage
  • cipher usage
  • password hashing storage techniques

So how to prevent sensitive exposure? There are some suggestions by OWASP:

  1. Classify data processed, stored, or transmitted by an application.
  2. Recognize which data is sensitive according to local privacy laws, or business needs.
  3. Start to protect as per the classification:

    1. Don't store sensitive data if it is unnecessary. Note: Note: data that is not retained cannot be stolen

    2. Make sure to encrypt all sensitive data if you need to store them.

    3. Ensure up-to-date and strong standard algorithms, protocols, and keys are in place. Use proper key management as the same time.
    4. Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters.
    5. Enforce encryption with secure protocols by using some directives like HTTP Strict Transport Security (HSTS).
    6. Disable caching responses that contain sensitive data.
    7. Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2.
    8. Verify independently the effectiveness of configuration and settings.
Empty Comments
Sign in GitHub

As the plugin is integrated with a code management system like GitLab or GitHub, you may have to auth with your account before leaving comments around this article.

Notice: This plugin has used Cookie to store your token with an expiration.