Skip to content

Latest commit

 

History

History
56 lines (47 loc) · 5.68 KB

File metadata and controls

56 lines (47 loc) · 5.68 KB

Attack Surface Analysis for realm/realm-java

  • Description: Direct access to the Realm database file (.realm) on the device, bypassing application security, when encryption is not used or the key is easily compromised.
  • Realm-Java Contribution: Realm Java is responsible for creating and managing the .realm file on the local file system. The library provides the encryption feature, but its use and secure configuration are the developer's responsibility.
  • Example: An attacker gains root access to a device and copies the unencrypted .realm file. Or, the application stores the Realm file in a publicly accessible directory.
  • Impact: Complete compromise of all data stored in the Realm database.
  • Risk Severity: Critical (if encryption is not used), High (if encryption is used, but key management is weak).
  • Mitigation Strategies:
    • Mandatory Encryption: Always enable Realm's built-in encryption.
    • Secure Key Storage: Store the encryption key in a secure location (Android Keystore, hardware-backed security). Never hardcode the key.
    • Proper File Permissions: Use the most restrictive file permissions. On Android, use internal storage. Avoid external storage.
  • Description: Insecure handling of the encryption key, making it vulnerable to discovery or brute-forcing.
  • Realm-Java Contribution: Realm Java provides the API for encryption, but the developer is entirely responsible for secure key management. This is a direct consequence of using the Realm encryption feature.
  • Example: The key is hardcoded, stored in plain text, or derived using a weak password and predictable salt.
  • Impact: An attacker who obtains the key decrypts the entire database, negating encryption.
  • Risk Severity: Critical.
  • Mitigation Strategies:
    • Secure Key Generation: Use a cryptographically secure random number generator.
    • Secure Key Storage: Use platform-specific secure key storage (Android Keystore, iOS Keychain).
    • Strong KDF: If deriving from a password, use a strong KDF (PBKDF2, Argon2) with a high iteration count and random salt.
    • Key Rotation: Implement a key rotation strategy.
    • Never Hardcode: Absolutely avoid hardcoding keys.
  • Description: Exploitation of weaknesses in the authentication and authorization mechanisms of Realm Sync/Atlas Device Sync, leading to unauthorized data access.
  • Realm-Java Contribution: The Realm Java SDK provides the client-side interface for interacting with Realm Sync. The correct configuration and use of authentication and authorization features within the SDK are crucial. Misuse directly impacts security.
  • Example:
    • An attacker uses compromised credentials to access synchronized data.
    • Misconfigured Flexible Sync permissions allow unauthorized data access.
  • Impact: Unauthorized access to, modification of, or deletion of synchronized data.
  • Risk Severity: High to Critical (depending on data sensitivity and the specific vulnerability).
  • Mitigation Strategies:
    • Strong Authentication: Enforce strong, unique passwords and multi-factor authentication (MFA).
    • Principle of Least Privilege: Configure Flexible Sync permissions and roles to grant only the minimum necessary access.
    • Regular Audits: Conduct regular security audits of the Atlas Device Sync configuration and client application.
    • Use App Services Authentication: Leverage MongoDB Atlas App Services authentication for robust user management.
  • Description: Incorrect management of Realm's asynchronous operations, specifically leading to data corruption due to race conditions or improper transaction handling.
  • Realm-Java Contribution: Realm Java provides asynchronous APIs. Incorrect use of these APIs by the developer directly causes this risk.
  • Example: Multiple threads attempt to write to the same Realm objects concurrently without proper synchronization (using Realm's thread-safe APIs), leading to inconsistent data or a corrupted Realm file. Or, an asynchronous write transaction is started, but a crash occurs before it's properly committed or rolled back, leaving the database in an inconsistent state.
  • Impact: Data loss or corruption, potentially rendering the database unusable.
  • Risk Severity: High.
  • Mitigation Strategies:
    • Proper Resource Management: Always close Realm instances when no longer needed. Use try-finally or Kotlin's use.
    • Thread Safety: Understand Realm's threading model. Use background threads appropriately and Realm's thread-safe APIs for cross-thread access.
    • Transaction Management: Use Realm's transaction APIs correctly. Ensure transactions are properly committed or rolled back, even in asynchronous operations. Handle exceptions appropriately.
    • Use executeTransactionAsync Correctly: Utilize asynchronous transaction methods and handle success/error callbacks meticulously.