A6 Sensitive Data Exposure

Owned by Former user (Deleted)
Last updated: Feb 02, 2018 by Former user (Deleted)
3 min read

A6 Sensitive Data Exposure

Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

The full perils of unsafe cryptography, SSL usage, and data protection are well beyond the scope of the Top 10. That said, for all sensitive data, do all of the following, at a minimum:

  1. Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit in a manner that defends against these threats.
  2. Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.
  3. Ensure strong standard algorithms and strong keys are used, and proper key management is in place. Consider using FIPS 140 validated cryptographic modules.
  4. Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt.
  5. Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data.
  6. Cryptography Storage Cheat Sheet

6.2 Providing Cryptographic Functionality

  1. Secure Cryptographic Storage Design
    1. Only store sensitive data that you need
    2. Use strong approved Authenticated Encryption
      1. Use strong approved cryptographic algorithms
      2. Use approved cryptographic modes
      3. Use strong random numbers
      4. Use Authenticated Encryption of data
    3. Store a one-way and salted value of passwords
    4. Ensure that the cryptographic protection remains secure even if access controls fail
    5. Ensure that any secret key is protected from unauthorized access
      1. Define a key lifecycle
      2. Store unencrypted keys away from the encrypted data
      3. Use independent keys when multiple keys are required
      4. Protect keys in a key vault
      5. Document concrete procedures for managing keys through the lifecycle
      6. Build support for changing algorithms and keys when needed
      7. Document concrete procedures to handle a key compromise
      8. Limit quantity of data encrypted with one key
    6. Follow applicable regulations on use of cryptography
      1. Under PCI DSS requirement 3, you must protect cardholder data


This article provides a simple model to follow when implementing solutions to protect data at rest.

6.3 Password Storage Cheat Sheet

1 Introduction

2 Guidance

  1. Do not limit the character set and set long max lengths for credentials
  2. Use a cryptographically strong credential-specific salt
  3. Impose infeasible verification on attacker
    1. Leverage an adaptive one-way function
    2. Leverage Keyed functions
  4. Design password storage assuming eventual compromise

6.4 Transport Layer

  1.  Introduction
    1. Architectural Decision
  2. Transport Layer Protection Cheat Sheet Providing Transport Layer Protection with SSL/TLS
    1. Benefits
    2. Basic Requirements
    3. SSL vs. TLS
    4. When to Use a FIPS 140-2 Validated Cryptomodule
    5. Secure Server Design
      1. 2.5.1 Rule - Use TLS for All Login Pages and All Authenticated Pages
      2. Use TLS on Any Networks (External and Internal) Transmitting Sensitive Data
      3. Do Not Provide Non-TLS Pages for Secure Content
      4. Do Not Mix TLS and Non-TLS Content
      5. Use "Secure" Cookie Flag
      6. Keep Sensitive Data Out of the URL
      7. Prevent Caching of Sensitive Data
      8. Use HTTP Strict Transport Security
      9. Use Public Key Pinning
    6. Server Certificate
      1. Use Strong Keys & Protect Them
      2. Use a Certificate That Supports Required Domain Names
      3. Use Fully Qualified Names in Certificates
      4. Do Not Use Wildcard Certificates
      5. Do Not Use RFC 1918 Addresses in Certificates
      6. Use an Appropriate Certification Authority for the Application's User Base
      7. Always Provide All Needed Certificates
      8.  Be aware of and have a plan for the SHA-1 deprecation plan
    7. Server Protocol and Cipher Configuration
      1. Only Support Strong Protocols
      2. Prefer Ephemeral Key Exchanges
      3. Only Support Strong Cryptographic Ciphers
      4. Support TLS-PSK and TLS-SRP for Mutual Authentication
      5. Only Support Secure Renegotiations
      6. Disable Compression
    8. Test your overall TLS/SSL setup and your Certificate
    9. Client (Browser) Configuration
    10. Additional Controls
      1. Extended Validation Certificates
      2. Client-Side Certificates
      3. Certificate and Public Key Pinning
      4. Secure Internal Network Fallacy
  3. Providing Transport Layer Protection for Back End and Other Connections
    1. Transport Layer Protection Cheat Sheet
    2. Protocol and Cipher Configuration for Back End and Other Connections
  4. Tools

Learn More: