SOUND – S for Secure Programming #3 | OWASP #3 | Sensitive Data Exposure

Atul Sharma

As part of Secure programming under SOUND Programming Methodology, we will explore 3rd security threat Sensitive Data Exposure. Before that, we have already covered

What is Sensitive Data Exposure?

This occurs when our application doesn’t protect the used sensitive data.

These below items can be classified as Sensitive data –

  • Credit card number
  • SSN, DOB or any personal information
  • Bank Account and Routing number
  • Any identification Number
  • Credentials to access any system
  • Health Information

Scenario and Preventions for Sensitive Data Exposure

Scenario #1 – Transmission over unsecured channel
  • Transmitting data in clear text with without HTTPS is big risk.
  • Use valid SSL certificate and keep certificate active.
  • Some web pages are not over HTTPS and intruder may get access to the web site from these unsecured pages.
See also  SOUND – S for Secure Programming #1 | OWASP #1 | Injection Attack
Prevention –
  • Always use HTTPS for communication.
  • Transmitted data should be encrypted with secure protocol TLS with PFS (Perfect Forward Secrecy)
  • Enforce encryption using directives like HSTS (HTTPS Strict Transport Security)
Scenario #2 – Unsecured Storage
  • Storage of credentials and other sensitive data should be very secure.
  • Sensitive data is NOT stored securely.
  • Archive of sensitive is not maintained under same strict security measures.
Prevention –
  • Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2.
  • Even after retrieval, sensitive data should NOT be passed through unsecured channel.
Scenario #3 – Weak Encryption and old algorithms
  • Use of old or default encryption techniques.
  • Use of unsalted password or simple hashes.
Prevention –
  • User proper key management for encryption and apply rotation policy on them.
  • Don’t use obsolete and default encryption mechanism for secure sensitive data.
  • Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted, so this should be taken care of.
  • Ensure to encrypt stored data at rest.
Scenario #4 – Saving of unnecessary data
  • Not adherence with EU’s General Data Protection Regulation (GDPR), or regulations.
  • Not complying with PCI DSS (Data Security Standard) and other govt regulations
Prevention –
  • Data which is not saved, can’t be stolen.
  • Disable caching for sensitive data at any stage.
See also  Events & Delegates in C#
Scenario #6 – Insufficient control and improper classification of data
  • Data access with insufficient privilege may lead to big security threat.
Prevention –
  • Data should be classified correctly.
  • Access to records should be properly configured and should be given access based on that only.

With this introduction, I hope you got a very good overview of OWASP Threat #3, Sensitive Data Exposure and will take care in your code and code review. It may NOT be applicable to all applications but recommended to consider with Banking and Finance, Healthcare and Insurance related applications.