Skip to content

Latest commit

 

History

History
48 lines (39 loc) · 4.74 KB

attack-surface.md

File metadata and controls

48 lines (39 loc) · 4.74 KB

Attack Surface Analysis for tencent/mmkv

Attack Surface: Unencrypted Sensitive Data Storage

  • Description: Storing sensitive information (passwords, tokens, PII) in MMKV without proper encryption.
  • How MMKV Contributes: MMKV provides a convenient storage mechanism, but it doesn't enforce encryption by default (although it offers an optional encryption feature). Developers might mistakenly assume it's secure without taking additional steps.
  • Example: An application stores a user's API key directly in MMKV without any encryption.
  • Impact: Complete exposure of the sensitive data if an attacker gains access to the device's storage or intercepts backups. This can lead to account compromise, data breaches, and identity theft.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Developer: Always encrypt sensitive data before storing it in MMKV, using strong, industry-standard algorithms (e.g., AES-256-GCM) and robust key management (e.g., Android Keystore, iOS Keychain). Never hardcode encryption keys.
    • Developer: Utilize MMKV's built-in encryption and securely manage the encryption key. Do not rely solely on the built-in encryption without proper key protection.
    • Developer: Minimize the amount of sensitive data stored. Only store what is absolutely necessary. Implement data retention policies to delete data when no longer needed.

Attack Surface: Weak or Mismanaged Encryption Keys (for MMKV's built-in encryption)

  • Description: Using MMKV's built-in encryption, but with a weak, predictable, or improperly stored key.
  • How MMKV Contributes: MMKV provides the option for encryption, but the security of this feature depends entirely on the key management practices of the application.
  • Example: An application uses MMKV's encryption but stores the encryption key in plain text within the application's code or in a shared preference file.
  • Impact: The encryption is rendered useless, and the data is effectively stored in plain text. An attacker who finds the key can decrypt all data.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Developer: Use a strong key derivation function (KDF) like PBKDF2, scrypt, or Argon2 to derive the encryption key from a user-provided password or other secret.
    • Developer: Store the encryption key securely using platform-specific secure storage (Android Keystore, iOS Keychain).
    • Developer: Implement key rotation policies to periodically change the encryption key.

Attack Surface: Data Tampering

  • Description: An attacker modifying the data stored in MMKV without detection.
  • How MMKV Contributes: MMKV uses CRC32 for integrity checks, which is not cryptographically secure and only detects accidental corruption, not malicious modification.
  • Example: An attacker modifies a configuration value stored in MMKV to disable a security feature within the application.
  • Impact: Application malfunction, denial of service, potential for arbitrary code execution (if the tampered data is used in a security-sensitive context), or bypassing security controls.
  • Risk Severity: High
  • Mitigation Strategies:
    • Developer: Use a cryptographic hash (e.g., SHA-256) or a Message Authentication Code (MAC) like HMAC-SHA256 to verify the integrity of the data before using it. Store the hash/MAC securely.
    • Developer: If using MMKV's encryption with an authenticated encryption mode (like GCM), this provides inherent integrity protection. However, this relies on the security of the encryption key.

Attack Surface: Data Leakage Through Backups

  • Description: Sensitive data stored in MMKV being included in unencrypted or weakly protected device backups.
  • How MMKV Contributes: MMKV stores data in files that can be included in standard device backups unless explicitly excluded.
  • Example: An application stores user session tokens in MMKV, and these tokens are included in an unencrypted cloud backup.
  • Impact: Exposure of sensitive data, potentially leading to account compromise, even if the application itself uses encryption.
  • Risk Severity: High
  • Mitigation Strategies:
    • Developer: Carefully configure backup settings to exclude sensitive data. On Android, use android:allowBackup and android:fullBackupContent in the manifest.
    • Developer: Consider using a separate, more secure storage mechanism for highly sensitive data that should never be backed up.