Skip to content

MASWE-0007: Sensitive Data Stored Unencrypted in Shared Storage Requiring No User Interaction

Content in BETA

This content is in beta and still under active development, so it is subject to change any time (e.g. structure, IDs, content, URLs, etc.).

Send Feedback

Overview

Apps frequently opt to store data in the external storage due to its larger capacity. However, this convenience comes with a potential security drawback. Once a malicious app is granted the relevant permissions, it can access this data without user consent or interaction at any time. Additionally, external storage like SD cards can be physically removed and read by a malicious actor. Even if the external storage is emulated by the system, the risk arises from improper file permissions or the misuse of APIs for saving files. In such cases, the files become vulnerable to unauthorized access, modifications and deletions, posing a security threat to the application.

Developers may consider switching to Private Storage or Shared Storage Requiring User Interaction if they need more privacy and security. However, if the external storage is the most suitable for the app, it's a good practise to encrypt data stored in the external storage. Below you can find potential security impacts and mitigations linked to the use of the external storage.

Impact

  • Loss of confidentiality: An attacker can extract sensitive data stored externally, such as personal information and media like photos, documents, and audio files.

  • Loss of secure material: An attacker can extract passwords, cryptographic keys, and session tokens to facilitate additional attacks, such as identity theft or account takeover.

  • Modification of app's behaviour: An attacker can tamper with data used by the app, altering the app's logic. For example, they could modify a database describing the state of premium features or inject a malicious payload to enable further attacks such as SQL injection and Path Traversal.

  • Modification of downloaded code: An app can download new functionality from the Internet and store the executable code in external storage before loading it into the process. An attacker can modify this code before it is used by the app.

Modes of Introduction

This threat is primarily a concern for Android devices since they permit the use of external storage. Even if a device lacks physical external storage, Android emulates it to provide access to the external storage API.

  • Data Stored Unencrypted: Sensitive data is stored in the external storage unencrypted.
  • Hardcoded Encryption Key: Sensitive data is encrypted and stored in the external storage but the key is hardcoded inside the application.
  • Encryption Key Stored on Filesystem: Sensitive data is encrypted and stored in the external storage but the key is stored alongside it or in another easily accessible location.
  • Encryption Used is Insufficient: Sensitive data is encrypted but the encryption is not considered to be strong.
  • Reuse of encryption key: The encryption key is shared between two devices owned by a single user, enabling the process of data cloning between these devices in the external storage.

On iOS, apps cannot directly write to or read from the arbitrary locations, as compared to desktop operating system or Android. iOS maintains strict sandboxing rules, meaning apps can only access their own sandboxed file directories.

Mitigations

Sensitive data stored in the external storage should be encrypted, and any keys used for data encryption should be protected by the device's hardware-backed keystore, where available. It is highly discouraged to include cryptographic keys hardcoded inside the application. You can also consider storing your files in the private app sandbox or internal storage and using Android's EncryptedFile API wrapper for file encryption.

Tests

MASTG-TEST-0202: References to APIs and Permissions for Accessing External Storage MASTG-TEST-0200: Files Written to External Storage MASTG-TEST-0201: Runtime Use of APIs to Access External Storage