Skip to content
Book a call

Home / Attacks & tests / Android Sandbox Security

3 test cases

Android Sandbox Security

Sandbox testing examines whether the application stays within the isolation the platform provides, and whether it asks for more privilege than it needs. The platform's boundary is sound; what is tested here is whether the application weakens it from the inside.

What an attacker is trying to achieve

The attacker wants a way around the sandbox that the target application has provided itself: a shared identity with a weaker sibling, a permission the application holds and can be persuaded to exercise, or privileged data written somewhere unprivileged.

Test cases

3 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.

AND-SBOX-01 Shared User Resources

Objective — Determine whether the application shares a process identity or storage with other applications, extending its sandbox to include theirs.

How it is tested — Examine the manifest for a shared identity declaration and identify which other applications declare the same. Establish what becomes mutually accessible as a result: private storage, preferences, credentials and process memory. Determine whether every application in the group is held to the same standard, since the group's security becomes that of its weakest member. Test whether a third application could join the group.

Prerequisites — The manifests of every application in the group; a device with the group installed; a test application able to attempt to join.

Indicators — A shared identity in use; private data reachable from a sibling; a sibling materially weaker than the target; the group joinable by another application.

CoverageMASVS-PLATFORM-1MASVS-STORAGE-1CWE-250CWE-276

DepthManual Requires assessing the other members of the group, not just the target.

AND-SBOX-02 Excessive Permissions

Objective — Determine whether the application requests more platform privilege than its function requires, widening what an attacker gains by compromising it.

How it is tested — Enumerate the permissions requested in the manifest and trace each to the code that uses it. Identify permissions requested but never exercised, and those requested by bundled third-party components rather than by the application itself. Establish whether dangerous permissions are requested at first launch rather than when first needed, and whether the application still functions when a permission is refused.

Prerequisites — The manifest and decompiled package; a device where permissions can be granted and refused individually.

Indicators — A permission requested but never used; a dangerous permission required by a bundled component rather than the application; permissions requested up front; the application refusing to function without an unnecessary permission.

CoverageMASVS-PRIVACY-1MASVS-PLATFORM-1CWE-250CWE-272

DepthHybrid Enumeration automates; tracing each permission to a genuine use requires reading the code.

AND-SBOX-03 Disclosure of Privileged Data to Public Resources

Objective — Determine whether data the application obtains under a privileged permission is written or transmitted somewhere unprivileged, defeating the permission that protected it.

How it is tested — Identify what the application obtains under each dangerous permission — location, contacts, media, identifiers — and follow each through the code and through captured traffic to every destination. Establish whether any reaches shared storage, the system log, the clipboard, a notification, or a third-party component. Test whether such data is included in crash reports and analytics.

Prerequisites — A device with the permissions granted and real data behind them; a proxy capturing all destinations including third parties; log and filesystem access.

Indicators — Permission-protected data in shared storage or the system log; such data sent to a third-party component; location or contacts included in crash reports; privileged data in a notification.

CoverageMASVS-PRIVACY-1MASVS-STORAGE-2CWE-359CWE-200

DepthManual The work is following privileged data to every destination, including the ones the application did not intend.

What we need from you

The manifest and decompiled package; a device or emulator with filesystem and permission visibility; a second test application, including one able to declare a shared identity where the target uses one.

Standards this category maps to

Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.

  • MASVS-PLATFORM-1 — The app uses IPC mechanisms securely.
  • MASVS-STORAGE-1 — The app securely stores sensitive data.
  • CWE-250 — Execution with Unnecessary Privileges
  • CWE-276 — Incorrect Default Permissions
  • MASVS-PRIVACY-1 — The app minimizes access to sensitive data and resources.
  • CWE-272 — Least Privilege Violation
  • MASVS-STORAGE-2 — The app prevents leakage of sensitive data.
  • CWE-359 — Exposure of Private Personal Information to an Unauthorized Actor
  • CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor

Tell us what the system does and what worries you.

If a penetration test is not what you need yet, we will say so.

Book a scoping callSee the test catalogue