deardaniel/secdata-raw huggingface dataset:
OWASP Mobile Application Security Testing Guide: MASTG TEST 0254

---
title: Dangerous App Permissions
platform: android
id: MASTG-TEST-0254
type: [static]
weakness: MASWE-0117
profiles: [P]
knowledge: [MASTG-KNOW-0017]
---

## Overview

In Android apps, permissions are acquired through different methods to access information and system functionalities, including the camera, location, or storage. The necessary permissions are specified in the `AndroidManifest.xml` file with `<uses-permission>` tags.

## Steps

There are multiple tools that can help in finding permissions in use by an app. Refer @MASTG-TECH-0118 to and use any of the mentioned tools.

1. Extract the `AndroidManifest.xml` file from the APK (see @MASTG-TECH-0117).
2. Obtain the list of declared permissions (see @MASTG-TECH-0126).

## Observation

The output should contain the list of permissions declared by the app.

## Evaluation

The test fails if there are any dangerous permissions in the app.

Compare the list of declared permissions with the list of [dangerous permissions](https://android.googlesource.com/platform/frameworks/base/%2B/master/core/res/AndroidManifest.xml) defined by Android. You can find more details in the [Android documentation](https://developer.android.com/reference/android/Manifest.permission).

**Context Consideration**:

Context is essential when evaluating permissions. For example, an app that uses the camera to scan QR codes should have the `CAMERA` permission. However, if the app does not have a camera feature, the permission is unnecessary and should be removed.

Also, consider if there are any privacy-preserving alternatives to the permissions used by the app. For example, instead of using the `CAMERA` permission, the app could [use the device's built-in camera app](https://developer.android.com/privacy-and-security/minimize-permission-requests#take-photo) to capture photos or videos by invoking the `ACTION_IMAGE_CAPTURE` or `ACTION_VIDEO_CAPTURE` intent actions. This approach allows the app to access the camera functionality without directly requesting the `CAMERA` permission, thereby enhancing user privacy.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0256

---
platform: android
title: Missing Permission Rationale
id: MASTG-TEST-0256
weakness: MASWE-0117
status: placeholder
note: This test checks if the app does not provide a rationale for requesting permissions. See https://developer.android.com/training/permissions/requesting#explain and https://developer.android.com/training/permissions/explaining-access#privacy-dashboard-show-rationale
profiles: [P]
knowledge: [MASTG-KNOW-0017]
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0257

---
platform: android
title: Not Resetting Unused Permissions
id: MASTG-TEST-0257
weakness: MASWE-0117
status: placeholder
note: This test checks if the app does not remove unnecessary access to granted permissions. See https://developer.android.com/training/permissions/requesting#remove-access
profiles: [P]
knowledge: [MASTG-KNOW-0017]
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0319

---
platform: android
title: Runtime Use of SDK APIs Known to Handle Sensitive User Data
id: MASTG-TEST-0319
type: [dynamic]
weakness: MASWE-0112
prerequisites:
  - identify-sensitive-data
profiles: [P]
---

## Overview

This test is the dynamic counterpart to @MASTG-TEST-0318.

## Steps

1. Use @MASTG-TECH-0033 to hook SDK methods known to handle sensitive user data.

## Observation

The output should list the locations where SDK methods are called, their stacktrace (call hierarchy leading to the call), and the arguments (values) passed to the SDK method at runtime.

## Evaluation

The test case fails if you can find sensitive user data being passed to these SDK methods in the app code, indicating that the app is sharing sensitive user data with the third-party SDK. If no such data sharing is found, the test case passes.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0255

---
platform: android
title: Permission Requests Not Minimized
id: MASTG-TEST-0255
weakness: MASWE-0117
status: placeholder
note: This test checks if the app requests permissions that have privacy-preserving alternatives.
profiles: [P]
knowledge: [MASTG-KNOW-0017]
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0318

---
platform: android
title: References to SDK APIs Known to Handle Sensitive User Data
id: MASTG-TEST-0318
type: [static]
weakness: MASWE-0112
profiles: [P]
---

## Overview

This test verifies whether an app uses SDK (third-party library) APIs known to handle sensitive user data (e.g., as defined in [Google Play's Data safety section](https://support.google.com/googleplay/android-developer/answer/10787469?hl=en#types&zippy=%2Cdata-types) or the relevant privacy regulations).

As a prerequisite, we need to identify the SDK API methods it uses as entry points for data collection by reviewing the library's documentation or codebase. For example, [Google Analytics for Firebase](https://firebase.google.com/docs/analytics) in its class `FirebaseAnalytics` provides methods such as [`setUserId`](https://firebase.google.com/docs/reference/android/com/google/firebase/analytics/FirebaseAnalytics#setUserId(java.lang.String)), [`setUserProperty`](https://firebase.google.com/docs/reference/android/com/google/firebase/analytics/FirebaseAnalytics#setUserProperty(java.lang.String,%20java.lang.String)), and [`logEvent`](https://firebase.google.com/docs/reference/android/com/google/firebase/analytics/FirebaseAnalytics#logEvent(java.lang.String,%20android.os.Bundle)) that can be used to collect user data.

> Note: This test detects only **potential** sensitive user data handling. For **confirming** that actual user data are being shared, please refer to @MASTG-TEST-0319.

## Steps

1. Use @MASTG-TECH-0013 to reverse engineer the app.
2. Use @MASTG-TECH-0014 to look for uses of these methods where sensitive user data may be passed to the SDK.

## Observation

The output should list the locations where SDK methods are called.

## Evaluation

The test case fails if you can find the use of these SDK methods in the app code, indicating that the app is sharing sensitive user data with the third-party SDK. If no such references are found, the test case passes.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0206

---
platform: android
title: Undeclared PII in Network Traffic Capture
id: MASTG-TEST-0206
type: [dynamic, network]
weakness: MASWE-0108
prerequisites:
- identify-sensitive-data
- privacy-policy
- app-store-privacy-declarations
profiles: [P]
---

## Overview

Attackers may capture network traffic from Android devices using an intercepting proxy, such as @MASTG-TOOL-0079, @MASTG-TOOL-0077, or @MASTG-TOOL-0097, to analyze the data being transmitted by the app. This works even if the app uses HTTPS, as the attacker can install a custom root certificate on the Android device to decrypt the traffic. Inspecting traffic that is not encrypted with HTTPS is even easier and can be done without installing a custom root certificate for example by using @MASTG-TOOL-0081.

The goal of this test is to verify that sensitive data, specifically PII, is not being sent over the network, even if the traffic is encrypted. This test is especially important for apps that handle sensitive data, such as financial or health data, and should be performed in conjunction with a review of the app's privacy policy and the app's marketplace privacy declarations (e.g., Data Safety section in Google Play).

## Steps

1. Start the device.
2. Start logging sensitive data from network traffic (@MASTG-TECH-0100). For example using @MASTG-TOOL-0097.
3. Launch and use the app going through the various workflows while inputting sensitive data wherever you can. Especially, places where you know that will trigger network traffic.

## Observation

The output should contain a network traffic log that includes the decrypted HTTPS traffic.

## Evaluation

The test case fails if you can find the PII you entered in the app that is not declared in the app's marketplace privacy declarations (e.g., Data Safety section in Google Play) and/or in its privacy policy.

Note that this test does not provide any code locations where the sensitive data is being sent over the network. In order to identify the code locations, you can use static analysis tools like @MASTG-TOOL-0110 or dynamic analysis tools like @MASTG-TOOL-0031. Consult @MASTG-TEST-0318 and @MASTG-TEST-0319, respectively, for more details.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0310

---
platform: android
title: Runtime Use of Reused Initialization Vectors in Symmetric Encryption
id: MASTG-TEST-0310
type: [dynamic]
weakness: MASWE-0022
status: placeholder
profiles: [L2]
note: Reusing a symmetric key is acceptable when IVs or nonces follow the rules defined for the mode. NIST SP 800 38A states that CBC requires a fresh or unpredictable IV for every encryption. NIST SP 800 38D states that counter based modes require a nonce that never repeats under the same key. Repeating a key and IV or nonce pair defeats confidentiality and can also undermine integrity.
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0205

---
platform: android
title: Non-random Sources Usage
id: MASTG-TEST-0205
type: [static]
best-practices: [MASTG-BEST-0001]
prerequisites:
- identify-sensitive-data
- identify-security-relevant-contexts
weakness: MASWE-0027
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0013]
---

## Overview

Android applications sometimes use non-random sources to generate "random" values, leading to potential security vulnerabilities. Common practices include relying on the current time, such as `Date().getTime()`, or accessing `Calendar.MILLISECOND` to produce values that are easily guessable and reproducible.

## Steps

1. Run a static analysis (@MASTG-TECH-0014) tool on the app and look for uses of non-random sources.

## Observation

The output should contain a list of locations where non-random sources are used.

## Evaluation

The test case fails if you can find security-relevant values, such as passwords or tokens, generated using non-random sources.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0309

---
platform: android
title: References to Reused Initialization Vectors in Symmetric Encryption
id: MASTG-TEST-0309
type: [static]
weakness: MASWE-0022
status: placeholder
profiles: [L2]
note: Reusing a symmetric key is acceptable when IVs or nonces follow the rules defined for the mode. NIST SP 800 38A states that CBC requires a fresh or unpredictable IV for every encryption. NIST SP 800 38D states that counter based modes require a nonce that never repeats under the same key. Repeating a key and IV or nonce pair defeats confidentiality and can also undermine integrity.
---
OWASP Mobile Application Security Testing Guide: MASTG TEST 0212

---
title: Use of Hardcoded Cryptographic Keys in Code
platform: android
id: MASTG-TEST-0212
type: [static]
weakness: MASWE-0014
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0012]
---

## Overview

In this test case, we will look for the use of hardcoded keys in Android applications. To do this, we need to focus on the cryptographic implementations of hardcoded keys. The Java Cryptography Architecture (JCA) provides the [`SecretKeySpec`](https://developer.android.com/reference/javax/crypto/spec/SecretKeySpec) class, which allows you to create a [`SecretKey`](https://developer.android.com/reference/javax/crypto/SecretKey) from a byte array.

## Steps

1. Use either @MASTG-TECH-0014 with a tool such as @MASTG-TOOL-0110 or @MASTG-TECH-0033 (dynamic analysis) with a tool like @MASTG-TOOL-0001 to identify all the instances of symmetric key encryption in code and look for uses of the hardcoded cryptographic keys.

## Observation

The output should contain a list of locations where hardcoded keys are used.

## Evaluation

The test case fails if you find any hardcoded keys that are used in security-sensitive contexts.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0312

---
title: References to Explicit Security Provider in Cryptographic APIs
platform: android
id: MASTG-TEST-0312
type: [static]
weakness: MASWE-0020
best-practices: [MASTG-BEST-0020]
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0011]
---

## Overview

Android cryptography APIs based on the Java Cryptography Architecture (JCA) allow developers to specify a [security provider](https://developer.android.com/reference/java/security/Provider.html) when calling `getInstance` methods. However, explicitly specifying a provider can cause security issues and break compatibility because several providers have been deprecated or removed in recent versions. For example:

- Apps targeting Android 9 (API level 28) or above [fail when a provider is specified](https://android-developers.googleblog.com/2018/03/cryptography-changes-in-android-p.html).
- The _Crypto_ provider was deprecated in Android 7.0 (API level 24) and [removed in Android 9 (API level 28)](https://developer.android.com/about/versions/pie/android-9.0-changes-all#conscrypt_implementations_of_parameters_and_algorithms).
- The _BouncyCastle_ provider was [deprecated in Android 9 (API level 28) and removed in Android 12 (API level 31)](https://developer.android.com/about/versions/12/behavior-changes-all#bouncy-castle).

This test identifies cases where an app explicitly specifies a security provider when using JCA APIs that is not the default provider, `AndroidOpenSSL` ([Conscrypt](https://github.com/google/conscrypt)), which is actively maintained and should generally be used. It examines `getInstance` calls and flags any use of a named provider other than legitimate exceptions such as `KeyStore.getInstance("AndroidKeyStore")`.

## Steps

1. Run @MASTG-TECH-0014 with a tool such as @MASTG-TOOL-0110 on the app binary to look for calls to `getInstance` that explicitly specify a security provider.

## Observation

The output should contain a list of locations where a security provider is explicitly specified in `getInstance` calls.

## Evaluation

The test case fails if any `getInstance` call explicitly specifies a security provider other than `AndroidKeyStore` for `KeyStore` operations. Review each occurrence to determine whether the provider is actually required and whether its use could introduce security or compatibility issues on modern Android versions.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0208

---
platform: android
title: Insufficient Key Sizes 
id: MASTG-TEST-0208
type: [static]
weakness: MASWE-0009
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0012]
---

## Overview

In this test case, we will look for the use insufficient key sizes in Android apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in Android and the methods that are used to generate, inspect and manage cryptographic keys.

The Java Cryptography Architecture (JCA) provides foundational classes for key generation which are often used directly when portability or compatibility with older systems is a concern.

- **`KeyGenerator`**: The [`KeyGenerator`](https://developer.android.com/reference/javax/crypto/KeyGenerator) class is used to generate symmetric keys including AES, DES, ChaCha20 or Blowfish, as well as various HMAC keys. The key size can be specified using the [`init(int keysize)`](https://developer.android.com/reference/javax/crypto/KeyGenerator#init(int)) method.
- **`KeyPairGenerator`**: The [`KeyPairGenerator`](https://developer.android.com/reference/java/security/KeyPairGenerator) class is used for generating key pairs for asymmetric encryption (e.g., RSA, EC). The key size can be specified using the [`initialize(int keysize)`](https://developer.android.com/reference/java/security/KeyPairGenerator#initialize(int)) method.

For more information you can consult the MASTG section about ["Key Generation"](../../../Document/0x05e-Testing-Cryptography.md#key-generation).

## Steps

1. Run a static analysis tool such as @MASTG-TOOL-0110 on the code and look for uses of the cryptographic functions that generate keys.

## Observation

The output should contain a list of locations where insufficient key lengths are used.

## Evaluation

The test case fails if you can find the use of insufficient key sizes within the source code. For example, a 1024-bit key size is considered insufficient for RSA encryption and a 128-bit key size is considered insufficient for AES encryption considering quantum computing attacks.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0308

---
platform: android
title: Runtime Use of Asymmetric Key Pairs Used For Multiple Purposes
id: MASTG-TEST-0308
type: [dynamic]
weakness: MASWE-0012
profiles: [L2]
knowledge: [MASTG-KNOW-0012]
---

## Overview

This test is the dynamic counterpart to @MASTG-TEST-0307, but it focuses on intercepting cryptographic operations rather than generating keys with multiple purposes.

Some of the relevant functions to intercept are:

- [`Cipher.init(int opmode, Key key, AlgorithmParameters params)`](https://developer.android.com/reference/javax/crypto/Cipher#init(int,%20java.security.Key,%20java.security.AlgorithmParameters)) where `opmode` is one of:
    - `Cipher.ENCRYPT_MODE`
    - `Cipher.DECRYPT_MODE`
    - `Cipher.WRAP_MODE`
    - `Cipher.UNWRAP_MODE`
- [`Signature.initSign(PrivateKey privateKey)`](https://developer.android.com/reference/java/security/Signature#initSign(java.security.PrivateKey))
- [`Signature.initVerify(PublicKey publicKey)`](https://developer.android.com/reference/java/security/Signature#initVerify(java.security.PublicKey))

## Steps

1. Execute a method trace (@MASTG-TECH-0033) targeting all functions that use an asymmetric key to perform cryptographic operations.

## Observation

The output should contain a list of all cryptographic operations together with their corresponding keys.

## Evaluation

The test case fails if you find any keys used for multiple roles.

Using the output, ensure that each key (or key pair) is restricted to exactly **one** of the following groups of operations:

- Encryption/Decryption (used in `Cipher` operations with `ENCRYPT_MODE` or `DECRYPT_MODE`)
- Signing/Verification (used in `Signature` operations)
- Key Wrapping (used in `Cipher` operations with `WRAP_MODE` or `UNWRAP_MODE`)
OWASP Mobile Application Security Testing Guide: MASTG TEST 0204

---
platform: android
title: Insecure Random API Usage
id: MASTG-TEST-0204
type: [static]
best-practices: [MASTG-BEST-0001]
prerequisites:
- identify-sensitive-data
- identify-security-relevant-contexts
weakness: MASWE-0027
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0013]
---

## Overview

Android apps sometimes use an insecure [pseudorandom number generator (PRNG)](../../../Document/0x05e-Testing-Cryptography.md#random-number-generation), such as [`java.util.Random`](https://developer.android.com/reference/java/util/Random), which is a linear congruential generator and produces a predictable sequence for any given seed value. As a result, `java.util.Random` and `Math.random()` ([the latter](https://franklinta.com/2014/08/31/predicting-the-next-math-random-in-java/) simply calls `nextDouble()` on a static `java.util.Random` instance) generate reproducible sequences across all Java implementations whenever the same seed is used. This predictability makes them unsuitable for cryptographic or other security-sensitive contexts.

In general, if a PRNG is not explicitly documented as being cryptographically secure, it should not be used where randomness must be unpredictable. Refer to the [Android Documentation](https://developer.android.com/privacy-and-security/risks/weak-prng) and the ["random number generation" guide](../../../Document/0x05e-Testing-Cryptography.md#random-number-generation) for further details.

## Steps

1. Run a static analysis (@MASTG-TECH-0014) tool on the app and look for insecure random APIs, or you can use @MASTG-TECH-0033 to detect the use of such APIs.
2. For each of the identified API uses, check if they are used in a security relevant context. You can decompile the app (@MASTG-TECH-0017) and inspect the code (@MASTG-TECH-0023) to confirm.

## Observation

The output should contain a list of locations where insecure random APIs are used.

## Evaluation

The test case fails if you can find random numbers generated using those APIs that are used in security-relevant contexts, such as generating passwords or authentication tokens.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0224

---
title: Usage of Insecure APK Signature Version
platform: android
id: MASTG-TEST-0224
type: [static]
available_since: 24
weakness: MASWE-0104
best-practices: [MASTG-BEST-0006]
profiles: [R]
knowledge: [MASTG-KNOW-0003]
---

## Overview

Not using newer APK signing schemes means that the app lacks the enhanced security provided by more robust, updated mechanisms.

This test checks if the outdated v1 signature scheme is enabled. The v1 scheme is vulnerable to certain attacks, such as the "Janus" vulnerability ([CVE-2017-13156](https://nvd.nist.gov/vuln/detail/CVE-2017-13156)), because it does not cover all parts of the APK file, allowing malicious actors to potentially **modify parts of the APK without invalidating the signature**. Relying solely on v1 signing therefore increases the risk of tampering and compromises app security.

To learn more about APK Signing Schemes, see ["Signing Process"](../../../Document/0x05a-Platform-Overview.md#signing-process).

## Steps

1. Obtain the `minSdkVersion` attribute from the AndroidManifest.xml, e.g., via @MASTG-TECH-0117.
2. List all used signature schemes as shown in @MASTG-TECH-0116.

## Observation

The output should contain the value of the `minSdkVersion` attribute and the used signature schemes (for example `Verified using v3 scheme (APK Signature Scheme v3): true`).

## Evaluation

The test case fails if the app has a `minSdkVersion` attribute of 24 and above, and only the v1 signature scheme is enabled.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0225

---
title: Usage of Insecure APK Signature Key Size
platform: android
id: MASTG-TEST-0225
type: [static]
weakness: MASWE-0104
profiles: [R]
knowledge: [MASTG-KNOW-0003]
---

## Overview

For Android apps, the cryptographic strength of the APK signature is essential for maintaining the app's integrity and authenticity. Using a signature key with insufficient length, such as an RSA key shorter than 2048 bits, weakens security, making it easier for attackers to compromise the signature. This vulnerability could allow malicious actors to forge signatures, tamper with the app's code, or distribute unauthorized, modified versions.

## Steps

1. List the additional signature information using @MASTG-TECH-0116.

## Observation

The output should contain the information about the key size in a line like: `Signer #1 key size (bits):`.

## Evaluation

The test case fails if any of the key sizes (in bits) is less than 2048 (RSA). For example, `Signer #1 key size (bits): 1024`.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0264

---
platform: android
title: Runtime Use of StrictMode APIs
id: MASTG-TEST-0264
type: [dynamic]
weakness: MASWE-0094
best-practices: []
profiles: [R]
---

## Overview

This test checks whether the app uses `StrictMode` by dynamically analyzing the app's behavior and placing relevant hooks to detect the use of `StrictMode` APIs, such as `StrictMode.setVmPolicy` and `StrictMode.VmPolicy.Builder.penaltyLog`.

While `StrictMode` is useful for developers to log policy violations such as disk I/O or network operations during development, it can expose sensitive implementation details in the logs that could be exploited by attackers.

## Steps

1. Use runtime method hooking (see @MASTG-TECH-0043) and look for uses of `StrictMode` APIs.

## Observation

The output should show the runtime usage of `StrictMode` APIs.

## Evaluation

The test fails if the Frida script output shows the runtime usage of `StrictMode` APIs.