diff --git a/.github/instructions/attacks.yaml b/.github/instructions/attacks.yaml new file mode 100644 index 00000000..06795c63 --- /dev/null +++ b/.github/instructions/attacks.yaml @@ -0,0 +1,90 @@ +MAS-ATTACK-0001: Obtaining the app package and reverse engineering it. +MAS-ATTACK-0002: Debugging the app at runtime. +MAS-ATTACK-0003: Using dynamic instrumentation. +MAS-ATTACK-0004: Attaching a remote inspector to the app's debuggable web content. +MAS-ATTACK-0005: Accessing the device storage on a compromised device. +MAS-ATTACK-0006: Accessing the system logs on a compromised device or from an app holding log-access permissions. +MAS-ATTACK-0007: Accessing files exposed through incorrect file permissions or misconfigured content providers. +MAS-ATTACK-0008: Extracting local or cloud backups of the device. +MAS-ATTACK-0009: Tampering with backup contents and restoring the modified backup to a device. +MAS-ATTACK-0010: Accessing shared or external storage from any app holding the corresponding permissions. +MAS-ATTACK-0011: Physically removing and reading external storage media such as SD cards. +MAS-ATTACK-0012: Monitoring network traffic on the same network (e.g., public Wi-Fi or a compromised router). +MAS-ATTACK-0013: Monitoring local or proximity interfaces such as Bluetooth, NFC, or USB. +MAS-ATTACK-0014: Performing a Machine-in-the-Middle (MITM) attack, e.g., via ARP poisoning, DNS spoofing, or a rogue access point. +MAS-ATTACK-0015: Presenting a fraudulent or otherwise invalid certificate that the app accepts. +MAS-ATTACK-0016: Obtaining a valid certificate for the target domain from a compromised, coerced, or rogue Certificate Authority (CA). +MAS-ATTACK-0017: Installing an attacker-controlled CA certificate on a device they control to inspect the app's traffic. +MAS-ATTACK-0018: Brute-forcing cryptographic material generated with insufficient length. +MAS-ATTACK-0019: Recovering or guessing the seed used by the generator to reproduce its output. +MAS-ATTACK-0020: Intercepting cryptographic keys exported in plaintext. +MAS-ATTACK-0021: Performing cryptanalysis of broken algorithms, modes, or parameters. +MAS-ATTACK-0022: Exploiting predictable or reused IVs or nonces to detect patterns or recover plaintext. +MAS-ATTACK-0023: Exploiting padding oracles exposed through observable error signals or timing differences. +MAS-ATTACK-0024: Observing enough outputs to recover the internal state of a non-cryptographic PRNG. +MAS-ATTACK-0025: Performing offline brute-force or dictionary attacks against keys derived from low-entropy inputs. +MAS-ATTACK-0026: Precomputing derived keys when salts are missing, hardcoded, or reused. +MAS-ATTACK-0027: Invoking keystore operations on a compromised or stolen device when key use does not require user authentication. +MAS-ATTACK-0028: Crafting collisions or second preimages for broken hash functions. +MAS-ATTACK-0029: Replaying previously captured valid messages or tags. +MAS-ATTACK-0030: Recovering private keys from predictable or reused signature nonces. +MAS-ATTACK-0031: Presenting data with invalid, stripped, or attacker-signed signatures that the app accepts. +MAS-ATTACK-0032: Using a victim's device with an active session (e.g., an unlocked or stolen device). +MAS-ATTACK-0033: Reusing stolen session tokens obtained through other attacks. +MAS-ATTACK-0034: Using a known, guessed, or shoulder-surfed device credential (PIN, pattern, or password). +MAS-ATTACK-0035: Enrolling additional biometrics on the device after obtaining the device credential. +MAS-ATTACK-0036: Displaying overlays or tampering with the UI to alter what the user sees while approving an action. +MAS-ATTACK-0037: Manipulating a compromised OS to alter or fabricate the confirmation flow. +MAS-ATTACK-0038: Invoking exported or unprotected app components from another app installed on the device. +MAS-ATTACK-0039: Connecting to open ports or local services exposed by the app. +MAS-ATTACK-0040: Patching or repackaging the app to remove or alter client-side checks. +MAS-ATTACK-0041: Reading sensitive data from the clipboard when users copy it between apps. +MAS-ATTACK-0042: Phishing credentials through lookalike apps or pages when users must type them manually. +MAS-ATTACK-0043: Observing the device screen while sensitive data is displayed or entered (shoulder surfing). +MAS-ATTACK-0044: Reading notification content shown on the lock screen without unlocking the device. +MAS-ATTACK-0045: Reading notification content from another app holding notification-access permissions. +MAS-ATTACK-0046: Registering the same custom URL scheme to intercept links intended for the app. +MAS-ATTACK-0047: Delivering crafted deep links or intents from a malicious app or web page. +MAS-ATTACK-0048: Capturing user input through a malicious custom keyboard or app extension. +MAS-ATTACK-0049: Registering intent filters to intercept implicit intents sent by the app. +MAS-ATTACK-0050: Modifying or replaying mutable PendingIntents obtained from the app. +MAS-ATTACK-0051: Injecting malicious JavaScript into WebView content (e.g., via MITM on insecure connections or a compromised website). +MAS-ATTACK-0052: Harvesting on-screen content through a malicious accessibility service the user was tricked into enabling. +MAS-ATTACK-0053: Targeting users who remain on an app version with publicly known vulnerabilities. +MAS-ATTACK-0054: Installing a malicious app on a device running an OS version affected by unpatched platform vulnerabilities. +MAS-ATTACK-0055: Running the app on a device whose OS version lacks the platform protections the app relies on. +MAS-ATTACK-0056: Accessing app data exposed by legacy compatibility behaviors that the platform still applies to apps targeting an old version. +MAS-ATTACK-0057: Substituting or modifying code that the app loads at runtime from writable or unverified locations. +MAS-ATTACK-0058: Identifying deprecated components in the app package and using publicly documented attacks against them. +MAS-ATTACK-0059: Supplying crafted input through any external interface (network, IPC, files, UI, or peripherals). +MAS-ATTACK-0060: Compromising a dependency, SDK, or build tool in the app's supply chain. +MAS-ATTACK-0061: Introducing malicious code through an insider or compromised developer account. +MAS-ATTACK-0062: Distributing tampered builds that cannot be distinguished from legitimate ones. +MAS-ATTACK-0063: Accessing a lost or stolen device that has no secure lock screen configured. +MAS-ATTACK-0064: Inspecting or modifying app traffic on a device they control after bypassing transport protections (e.g., pinning). +MAS-ATTACK-0065: Running the app on a rooted or jailbroken device they control. +MAS-ATTACK-0066: Running the app in an emulator or virtual device. +MAS-ATTACK-0067: Running the app inside an app-virtualization or cloning framework. +MAS-ATTACK-0068: Impersonating the app with scripts, bots, or tampered clients when interacting with the backend. +MAS-ATTACK-0069: Installing a repackaged version of the app on victim devices. +MAS-ATTACK-0070: Modifying the app's files or resources on a compromised device. +MAS-ATTACK-0071: Capturing or recording the screen from another app or an external tool. +MAS-ATTACK-0072: Accessing screenshots automatically taken by the system, e.g., when the app moves to the background. +MAS-ATTACK-0073: Identifying vulnerable dependency versions in the app package and using public advisories or exploits. +MAS-ATTACK-0074: Collecting and correlating identifiers and usage data across apps, devices, and services. +MAS-ATTACK-0075: Contacting undeclared tracking domains that platform enforcement cannot block. +MAS-ATTACK-0076: Handling credentials and browsing state inside the app instead of isolated system flows. +MAS-ATTACK-0077: Collecting non-resettable identifiers or misusing resettable ones. +MAS-ATTACK-0078: Linking directly identifiable data to real-world identities. +MAS-ATTACK-0079: Operating without a privacy policy or under a vague, generic, or inaccessible one. +MAS-ATTACK-0080: Deviating from the practices stated in the published privacy policy. +MAS-ATTACK-0081: Collecting or sharing data categories that are not declared in the platform's privacy labels. +MAS-ATTACK-0082: Transmitting undeclared identifiers or analytics data to first- or third-party services over the network. +MAS-ATTACK-0083: Providing no way for users to delete, export, modify, or opt out of the collection of their data. +MAS-ATTACK-0084: Making profile details, activity status, or discoverability visible to other users or third parties by default. +MAS-ATTACK-0085: Collecting data under consent that is bundled, implied, or otherwise not freely and specifically given. +MAS-ATTACK-0086: Continuing to collect data under an outdated consent after practices have changed. +MAS-ATTACK-0087: Exporting or sharing data through flows whose privacy consequences are not evident to the user. +MAS-ATTACK-0088: Holding excessive or no-longer-needed permissions granted to the app. +MAS-ATTACK-0089: Using permissions granted to the host app to call protected APIs and collect data from a third-party SDK. +MAS-ATTACK-0090: Forging a MAC or tag by exploiting non-constant-time verification or distinguishable error responses. diff --git a/.github/instructions/impact.yaml b/.github/instructions/impact.yaml new file mode 100644 index 00000000..344c9ced --- /dev/null +++ b/.github/instructions/impact.yaml @@ -0,0 +1,10 @@ +- Compromise of Sensitive Data +- Authentication or Authorization Bypass +- Bypass of Protection Mechanisms +- Execution of Unauthorized Code +- Financial Loss +- Compromise of System Integrity and Business Operations +- Violation of User Privacy +- Loss of User Trust +- Legal and Regulatory Non-Compliance +- Compromise of Content or UI Integrity diff --git a/.github/instructions/index.md b/.github/instructions/index.md index 93207f8c..c4208e8e 100644 --- a/.github/instructions/index.md +++ b/.github/instructions/index.md @@ -9,10 +9,22 @@ The MASWE project includes specific requirements and formatting guidelines. Use The following writing guidelines are available. | File | Applies to | Purpose | -|------|-----------|---------| +| ---- | ---------- | ------- | | [markdown.instructions.md](markdown.instructions.md) | `**/*.md` | Shared writing style, cross-references, and LLM disclosure policy | | [maswe.instructions.md](maswe.instructions.md) | `weaknesses/**/*.md` | MASWE weakness file structure, front matter, sections, and template | +## Shared Vocabularies + +MASWE files reference these controlled vocabularies instead of restating their content. + +| File | Referenced from | Purpose | +| ---- | --------------- | ------- | +| [threats.yaml](threats.yaml) | `threat:` front matter | `MAS-THREAT-XXXX` outcomes attackers can achieve | +| [attacks.yaml](attacks.yaml) | `attacks:` front matter | `MAS-ATTACK-XXXX` paths through which a threat is realized | +| [impact.yaml](impact.yaml) | `## Impact` bullets | Canonical consequence labels (no IDs) | + +Entries in `threats.yaml` and `attacks.yaml` are append-only. Never reuse or renumber an existing ID. + ## Before You Start Before contributing content: diff --git a/.github/instructions/maswe.instructions.md b/.github/instructions/maswe.instructions.md index f7dbe08d..6a22e4a2 100644 --- a/.github/instructions/maswe.instructions.md +++ b/.github/instructions/maswe.instructions.md @@ -47,12 +47,15 @@ Required fields: title: id: MASWE-XXXX alias: +requirement: "" platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-XXXX +attacks: [MAS-ATTACK-XXXX, MAS-ATTACK-YYYY] mappings: - masvs-v1: [MSTG-- + masvs-v1: [MSTG--] masvs-v2: [MASVS--] - cwe:[CWE-ID, CWE-ID] + cwe: [CWE-ID, CWE-ID] android-risks: - If applicable refs: @@ -62,20 +65,26 @@ status: --- ``` +YAML style: do not quote list items unless required (`[android, ios]`, not `["android", "ios"]`). Keep the fields in the order shown above, with `status` last. + Field rules: - **title**: Noun phrase naming the weakness, not a sentence. No trailing period. Use title case. Avoid vendor names unless they are part of the standardized term (e.g. "Android KeyStore"). - **alias**: Short, lowercase, dash-separated version of the title. This is used for cross-referencing the weakness in MASTG content. It should be unique across all weaknesses. Examples: `weak-crypto-key-derivation`, `no-key-rotation`. +- **requirement**: A single sentence, in quotes, stating the positive security requirement that the app must fulfill (the inverse of the weakness). Example: `"The app encrypts all network traffic."` - **platform**: List of affected platforms. Use `[android, ios]` if the weakness applies to both. Use a single-item list if it is platform-specific (e.g. `[android]` for StrandHogg). - **profiles**: MAS Testing Profiles that the weakness is relevant for. Most weaknesses apply to `L1` and `L2`. Resilience weaknesses apply to `R` and Privacy to `P`. Use the current profile values defined in +- **threat**: Exactly one threat ID from `.github/instructions/threats.yaml`. The threat states the immediate outcome attackers (or, for privacy weaknesses, apps and third-party components) can achieve when the weakness is present. Each MASWE references exactly one threat. If no existing threat fits, add a new one at the end of `threats.yaml` with the next free `MAS-THREAT-XXXX` ID and reference it here. Never reuse or renumber an existing ID. +- **attacks**: List of attack IDs from `.github/instructions/attacks.yaml`, describing the paths through which the threat can be realized. List them in ascending ID order, e.g. `attacks: [MAS-ATTACK-0005, MAS-ATTACK-0006]`. At least one entry is required. If no existing attack fits, add a new one at the end of `attacks.yaml` with the next free `MAS-ATTACK-XXXX` ID and reuse it, rather than inventing per-weakness wording. Never reuse or renumber an existing ID. - **mappings**: Cross-references to related controls and weaknesses in other standards. At least one MASVS v2 control is required. Mappings to MASVS v1, CWE, and Android risks are optional but encouraged when applicable. - - **mappings.masvs-v1**: One or more MSTG v1 controls that covered this topic. This helps identify content to port from MASTG v1. - - **mappings.masvs-v2**: One or more MASVS v2 controls this weakness helps verify. At least one entry is required. - - **cwe**: One or more CWE IDs that correspond to this weakness. This helps link to the broader software security ecosystem. - - **android-risks**: One or more specific risks from the Android developer documentation (https://developer.android.com/privacy-and-security/risks) that correspond to this weakness. This is an optional field that can help link to Android-specific guidance, but it should only be used when there is a clear match + - **masvs-v1**: One or more MSTG v1 controls that covered this topic. This helps identify content to port from MASTG v1. + - **masvs-v2**: One or more MASVS v2 controls this weakness helps verify. At least one entry is required. Example: `masvs-v2: [MASVS-STORAGE-1]` which will be rendered as + - **maswe-beta**: One or more MASWE v0.x (pre-1.0.0-rc) weaknesses that this weakness supersedes or absorbs. This is optional but encouraged for traceability. + - **cwe**: One or more CWE IDs that correspond to this weakness. This helps link to the broader software security ecosystem. Example: `cwe: [200]` which will be rendered as + - **android-risks**: One or more specific risks from the Android developer documentation (https://developer.android.com/privacy-and-security/risks/) that correspond to this weakness. This is an optional field that can help link to Android-specific guidance, but it should only be used when there is a clear match + - **android-core-app-quality**: One or more checklist item IDs from the [Android Core App Quality guidelines](https://developer.android.com/docs/quality-guidelines/core-app-quality), using the current named IDs (e.g. `android-core-app-quality: [Network_Security_Traffic]` which will be rendered as ), not the legacy `SC-*`/`PS-*` numbering. Optional; only use when there is a clear match, and only for weaknesses whose `platform` includes `android`. - **refs**: External references. Prefer stable, vendor-neutral sources (official platform docs, CWE, NIST, academic papers). -- **status**: When you generate a new MASWE draft, set -`status: new`. +- **status**: When you generate a new MASWE draft, set `status: new`. Do not invent additional front matter fields. If you believe a new field is needed, open an issue first. @@ -88,9 +97,6 @@ Use exactly these top-level section headings, in this order, all at `##` level. 3. `## Impact` 4. `## Mitigations` -Some existing approved MASWEs order `## Impact` before -`## Modes of Introduction`. Prefer the order above for new content, but do not re-order existing approved pages in an unrelated PR. - ### `## Overview` - 2-5 short paragraphs in plain prose. @@ -103,24 +109,83 @@ materially differs. ### `## Modes of Introduction` - How the weakness gets introduced into an app. Typical causes: unsafe defaults, missing configuration, unsafe API usage, copy-pasted code, outdated libraries, insufficient input validation, misuse of platform features. -- Prefer a short bulleted list (3-5 bullets). -- Each bullet starts with a **bold short label** followed by a colon and then the explanation. For example: - `- **Hardcoded Keys**: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation and reverse-engineering.` -- Each bullet describes a developer-facing cause, not a consequence. -- If the weakness can be introduced through a third-party SDK or cross-platform framework, call that out explicitly. +- They must reflect the testable aspects of the weakness, which is what developers introduced and can fix. Avoid describing the consequences of the weakness here. +- They must be **platform-agnostic** as much as possible. Only mention platform-specific details when it really matters to the introduction of the weakness or when the specific example is especially helpful to illustrate the weakness. + - It is ok to mention the Android Keystore or iOS Keychain as examples of secure storage. + - It is ok to mention Android's `SharedPreferences` or iOS's `UserDefaults` as examples of insecure storage. + - It is not ok to mention Android's `WebView` or iOS's `WKWebView` as examples of web content containers. Mentioning WebView is sufficient. +- Use a short bulleted list where each bullet starts with a **bold short label** followed by a colon and then the explanation. + +For example: + +- `**Hardcoded Keys**: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation and reverse-engineering.` + - This should not contain the consequences (e.g. "making them susceptible to extraction through decompilation and reverse-engineering") — that belongs in the Impact section. Instead, it should describe how the weakness is introduced (e.g. "Including cryptographic keys directly in the application code"). ### `## Impact` -- What an attacker can do, or what the user loses, if the weakness is present. -- Short bulleted list (3-5 bullets). Each bullet starts with a **bold short label** followed by a colon and then the concrete outcome. For example: - `- **Loss of Confidentiality**: Sensitive information can be exposed, resulting in a loss of confidentiality. Once keys are exposed, all data encrypted with those keys is at risk.` -- Avoid vague risk labels. Each outcome should be specific and actionable. -- No CVSS numbers. Severity is context-dependent and cannot be universally assigned to a weakness. Instead, the impact section should provide enough detail for testers and developers to make their own informed severity assessments based on the specific app context. +What attackers can achieve and how they get there is **not** written in this section. It lives in the front matter. + +- The immediate outcome is the `threat:` field, referencing `.github/instructions/threats.yaml`. +- The paths to that outcome are the `attacks:` field, referencing `.github/instructions/attacks.yaml`. + +The `## Impact` section therefore contains **only** the consequences that follow, as a bulleted list. Do not add an opening sentence, do not repeat the threat or the attack paths, and do not add a `This can lead to:` line. + +Use `.github/instructions/impact.yaml` for the canonical consequence labels. Reuse the same language and terms across MASWEs whenever a consequence is equivalent. + +#### Structure + +```md +- **[Canonical Impact Label]**: [Concrete attacker action or consequence], resulting in [specific harm]. +``` + +Each consequence must. + +- Use an exact label from `impact.yaml`. +- Explain what attackers can do after achieving the outcome stated by the weakness's `threat:`. +- Include a `resulting in` clause. +- Be specific to the affected user, app, service, or organization. +- Avoid unsupported, duplicate, or generic consequences. + +#### Example 1 + +For a weakness with `threat: MAS-THREAT-0006` ("Attackers can extract hardcoded secrets, credentials, and internal information.") and `attacks: [MAS-ATTACK-0001]`: + +```md +## Impact + +- **Financial Loss**: Attackers can abuse compromised API keys to make unauthorized billed API calls (e.g., AI/ML services), resulting in unexpected charges to the app owner. +- **Compromise of System Integrity and Business Operations**: Attackers can use extracted credentials to access backend services, resulting in service disruption, policy-violation suspensions, or denial of service. +``` + +#### Example 2 + +For a weakness with `threat: MAS-THREAT-0010` ("Attackers can use the app's cryptographic keys without authorization.") and `attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003, MAS-ATTACK-0027]`: + +```md +## Impact + +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data without ever extracting the key, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can perform signing or authentication operations reserved for the legitimate user, resulting in unauthorized transactions or access to protected functionality. +``` + +### Writing threats and attacks + +New entries in `threats.yaml` and `attacks.yaml` are appended, never renumbered. Keep them reusable and platform-agnostic. + +A threat states _what_ the actor achieves, as a full sentence ending in a period. + +- Attacker-driven weaknesses: `Attackers can [obtain, expose, modify, bypass, or disrupt something].` +- Privacy weaknesses, where the app itself is the actor: `Apps and embedded third-party components can [collect, share, or track something].` + +An attack states _how_ they get there, as a gerund phrase ending in a period. Each attack must. + +- Name a concrete actor action or a precondition the actor needs (installing an app, accessing storage, obtaining the package, running the app in a controlled environment), never restate the outcome already given by the threat. The threat says _what_; the attack says _how_. +- Be an action someone could observe or attempt, not a property of the app. "Leveraging legacy platform behaviors applied to apps targeting outdated platform versions" describes the weakness; "Accessing app data exposed by legacy compatibility behaviors that the platform still applies to apps targeting an old version" describes the attack. +- Reuse the threat's verb only when the attack adds a distinct actor, interface, or precondition. An attack that repeats the threat's verb and its object (threat "Attackers can exploit flaws in non-standard security implementations." with attack "Exploiting flaws in custom or unproven security implementations.") is a restatement and must be rewritten or dropped. ### `## Mitigations` - What developers must do to prevent or reduce the impact of the weakness. +- Mitigations typically correspond to the modes of introduction. Each mitigation should be actionable and specific, providing clear guidance on how to address the weakness. - Short bulleted list. Each bullet starts with a **bold short label** followed by a colon and then an imperative sentence addressed to the developer. For example: `- **Use Platform Keystores**: Where possible, generate cryptographic keys dynamically on the device, rather than using predefined keys, and ensure that they are securely stored after creation.` -- When a mitigation is fully captured by a MASTG-BEST entry, link to it with `@MASTG-BEST-XXXX` and keep the bullet short. Do not duplicate the content of the best practice. -- Do not include testing steps here. diff --git a/.github/instructions/threats.yaml b/.github/instructions/threats.yaml new file mode 100644 index 00000000..c9525f4c --- /dev/null +++ b/.github/instructions/threats.yaml @@ -0,0 +1,78 @@ +MAS-THREAT-0001: Attackers can access sensitive data written to logs. +MAS-THREAT-0002: Attackers can extract or tamper with sensitive data included in backups. +MAS-THREAT-0003: Attackers can access sensitive data stored unencrypted in private storage. +MAS-THREAT-0004: Attackers can access or tamper with sensitive data stored in shared or external storage. +MAS-THREAT-0005: Attackers can extract cryptographic keys stored outside the platform keystore. +MAS-THREAT-0006: Attackers can extract hardcoded secrets, credentials, and internal information. +MAS-THREAT-0007: Attackers can predict or reproduce improperly generated cryptographic keys. +MAS-THREAT-0008: Attackers can predict or reproduce improperly derived cryptographic keys. +MAS-THREAT-0009: Attackers can decrypt or forge all data ever protected with a compromised key. +MAS-THREAT-0010: Attackers can use the app's cryptographic keys without authorization. +MAS-THREAT-0011: Attackers can decrypt or forge improperly encrypted data. +MAS-THREAT-0012: Attackers can forge or replay data that passes hash-based integrity or authenticity checks. +MAS-THREAT-0013: Attackers can forge or replay messages that the app or its backend accepts as authentic. +MAS-THREAT-0014: Attackers can forge signatures or recover signing keys. +MAS-THREAT-0015: Attackers can present forged or tampered data as authentic. +MAS-THREAT-0016: Attackers can predict or reproduce random values used in security contexts. +MAS-THREAT-0017: Attackers can perform sensitive actions in a victim's authenticated session. +MAS-THREAT-0018: Attackers can access sensitive data or resume a session after it should have ended. +MAS-THREAT-0019: Attackers can obtain user approval for actions different from what the user intended. +MAS-THREAT-0020: Attackers can access sensitive data and functionality exposed by app components. +MAS-THREAT-0021: Attackers can bypass local authentication and access protected data or functionality. +MAS-THREAT-0022: Attackers can authenticate sensitive transactions without the user's biometrics. +MAS-THREAT-0023: Attackers can use biometric-protected keys without the legitimate user's biometrics. +MAS-THREAT-0024: Attackers can capture credentials that users handle manually. +MAS-THREAT-0025: Attackers can intercept or modify cleartext network traffic. +MAS-THREAT-0026: Attackers can intercept or modify TLS-protected network traffic. +MAS-THREAT-0027: Attackers can intercept or modify TLS-protected traffic even when standard certificate validation succeeds. +MAS-THREAT-0028: Attackers can capture sensitive data displayed or entered in the user interface. +MAS-THREAT-0029: Attackers can access sensitive data shown in notifications. +MAS-THREAT-0030: Attackers can access sensitive data displayed on the screen. +MAS-THREAT-0031: Attackers can hijack user interactions with the app. +MAS-THREAT-0032: Attackers can hijack deep links or inject malicious input into the app. +MAS-THREAT-0033: Attackers can capture sensitive data placed on the clipboard. +MAS-THREAT-0034: Attackers can capture sensitive user input and content. +MAS-THREAT-0035: Attackers can intercept or manipulate the app's intents. +MAS-THREAT-0036: Attackers can invoke exposed native functionality from web content. +MAS-THREAT-0037: Attackers can access local files and app-private data from web content. +MAS-THREAT-0038: Attackers can execute malicious web content inside the app's WebView. +MAS-THREAT-0039: Attackers can capture sensitive data displayed or entered in the app. +MAS-THREAT-0040: Attackers can exploit vulnerabilities that remain reachable in outdated app versions. +MAS-THREAT-0041: Attackers can exploit publicly known vulnerabilities in the app's dependencies. +MAS-THREAT-0042: Attackers can exploit platform-level weaknesses that the app cannot fix on its own. +MAS-THREAT-0043: Attackers can exploit the absence of modern platform protections. +MAS-THREAT-0044: Attackers can execute arbitrary code within the app's context. +MAS-THREAT-0045: Attackers can exploit memory-corruption bugs with substantially less effort. +MAS-THREAT-0046: Attackers can exploit weaknesses that maintained APIs have already addressed. +MAS-THREAT-0047: Attackers can exploit flaws in non-standard security implementations. +MAS-THREAT-0048: Attackers can execute injection attacks against the app. +MAS-THREAT-0049: Attackers with physical access to the device can read the app's data and use its keys when no device credential protects them.``` +MAS-THREAT-0050: Attackers can inspect and manipulate a debuggable app at runtime, even on non-rooted or non-jailbroken devices. +MAS-THREAT-0051: Attackers can analyze the app's logic and security controls with minimal effort. +MAS-THREAT-0052: Attackers can analyze the app's inner workings through its resources. +MAS-THREAT-0053: Attackers can target the app with malware running on the same device. +MAS-THREAT-0054: Attackers can analyze the app's internals and disable its security controls. +MAS-THREAT-0055: Attackers can inspect and manipulate the app's API payloads. +MAS-THREAT-0056: Attackers can run and manipulate the app in a privileged environment without resistance. +MAS-THREAT-0057: Attackers can observe and manipulate the app from a hosting process. +MAS-THREAT-0058: Attackers can analyze and automate the app in a fully controlled environment. +MAS-THREAT-0059: Attackers can interact with the backend from untrusted environments. +MAS-THREAT-0060: Attackers can inspect and manipulate the running app without resistance. +MAS-THREAT-0061: Attackers can observe and modify the running app without resistance. +MAS-THREAT-0062: Attackers can distribute and run modified copies of the app. +MAS-THREAT-0063: Attackers can alter the app's behavior through its resources. +MAS-THREAT-0064: Attackers can modify the app's code while it runs. +MAS-THREAT-0065: Apps and embedded third-party components, as well as any party that later obtains the collected data, can identify and track users. +MAS-THREAT-0066: Apps and embedded third-party components can track users across apps, devices, and services. +MAS-THREAT-0067: Apps and embedded third-party components can collect, process, or share personal data in ways users cannot anticipate. +MAS-THREAT-0068: Apps and embedded third-party components can collect or share more data than users were led to expect. +MAS-THREAT-0069: Apps and their backend services can retain and process personal data beyond the user's control. +MAS-THREAT-0070: Apps and their users' counterparts can expose personal information beyond the user's intent. +MAS-THREAT-0071: Apps and embedded third-party components can process personal data without valid user consent. +MAS-THREAT-0072: Apps and embedded third-party components can access more sensitive device resources and data than needed. +MAS-THREAT-0073: Apps and embedded third-party components can track users against their expressed preferences. +MAS-THREAT-0074: Apps and embedded third-party components can access more user data than the feature requires. +MAS-THREAT-0075: Attackers can run malicious functionality inside the trusted app. +MAS-THREAT-0076: Attackers can conceal tampering with the app's released binaries. +MAS-THREAT-0077: Apps can lead users to disclose personal data without understanding or controlling the scope of the disclosure. +MAS-THREAT-0078: Apps can disclose more personal data than necessary before users adjust any settings. \ No newline at end of file diff --git a/.github/workflows/config/url-checker-config.json b/.github/workflows/config/url-checker-config.json index 9bea288c..16ae0b36 100644 --- a/.github/workflows/config/url-checker-config.json +++ b/.github/workflows/config/url-checker-config.json @@ -5,8 +5,14 @@ }, { "pattern": "^http://localhost" + }, + { + "comment": "Sites that are live but block automated clients (bot challenge, consent-redirect loop or rate limiting)", + "pattern": "^https://(www\\.)?(statista\\.com|researchgate\\.net|ieeexplore\\.ieee\\.org)" + }, + { + "pattern": "^https://support\\.google\\.com/" } - ], "httpHeaders": [ { diff --git a/weaknesses/MASVS-AUTH/MASWE-0005.md b/weaknesses/MASVS-AUTH/MASWE-0005.md deleted file mode 100644 index 276476d2..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0005.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: API Keys Hardcoded in the App Package -id: MASWE-0005 -alias: api-keys-hardcoded-app-package -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-AUTH-1] - mastg-v1: [] - cwe: [798] - android-risks: - - https://developer.android.com/privacy-and-security/risks/insecure-api-usage -status: new -refs: -- https://cloud.google.com/docs/authentication/api-keys#securing -- https://cloud.google.com/docs/authentication/api-keys#api_key_restrictions ---- - -## Overview - -API keys hardcoded in the app package, source code, or compiled binaries, can be easily extracted through reverse engineering. - -## Impact - -Hardcoding API keys in the app can lead to a variety of security issues, including but not limited to: - -- **Financial Loss**: Attackers can exploit the compromised hardcoded API keys to make unauthorized API calls and abuse services that are billed on a per-use basis (e.g., AI or ML API services), resulting in unexpected charges to the app owner. -- **Compromise of System Integrity and Business Operations**: Extracted API keys can give attackers unauthorized access to sensitive resources and services. This directly impacts developers and enterprises by compromising app integrity, privacy, and service continuity - potentially leading to disruptions such as Denial of Service (DoS) or service suspension due to policy violations. Such incidents can significantly impact the user experience, erode user trust, and negatively impact business reputation and operations. -- **Bypass Protection Mechanism**: Hardcoded API keys can make it easier to bypass app protection mechanisms. Attackers can use this to access restricted content, cheat in app functionality, or unlock features that are intended for purchase, impacting both revenue and user experience. - -## Modes of Introduction - -API keys can be hardcoded in several areas: - -- **App Source Code**: directly embedded in the app source code. -- **App Assets**: included in files that are destined for the final deliverable app package (typically APK/IPA), such as configuration files, manifest files, and resource files. -- **Libraries**: configuration files or source code for third-party, first-party libraries or any other app dependencies. - -## Mitigations - -- Use a stateful API service that provides secure authentication, client validation, and session controls. Implement dynamic tokens that expire after a reasonably short time (e.g., 1 hour). This can help reduce the impact of key exposure. Also, ensure proper error handling and logging to detect and respond to unauthorized access attempts. Consider using OAuth 2.0 and security libraries like AppAuth to simplify secure OAuth flows. -- If a stateful API service is not viable, consider using a stateless API service with a middleware solution (sometimes known as API proxy or API Gateway). This involves proxying requests between the app and API endpoint. Use JSON Web Tokens (JWT) and JSON Web Signature (JWS) to store the vulnerable static key server-side rather than in the application (client). Implement secure key management practices and consider using a cloud key management service. -- If API keys must be hardcoded, be sure to configure them with the minimum required permissions to reduce the impact in case of exposure. Many services allow you to create keys with restricted access, which limits the operations that can be performed. -- Consider using a [Key Management Service](https://cloud.google.com/kms/docs/key-management-service) to get API keys on runtime after validating app integrity. -- Regularly audit the codebase and dependencies for hardcoded sensitive data (e.g. using tools such as [gitLeaks](https://github.com/gitleaks/gitleaks)). -- Use white-box cryptography techniques to encrypt API keys and sensitive data within the app, ensuring that the cryptographic algorithms and keys remain protected even if the app is reverse-engineered. -- While not foolproof, and **to be used as a last resort** when no other secure options are available, code and resource obfuscation and encryption can deter attackers by making it more difficult to analyze your app and discover hardcoded secrets. Avoid custom implementations and use well-established solutions such as RASP (Runtime Application Self-Protection) which can ensure that the API keys are only fully assembled in memory when necessary, keeping them obfuscated or split across different components otherwise. RASP can also dynamically retrieve and manage keys securely at runtime by integrating with secure key management solutions. diff --git a/weaknesses/MASVS-AUTH/MASWE-0017.md b/weaknesses/MASVS-AUTH/MASWE-0017.md new file mode 100644 index 00000000..fdf9b8ec --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0017.md @@ -0,0 +1,55 @@ +--- +title: Step-Up Authentication Not Implemented for Sensitive Actions +id: MASWE-0017 +alias: step-up-auth +requirement: "The app enforces step-up authentication before granting access to sensitive functionality." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0017 +attacks: [MAS-ATTACK-0032, MAS-ATTACK-0033] +mappings: + masvs-v1: [MSTG-AUTH-10] + masvs-v2: [MASVS-AUTH-3, MASVS-PLATFORM-3] + cwe: [306] + android-core-app-quality: [Biometric_Authentication] + maswe-beta: [MASWE-0029] +refs: +- https://developer.apple.com/documentation/localauthentication +- https://auth0.com/blog/what-is-step-up-authentication-when-to-use-it/ +- https://pages.nist.gov/800-63-4/sp800-63b.html +--- + +## Overview + +This weakness occurs when an app allows sensitive actions to be performed within an already authenticated session without requiring the user to re-confirm their identity. + +Step-up authentication requires the user to re-authenticate or provide an additional authentication factor before performing a sensitive action, even within an active session. + +For example, a user logged into their bank account who requests a large transfer to an unknown payee should be required to re-confirm their identity (e.g. via biometrics or a second factor) so that only the legitimate user can complete the action. Without it, whoever holds the active session, not necessarily the legitimate user, can perform every operation the account allows. + +Depending on the context, other sensitive actions may include: + +- Changing account data such as password, email address or phone number +- Elevating a user role +- Disabling security features such as multifactor authentication (MFA) +- Displaying sensitive data such as credit card number / PAN + +## Modes of Introduction + +- **No Re-Authentication for Sensitive Actions**: Allowing high-risk operations, such as payments, credential or profile changes, or the display of sensitive personal data, with only the assurance of the initial login. +- **Step-Up Not Bound to the Action**: Implementing a re-authentication challenge that is not tied to the specific transaction being approved, so a single approval can be reused for a different or modified action. +- **Step-Up Not Enforced Server-Side**: Step-up authentication is only performed by app and not by the server. +- **Uniform Assurance Level**: Designing all functionality behind a single login assurance level without classifying operations by risk. + +## Impact + +- **Financial Loss**: Attackers can initiate transfers or purchases in the victim's session, resulting in direct financial harm to the user. +- **Compromise of Sensitive Data**: Attackers can view or export sensitive personal data available in the session, resulting in unauthorized disclosure of user information. +- **Authentication or Authorization Bypass**: Attackers can change the account's credentials or security settings without any additional challenge, resulting in persistent account takeover. + +## Mitigations + +- **Classify Actions by Risk**: Define which operations require step-up authentication and match the required assurance level to the sensitivity of each action. +- **Require Step-Up for Sensitive Actions**: Re-authenticate the user, e.g. with biometrics bound to a keystore-protected key or an additional factor, before executing high-risk operations or displaying highly sensitive data. +- **Bind the Challenge to the Action**: Tie the step-up challenge cryptographically to the specific transaction (e.g. transaction signing), so an approval cannot be replayed or applied to a different action. +- **Enforce Step-Up Server-Side**: Have the server require and verify step-up evidence before executing the action, rather than trusting a client-side check. diff --git a/weaknesses/MASVS-AUTH/MASWE-0018.md b/weaknesses/MASVS-AUTH/MASWE-0018.md new file mode 100644 index 00000000..5db83588 --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0018.md @@ -0,0 +1,43 @@ +--- +title: Sensitive Data Accessible After Session Termination +id: MASWE-0018 +alias: session-termination +requirement: "The app makes sensitive data inaccessible after session termination." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0018 +attacks: [MAS-ATTACK-0005, MAS-ATTACK-0032, MAS-ATTACK-0033] +mappings: + masvs-v2: [MASVS-AUTH-3] + cwe: [285, 287, 613] + maswe-beta: [MASWE-0030] +refs: +- https://developer.android.com/identity/sign-in/credential-manager-siwg-implementation#handle-sign-out +- https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html +--- + +## Overview + +This weakness occurs when sensitive data or an authenticated session remains accessible after the session should have ended, whether through explicit logout, a timeout, or a contextual state change. + +Session termination is not limited to the user tapping "log out": inactivity timeouts, the app moving to the background, or remarkable changes in the user's context (such as location or profile changes) can all require the session to end or the user to re-authenticate. When the app fails to invalidate the session and clear the associated sensitive data (session tokens, cached personal data, in-memory state, on-screen content), anyone who gains access to the device or the leftover tokens can resume access without authenticating. + +## Modes of Introduction + +- **Sessions Not Invalidated Server-Side**: Terminating sessions only client-side, leaving session tokens valid on the server after logout or timeout. +- **Missing Client-Side Session Termination**: The app provides no way to terminate user sessions (e.g. no logout button or timeout). +- **No Re-Authentication on State Changes**: Resuming the app from the background or continuing after remarkable context changes (e.g. a significant change in the user's location or profile) without invalidating the current session and requiring re-authentication. +- **Cached Data Not Cleared**: Retaining session tokens, cached personal data, in-memory state, or on-screen content after the session ends. +- **Missing Inactivity Timeout**: Allowing sessions to remain valid indefinitely without inactivity or absolute expiration limits. + +## Impact + +- **Authentication or Authorization Bypass**: Attackers can resume the victim's session and act as the user without authenticating, resulting in unauthorized access to the account and its functionality. +- **Compromise of Sensitive Data**: Attackers can read cached or leftover personal data from a terminated session, resulting in unauthorized disclosure of user information. + +## Mitigations + +- **Invalidate Sessions Fully**: Invalidate the session server-side on logout, timeout, and account state changes, following the [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html). +- **Re-Authenticate on Context Changes**: Require re-authentication when the app returns to the foreground after a sensitive flow or when remarkable changes in the user's context (e.g. location or profile) are detected. +- **Clear Sensitive Data on Termination**: Remove session tokens, cached personal data, and in-memory or on-screen sensitive content when the session ends, including disconnecting linked accounts where applicable. +- **Enforce Timeouts**: Apply both inactivity and absolute session timeouts appropriate to the app's risk profile. diff --git a/weaknesses/MASVS-AUTH/MASWE-0019.md b/weaknesses/MASVS-AUTH/MASWE-0019.md new file mode 100644 index 00000000..fa50cf10 --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0019.md @@ -0,0 +1,50 @@ +--- +title: Lack of Non-Repudiation for Critical Actions +id: MASWE-0019 +alias: lack-of-non-repudiation +requirement: "The app ensures non-repudiation for critical actions." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0019 +attacks: [MAS-ATTACK-0036, MAS-ATTACK-0037] +mappings: + masvs-v2: [MASVS-AUTH-3] + cwe: [287, 778] + maswe-beta: [MASWE-0031] +refs: +- https://developer.android.com/training/articles/security-android-protected-confirmation +- https://source.android.com/docs/security/features/protected-confirmation +--- + +## Overview + +This weakness occurs when critical actions, such as confirming a payment or a high-value transaction, can be approved without a trusted confirmation path that produces cryptographic evidence of what the user actually saw and approved. + +For a critical action to be non-repudiable, the user must be shown exactly what they are approving through a trusted, hardware-protected confirmation path, and the app should obtain cryptographic evidence that this specific prompt was confirmed by the user. + +This can be achieved by displaying a prompt and then signing the confirmed message with an attested hardware-backed key. + +Note that it does not provide a secure information channel, so it must not be used to display sensitive information that wouldn't ordinarily be shown on the device. Equivalent trusted-confirmation paths on other platforms need to be evaluated case by case. + + +!!! Warning + + On Android, [Android Protected Confirmation](https://developer.android.com/training/articles/security-android-protected-confirmation) can display the prompt and sign the confirmed message with a hardware-backed key. However, while the API itself is not deprecated, its interface definition is [deprecated](https://android.googlesource.com/platform/system/security/+/07fec0ff). It is therefore not guaranteed that Android Protected Confirmation works properly on current devices. + +Beyond the technical aspect, non-repudiation has a legal dimension: a signed, user-confirmed action carries evidentiary value that a plain in-app confirmation does not, which matters when transactions are later disputed. + +## Modes of Introduction + +- **No Trusted Confirmation Path**: Confirming critical actions through the regular app UI, which a compromised OS or a tampered app can render differently from what is actually executed. +- **No Cryptographic Evidence of Approval**: Completing critical actions without obtaining a hardware-backed signature that binds the displayed message to the user's approval, leaving the app owner unable to prove what was approved. + +## Impact + +- **Financial Loss**: Attackers can trick users into approving altered payments or transactions, resulting in funds being transferred to attacker-controlled destinations. +- **Compromise of System Integrity and Business Operations**: Users can plausibly repudiate transactions when the app owner holds no cryptographic proof of what was approved, resulting in disputes, chargebacks, and legal exposure for the app owner. + +## Mitigations + +- **Bind Cryptographic Evidence to the Action**: Have the confirmation produce a hardware-backed signature over the exact message shown to the user, verify it server-side, and retain it as evidence of the approval. +- **Do Not Display Secrets in the Prompt**: Keep sensitive information out of the trusted confirmation message; it guarantees integrity of the confirmation, not confidentiality of its contents. +- **Use the Strongest Available Alternative**: Where no trusted-UI mechanism exists, bind transaction approval to a user-authenticated, hardware-backed signing key (e.g. biometric-bound transaction signing) as the closest available equivalent. Verify the key attestation certificate of the signing key on the server-side. diff --git a/weaknesses/MASVS-AUTH/MASWE-0020.md b/weaknesses/MASVS-AUTH/MASWE-0020.md new file mode 100644 index 00000000..94ce0f03 --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0020.md @@ -0,0 +1,61 @@ +--- +title: Lack of Authentication or Authorization on App Components +id: MASWE-0020 +alias: missing-auth-app-components +requirement: "The app enforces authentication and authorization on its components." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0020 +attacks: [MAS-ATTACK-0038, MAS-ATTACK-0039] +mappings: + masvs-v1: [MSTG-PLATFORM-4, MSTG-AUTH-3, MSTG-NETWORK-2, MSTG-STORAGE-6] + masvs-v2: [MASVS-AUTH-1, MASVS-PLATFORM-1, MASVS-STORAGE-2] + cwe: [306, 749, 862, 863, 923, 926, 939, 940] + android-risks: + - content-resolver + - insecure-broadcast-receiver + - access-control-to-exported-components + - android-exported + - custom-permissions + android-core-app-quality: [Component_Export, Component_Permissions, Component_Protection] + maswe-beta: [MASWE-0033, MASWE-0038, MASWE-0040, MASWE-0051, MASWE-0059, MASWE-0062, MASWE-0063, MASWE-0064, MASWE-0065, MASWE-0119] +refs: +- https://developer.android.com/privacy-and-security/security-tips#IPNetworking +- https://developer.android.com/privacy-and-security/security-tips#Services +- https://developer.android.com/privacy-and-security/security-tips#BroadcastReceivers +- https://developer.android.com/privacy-and-security/security-tips#ContentProviders +- https://developer.android.com/privacy-and-security/security-tips#binder-and-messenger-interfaces +- https://developer.android.com/topic/security/risks/content-resolver +- https://developer.android.com/topic/security/risks/file-providers +--- + +## Overview + +This weakness occurs when app components that expose functionality or data do not enforce proper authentication or authorization on their callers. + +It covers any component reachable by other apps or processes without adequate access control, including services, broadcast receivers, activities, and content providers, as well as local web services or open ports exposed by the app. It also covers the handling of authentication material on such surfaces, for example authentication tokens accepted without validation or authentication flows handled insecurely inside WebViews. + +## Modes of Introduction + +- **Unintentionally Exported Components**: Exporting services, broadcast receivers, activities, or content providers through defaults or misconfiguration when they are only meant for internal use. +- **Missing or Weak Permissions on Exported Components**: Exporting components without permission requirements, with weak protection levels, or with misconfigured custom permissions. +- **Caller Not Verified on IPC Interfaces**: Exposing Binder or Messenger interfaces that do not verify the caller's identity or permissions (e.g. not calling `checkCallingPermission()`). +- **Over-Broad Data Grants**: Using sticky broadcasts, over-broad or persistable URI permission grants, or persistent data sharing where one-time, scoped sharing would suffice. +- **Unprotected Local Network Services**: Binding a local web service or open port that accepts connections without authentication. +- **Authentication Material Not Validated**: Accepting authentication tokens without proper validation (e.g. missing signature or claim checks, no PKCE in OAuth flows) or handling authentication inside WebViews instead of secure system flows. +- **Missing Authentication or Authorization on Deep Links**: App-defined URI scheme, Android App Link, or iOS Universal Link triggers a sensitive action (e.g., password reset, fund transfer, account linking) without verifying that the request came from an authenticated or authorized source. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can query unprotected content providers or receive broadcast data, resulting in unauthorized disclosure of user or app data to other apps on the device. +- **Authentication or Authorization Bypass**: Attackers can invoke privileged functionality, such as internal services or unvalidated token flows, without authenticating, resulting in actions being executed on behalf of the user. +- **Bypass of Protection Mechanisms**: Attackers can launch internal activities directly, resulting in the circumvention of intended flows such as authentication screens or paywalls. + +## Mitigations + +- **Do Not Export Components Unnecessarily**: Explicitly mark internal components as not exported and keep the exposed surface minimal. +- **Protect Exported Components with Permissions**: Guard intentionally exported components with permissions of an appropriate protection level (e.g. signature-level for same-developer apps) and define custom permissions correctly. +- **Verify Callers on IPC Interfaces**: Check the caller's identity or permissions on Binder and Messenger interfaces before performing sensitive operations or returning data. +- **Grant Minimal, Short-Lived Data Access**: Prefer one-time, narrowly scoped URI grants over persistable ones, avoid sticky broadcasts, and restrict content provider paths to exactly what must be shared. +- **Authenticate Local Services**: Avoid opening local ports where possible; if required, authenticate every connection and bind only to the local interface. +- **Validate Authentication Material**: Validate tokens server-side (signature, issuer, audience, expiry), use PKCE for OAuth flows, and use system-provided authentication sessions instead of handling credentials inside WebViews. diff --git a/weaknesses/MASVS-AUTH/MASWE-0021.md b/weaknesses/MASVS-AUTH/MASWE-0021.md new file mode 100644 index 00000000..a0a4935a --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0021.md @@ -0,0 +1,52 @@ +--- +title: Local Authentication Can Be Bypassed +id: MASWE-0021 +alias: event-bound-biometric-auth +requirement: "The app implements local authentication securely." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0021 +attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003, MAS-ATTACK-0027, MAS-ATTACK-0040] +mappings: + masvs-v1: [MSTG-AUTH-8, MSTG-AUTH-1, MSTG-AUTH-12] + masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] + cwe: [285, 287, 312, 319, 326, 602, 603, 863, 922] + android-core-app-quality: [Biometric_Authentication] + maswe-beta: [MASWE-0034, MASWE-0044, MASWE-0041, MASWE-0042, MASWE-0043] +refs: +- https://developer.android.com/training/sign-in/biometric-auth#crypto +- https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication +- https://developer.apple.com/documentation/localauthentication/accessing_keychain_items_with_face_id_or_touch_id +- https://github.com/sensepost/objection/issues/136#issuecomment-419664574 +- https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass +- https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/applicationpassword +--- + +## Overview + +This weakness occurs when local authentication, such as biometrics, device credentials, or a custom app PIN, can be bypassed because it is implemented as an event-bound check rather than being cryptographically tied to a protected resource. + +Local authentication is only as strong as what it unlocks. When the app merely reacts to a "success" callback, an attacker who controls the app's execution can invoke the protected logic directly, without ever passing the check. To be effective, local authentication must require a cryptographic operation, such as decrypting a secret or signing a payload, using a key locked inside secure hardware like a Trusted Execution Environment or Secure Enclave. Because the hardware itself enforces user authentication before executing the operation, an attacker spoofing a successful callback cannot produce the required cryptographic proof or unencrypted data. For connected apps, authentication and authorization decisions that are enforced only locally, rather than on the server side, are similarly bypassable by tampering with the client. + +## Modes of Introduction + +- **Event-Bound Biometric Checks**: Acting on the biometric prompt's success result alone, without binding the protected operation to a keystore key that requires authentication (e.g. no `CryptoObject`). +- **Weak Keychain Access Control Flags**: Protecting Keychain items with flags that do not enforce the intended factor (e.g. `kSecAccessControlTouchIDAny` without additional constraints) or storing "protected" data retrievable without authentication. +- **Insecure Device-Credential Fallback**: Implementing Confirm Credentials or similar flows with long authentication validity durations or without binding them to keystore keys. +- **Local-Only Enforcement**: Enforcing authentication or authorization decisions solely in client code for apps that have a backend, instead of validating them server-side. +- **No Brute-Force Resistance**: Allowing unlimited attempts against a custom PIN or password because the app does not track failures. +- **Custom Credentials Hardcoded**: Implementing a custom app PIN or password as a plain comparison in code. + +## Impact + +- **Authentication or Authorization Bypass**: Attackers can trigger the protected functionality without valid biometrics or credentials, resulting in unauthorized access to the user's account and sensitive operations. +- **Compromise of Sensitive Data**: Attackers can retrieve data that was supposed to be gated by local authentication, resulting in unauthorized disclosure of sensitive user information. + +## Mitigations + +- **Bind Authentication to Keystore Keys**: Protect sensitive actions by requiring a cryptographic operation (such as decryption or signing) using keys stored in the platform keystore. Use mechanisms like `CryptoObject` on Android or Keychain access control on iOS (such as `.biometryCurrentSet`) so attackers cannot bypass authentication by hooking software callbacks. +- **Use Strict Access Control Flags**: Choose Keychain and keystore parameters that enforce the intended factor and invalidate on enrollment changes (see @MASWE-0023), avoiding weak flags and long authentication validity windows. +- **Enforce Authentication Server-Side**: For connected apps, gate server resources on server-verified evidence of authentication (e.g. a signed challenge produced with an authentication-bound key), never on a client-side boolean. +- **Bind Custom Credentials to the KeyChain**: For defining a custom PIN or password as an authentication factor, bind it to key material by using `applicationPassword` rather than comparing it in app code. +- **Require Explicit User Action**: For passive modalities such as face recognition, require explicit confirmation of the authentication prompt before proceeding with sensitive operations. +- **Resist Credential Guessing**: Keep each attempt dependent on hardware-backed key material so guesses cannot be parallelized off-device, and combine app-defined credentials with a biometric or device-credential constraint so every attempt also requires an OS-throttled factor. diff --git a/weaknesses/MASVS-AUTH/MASWE-0022.md b/weaknesses/MASVS-AUTH/MASWE-0022.md new file mode 100644 index 00000000..6466f9f2 --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0022.md @@ -0,0 +1,42 @@ +--- +title: Fallback to Non-biometric Credentials Allowed for Sensitive Transactions +id: MASWE-0022 +alias: no-biometric-fallback +requirement: "The app does not allow fallback to non-biometric credentials for sensitive transactions." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0022 +attacks: [MAS-ATTACK-0034] +mappings: + masvs-v2: [MASVS-AUTH-2] + cwe: [288, 287] + android-core-app-quality: [Biometric_Authentication] + maswe-beta: [MASWE-0045] +refs: +- https://developer.android.com/training/sign-in/biometric-auth#allow-fallback +- https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id#3148834 +- https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthenticationwithbiometrics/ +--- + +## Overview + +This weakness occurs when authentication for a sensitive transaction can silently fall back from biometrics to a weaker device credential such as a PIN, pattern, or password. + +Device credentials are typically short, reusable, and observable, so allowing them as a fallback drops the assurance level below what a high-value operation requires. On Android, this happens when `DEVICE_CREDENTIAL` is permitted as an authenticator (e.g. via `BiometricPrompt.setAllowedAuthenticators`) for a sensitive action; on iOS, when `LAPolicy.deviceOwnerAuthentication` is used instead of `LAPolicy.deviceOwnerAuthenticationWithBiometrics`. Sensitive transactions should require biometrics and be bound to a biometric-protected key rather than permitting a non-biometric fallback. + +## Modes of Introduction + +- **Device Credential Allowed for Sensitive Actions**: Permitting `DEVICE_CREDENTIAL` as an accepted authenticator for high-value operations on Android. +- **Generic Authentication Policy on iOS**: Using `LAPolicy.deviceOwnerAuthentication`, which allows passcode fallback, instead of `LAPolicy.deviceOwnerAuthenticationWithBiometrics` for sensitive operations. +- **Operation Not Bound to a Biometric-Only Key**: Protecting the sensitive operation with a UI-level prompt rather than a keystore key that only unlocks with strong biometric authentication. + +## Impact + +- **Authentication or Authorization Bypass**: Attackers can complete authentication challenges intended to require the user's biometrics, resulting in unauthorized approval of sensitive operations. +- **Financial Loss**: Attackers can authorize payments or transfers with a stolen device and its credential, resulting in direct financial harm to the user. + +## Mitigations + +- **Require Biometrics for Sensitive Transactions**: Configure the authentication prompt to accept only strong biometrics (e.g. `BIOMETRIC_STRONG` on Android, `LAPolicy.deviceOwnerAuthenticationWithBiometrics` on iOS) for high-value operations. +- **Bind Operations to Biometric-Only Keys**: Protect the operation with a keystore key that requires strong biometric authentication for use and is invalidated on new biometric enrollments (see @MASWE-0023). +- **Match Assurance to Sensitivity**: Allow device-credential fallback only for low-risk convenience features, never for the transactions that motivated biometric protection in the first place. diff --git a/weaknesses/MASVS-AUTH/MASWE-0023.md b/weaknesses/MASVS-AUTH/MASWE-0023.md new file mode 100644 index 00000000..863c97c3 --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0023.md @@ -0,0 +1,40 @@ +--- +title: Crypto Keys Not Invalidated on New Biometric Enrollment +id: MASWE-0023 +alias: crypto-keys-biometric-enrollment +requirement: "The app invalidates keys after any enrollment of new biometric data." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0023 +attacks: [MAS-ATTACK-0035] +mappings: + masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] + cwe: [287, 522] + maswe-beta: [MASWE-0046] +refs: +- https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setInvalidatedByBiometricEnrollment(boolean) +- https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/biometrycurrentset +--- + +## Overview + +This weakness occurs when cryptographic keys gated by biometric authentication remain valid after the set of enrolled biometrics changes. + +Biometric-bound keys are meant to be usable only by the person whose biometrics were enrolled when the key was created. If keys stay valid across enrollments, anyone who can add a new fingerprint or face to the device can unlock them. On Android, invalidation on new enrollment is enabled by default but can be disabled with `setInvalidatedByBiometricEnrollment(false)`; on iOS, it must be explicitly enabled by creating the access control with `SecAccessControlCreateFlags.biometryCurrentSet` (formerly `touchIDCurrentSet`), which invalidates the Keychain item when a biometric is added or removed. + +## Modes of Introduction + +- **Invalidation Disabled on Android**: Creating keys with `setInvalidatedByBiometricEnrollment(false)`, keeping them usable after new biometrics are enrolled. +- **Invalidation Not Enabled on iOS**: Protecting Keychain items without `biometryCurrentSet`, so items remain accessible with any enrolled biometric, including ones added later. +- **Unsafe Invalidation Recovery**: Silently re-creating an invalidated key or falling back to weaker authentication when invalidation occurs, instead of re-verifying the user's identity first. + +## Impact + +- **Authentication or Authorization Bypass**: Attackers can pass biometric prompts with their own newly enrolled biometrics, resulting in unauthorized approval of operations bound to the victim's identity. +- **Compromise of Sensitive Data**: Attackers can unlock data protected by biometric-bound keys, resulting in unauthorized disclosure of sensitive user information. + +## Mitigations + +- **Keep Enrollment Invalidation Enabled on Android**: Do not call `setInvalidatedByBiometricEnrollment(false)` for keys protecting sensitive data or operations. +- **Enable Enrollment Invalidation on iOS**: Create Keychain access controls with `SecAccessControlCreateFlags.biometryCurrentSet` so items are invalidated when the enrolled biometric set changes. +- **Handle Invalidation Safely**: When a key has been invalidated, require full re-authentication of the user (e.g. account credentials or a server-verified flow) before re-creating the key, and never silently fall back to weaker protection. diff --git a/weaknesses/MASVS-AUTH/MASWE-0024.md b/weaknesses/MASVS-AUTH/MASWE-0024.md new file mode 100644 index 00000000..cc1bc14e --- /dev/null +++ b/weaknesses/MASVS-AUTH/MASWE-0024.md @@ -0,0 +1,49 @@ +--- +title: Lack of Auto-fill Support for Credential Providers +id: MASWE-0024 +alias: autofill-authenticators +requirement: "The app enables auto-fill support for credential providers." + +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0024 +attacks: [MAS-ATTACK-0041, MAS-ATTACK-0042] +mappings: + masvs-v1: [MSTG-AUTH-9] + masvs-v2: [MASVS-AUTH-1, MASVS-AUTH-3] + cwe: [287, 522] + android-core-app-quality: [Autofill_Hints, Credential_Manager] + maswe-beta: [MASWE-0028, MASWE-0032, MASWE-0035, MASWE-0039] +refs: +- https://developer.apple.com/documentation/security/password_autofill +- https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession +- https://developer.android.com/guide/topics/text/autofill +- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys +--- + +## Overview + +This weakness occurs when an app does not support the platform's auto-fill and credential-management mechanisms, pushing users toward insecure workarounds such as copying and pasting credentials between apps. + +Platforms provide secure flows for supplying credentials, one-time codes, and passkeys: credential and one-time-code auto-fill, Password AutoFill tied to the app's associated domain, system authentication sessions for third-party services, passwordless authentication with passkeys and WebAuthn, and shared web credentials between an app and its website counterpart. When an app ignores these mechanisms, users end up typing or copying secrets manually, weakening both their credentials and the trust boundary they cross. + +## Modes of Introduction + +- **No Auto-Fill Support in Credential Fields**: Building login fields that are not recognized by or are incompatible with the platform's auto-fill framework and password managers. +- **No One-Time-Code Auto-Fill**: Requiring users to manually read and copy one-time codes (e.g. from SMS) instead of supporting the platform's code auto-fill. +- **Missing Website Association**: Not associating the app with its domain, preventing frictionless secure credential sharing between the app and its website counterpart. +- **Embedded Custom Login Instead of System Flows**: Handling custom authentication, such as using third-party logins in embedded views, instead of system-provided authentication sessions (e.g. `ASWebAuthenticationSession`). +- **No Support for Passwordless Authentication**: Not offering passkeys or other multi-device FIDO/WebAuthn credentials where they could replace passwords. + +## Impact + +- **Authentication or Authorization Bypass**: Attackers can reuse captured credentials or one-time codes, resulting in account takeover and unauthorized access to the user's data and functionality. +- **Compromise of Sensitive Data**: Attackers can read credentials exposed through clipboard-based workarounds, resulting in disclosure of authentication material that protects sensitive information. + +## Mitigations + +- **Support Platform Auto-Fill**: Annotate credential fields so the platform's auto-fill framework and password managers can fill them securely (e.g. autofill hints on Android, `textContentType` on iOS). +- **Support One-Time-Code Auto-Fill**: Use the platform mechanisms that deliver one-time codes directly into the app, removing the need for manual copying. +- **Associate the App with Its Domain**: Configure website association (e.g. iOS Password AutoFill with associated domains, shared web credentials) so credentials flow securely between the app and its website. +- **Use System Authentication Sessions for Third-Party Logins**: Authenticate against third-party services with system flows such as `ASWebAuthenticationSession` instead of embedded views. +- **Support Passkeys**: Offer passkeys or other WebAuthn-based passwordless authentication to remove shared secrets from the login flow entirely. diff --git a/weaknesses/MASVS-AUTH/MASWE-0028.md b/weaknesses/MASVS-AUTH/MASWE-0028.md deleted file mode 100644 index 9f4a9d4a..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0028.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: MFA Implementation Best Practices Not Followed -id: MASWE-0028 -alias: mfa-best-practices -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-AUTH-9] - masvs-v2: [MASVS-AUTH-3] - cwe: [287] - -draft: - description: e.g. not using auto-fill - topics: - - platform auto-fill from SMS - - use of Sign-in with Apple - - MFA best practices - - (IEEE) unreliable channels such as voice mails and phone numbers must be avoided - - is not enforced only locally but server-side - - check if relies on static responses from the remote endpoint such as `"message":"Success"` -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0029.md b/weaknesses/MASVS-AUTH/MASWE-0029.md deleted file mode 100644 index 6b8ca4f6..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0029.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Step-Up Authentication Not Implemented After Login -id: MASWE-0029 -alias: step-up-auth -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-AUTH-10] - masvs-v2: [MASVS-AUTH-3, MASVS-PLATFORM-3] - cwe: [306] - -refs: -- https://developer.apple.com/documentation/localauthentication -- https://auth0.com/blog/what-is-step-up-authentication-when-to-use-it/ -- https://tdcolvin.medium.com/is-firebase-auth-secure-dace0563d41b -- https://github.com/WICG/trust-token-api -- https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/ -draft: - description: An example of step-up authentication is when a user is logged into - their bank account (with or without MFA) and requests an action that is considered - sensitive, such as the transfer of a large sum of money. In such cases, the user - will be required to provide additional information to authenticate their identity - (e.g. using MFA) and ensure only the legitimate user is requesting the action. - topics: - - (ioXt) UP107 App shall re-authenticate the user when displaying sensitive PII - data or conducting sensitive transactions. - - null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0030.md b/weaknesses/MASVS-AUTH/MASWE-0030.md deleted file mode 100644 index 93503f06..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0030.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Re-Authenticates Not Triggered On Contextual State Changes -id: MASWE-0030 -alias: reauth-state-changes -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-3] - cwe: [285, 287] - -refs: -- https://developers.google.com/identity/sign-in/android/disconnect -draft: - description: Re-authentication means forcing a new login after e.g. timeout, changing - state from running in the background to running in the foreground, remarkable - changes in a user's location, profile, etc. - topics: - - timeout - - changing state from running in the background to running in the foreground - - (IEEE) remarkable changes in a user's location - - ASVS V3.3 Session Logout and Timeout Requirements - - NIST 800-63 - - etc. -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0031.md b/weaknesses/MASVS-AUTH/MASWE-0031.md deleted file mode 100644 index be99d6d8..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0031.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Insecure use of Android Protected Confirmation -id: MASWE-0031 -alias: insecure-android-confirmation -platform: [android] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-3] - cwe: [287] - -draft: - description: Android Protected Confirmation doesn't provide a secure information - channel for the user. Don't use it to display sensitive information that you wouldn't - ordinarily show on the user's device. - topics: - - Android Protected Confirmation -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0032.md b/weaknesses/MASVS-AUTH/MASWE-0032.md deleted file mode 100644 index 3f1db134..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0032.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Platform-provided Authentication APIs Not Used -id: MASWE-0032 -alias: platform-auth-apis -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-CODE-3] - cwe: [287] - -refs: -- https://developer.android.com/privacy-and-security/security-tips#Credentials -- https://developer.apple.com/documentation/security/password_autofill -- https://developer.apple.com/videos/play/wwdc2017/206 -- https://developer.android.com/guide/topics/text/autofill-optimize -draft: - description: AKA don't roll your own authentication security. Platform-provided - APIs are designed and implemented by experts who have deep knowledge of the platform's - security features and considerations. These APIs often incorporate security best - practices and are regularly updated to address new threats and vulnerabilities. - Not using platform-provided authentication APIs in mobile apps can result in security - vulnerabilities, inconsistent user experience, missed integration opportunities, - and increased development and maintenance efforts. - topics: - - credential auto-fill to avoid copy/paste - - correct use of Android AccountManager (e.g. invoke a cloud-based service and don't - store passwords on the device). AccountManager data stored in clear in some Android - versions. - - use of CREATOR afterretrieving an account with AccountManager - - use of Authentication Services framework on iOS - - iOS Password AutoFill streamlines logging into web services at your domain. However, - if you need to log into a third-party service, use ASWebAuthenticationSession - instead -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0033.md b/weaknesses/MASVS-AUTH/MASWE-0033.md deleted file mode 100644 index 79f95304..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0033.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Authentication or Authorization Protocol Security Best Practices Not Followed -id: MASWE-0033 -alias: auth-protocol-best-practices -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-1] - cwe: [285, 287] - -refs: -- https://mobidev.biz/blog/single-sign-on-sso-implementation-benefits-enterprise -- https://developers.google.com/identity/protocols/risc -- https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/3237231-prefersephemeralwebbrowsersessio?language=objc -- https://developer.apple.com/videos/play/tech-talks/301 -- https://developers.google.com/identity/protocols/oauth2 -draft: - description: For example, when using oauth2, the app does not use PKCE, etc. See - RFC-8252. Focus on client-side best practices. - topics: - - best practices from RFC-8252 - - SSO -> OpenID Connect (OIDC) - - use of Google Service Accounts - - use of RISC - - use of Apple Redirect extensions for Enterprise - - using use SFAuthenticationSession (deprecated) instead of ASWebAuthenticationSession - - secure mutual authentication using X.509v3 certificates - - use of context to add security to authentication e.g. via IP or location data - - set prefersEphemeralWebBrowserSession to true before calling start for a session - on iOS -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0034.md b/weaknesses/MASVS-AUTH/MASWE-0034.md deleted file mode 100644 index c1cc7376..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0034.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Insecure Implementation of Confirm Credentials -id: MASWE-0034 -alias: insecure-confirm-credentials -platform: [android] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-2] - cwe: [287, 319] - -status: deprecated -covered_by: [MASWE-0044] -deprecation_note: Content overlap. Confirm Credentials is a form of local authentication that will have a dedicated MASTG test. ---- diff --git a/weaknesses/MASVS-AUTH/MASWE-0035.md b/weaknesses/MASVS-AUTH/MASWE-0035.md deleted file mode 100644 index 9057036f..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0035.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Passwordless Authentication Not Implemented -id: MASWE-0035 -alias: no-passwordless-auth -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-STORAGE-1] - cwe: [287] - -refs: -- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication -- https://www.w3.org/TR/webauthn-2/ -- https://fidoalliance.org/white-paper-multi-device-fido-credentials/ -- https://developers.google.com/identity/fido -- https://developers.google.com/identity/fido#what_are_passkeys -- https://fidoalliance.org/developers/ -- https://fidoalliance.org/product-category/android-client/ -- https://fidoalliance.org/product-category/ios-client/ -- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys -- https://techcommunity.microsoft.com/t5/azure-active-directory-identity/expansion-of-fido-standard-and-new-updates-for-microsoft/ba-p/3290633 -- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_security_key_authentication_using_physical_keys -- https://developer.apple.com/videos/play/wwdc2021/10106/ -draft: - description: there's no use of passwordless authentication mechanisms e.g. passkeys - topics: - - passkeys or multi-device FIDO credentials - - WebAuthn/ASAuthorization - - use of Physical Security Keys which stored the public-private key pair on a physical - medium, such as a security card or a USB key -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0036.md b/weaknesses/MASVS-AUTH/MASWE-0036.md deleted file mode 100644 index cddcb489..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0036.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Authentication Material Stored Unencrypted on the Device -id: MASWE-0036 -alias: auth-material-unencrypted -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-STORAGE-1] - cwe: [312] - -refs: -- https://developers.google.com/identity/blockstore/android?hl=en -- https://cloud.google.com/docs/authentication/best-practices-applications#semi-trusted_or_restricted_environments -- https://cloud.google.com/docs/authentication/best-practices-applications#security_considerations -- https://developer.apple.com/documentation/signinwithapplerestapi -draft: - description: General authentication material management best practices. Note that API keys are covered separately. - topics: - - session IDs - - tokens - - passwords - - use of sign-in with Apple/Google -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0037.md b/weaknesses/MASVS-AUTH/MASWE-0037.md deleted file mode 100644 index 31202cff..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0037.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Authentication Material Sent over Insecure Connections -id: MASWE-0037 -alias: auth-material-over-insecure-connections -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-NETWORK-1] - cwe: [319] - -draft: - description: General authentication best practice. - topics: - - session IDs - - tokens - - passwords - - API keys -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0038.md b/weaknesses/MASVS-AUTH/MASWE-0038.md deleted file mode 100644 index 5778437a..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0038.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Authentication Tokens Not Validated -id: MASWE-0038 -alias: unvalidated-auth-tokens -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-AUTH-3] - masvs-v2: [MASVS-AUTH-1, MASVS-CODE-4] - cwe: [287] - -refs: -- https://developers.google.com/identity/sign-in/android/backend-auth#verify-the-integrity-of-the-id-token -- https://developers.google.com/identity/protocols/oauth2/openid-connect#validatinganidtoken -- https://developer.apple.com/documentation/sign_in_with_apple/generate_and_validate_tokens -draft: - description: e.g. oauth2/jwt client-side checks - topics: - - code grant - - expiration - - none algorithm - - PKCE - - implicit grant -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0039.md b/weaknesses/MASVS-AUTH/MASWE-0039.md deleted file mode 100644 index fef285dd..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0039.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Shared Web Credentials and Website-association Not Implemented -id: MASWE-0039 -alias: no-shared-web-credentials -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-PLATFORM-1] - cwe: [287] - -refs: -- https://developer.apple.com/documentation/security/shared_web_credentials -draft: - description: Best practice for sharing credentials between apps and their website - counterparts. - topics: - - Website-association - - Shared Web Credentials -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0040.md b/weaknesses/MASVS-AUTH/MASWE-0040.md deleted file mode 100644 index ba9ab8a1..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0040.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Insecure Authentication in WebViews -id: MASWE-0040 -alias: insecure-webview-auth -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-AUTH-1, MASVS-PLATFORM-2] - cwe: [287] - -refs: - - https://developer.android.com/reference/android/webkit/WebView#getHttpAuthUsernamePassword(java.lang.String,%20java.lang.String) - - https://developer.android.com/reference/android/webkit/WebViewClient#onReceivedHttpAuthRequest(android.webkit.WebView,%20android.webkit.HttpAuthHandler,%20java.lang.String,%20java.lang.String) -draft: - description: e.g. via WebView.getHttpAuthUsernamePassword / WebViewClient.onReceivedHttpAuthRequest - topics: - - Using WebView.getHttpAuthUsernamePassword / WebViewClient.onReceivedHttpAuthRequest -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0041.md b/weaknesses/MASVS-AUTH/MASWE-0041.md deleted file mode 100644 index 2f45b7ab..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0041.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Authentication Enforced Only Locally Instead of on the Server-side -id: MASWE-0041 -alias: local-auth-enforcement -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-AUTH-1] - masvs-v2: [MASVS-AUTH-2] - cwe: [603, 287] - -draft: - description: General authentication best practice. Only for apps with connection. - The app performs local authentication involving the remote endpoint and according - to the platform best practices. - topics: - - (IEEE) Since client-side security controls are capable of being invaded, authentication - and authorization controls should be implemented on the server-side. - - biometry only used as part of MFA authentication and not as the only auth method -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0042.md b/weaknesses/MASVS-AUTH/MASWE-0042.md deleted file mode 100644 index 51f254e3..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0042.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Authorization Enforced Only Locally Instead of on the Server-side -id: MASWE-0042 -alias: local-authz-enforcement -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-AUTH-12] - masvs-v2: [MASVS-AUTH-2] - cwe: [285, 602, 863] - -refs: -- https://developers.google.com/identity/smartlock-passwords/android/associate-apps-and-sites -draft: - description: General authentication best practice. Only for apps with connection. - topics: - - Authorization Enforced Locally - - use of oauth - - use of SharedWebcredentials - - use of WebAuthn/ASAuthorization -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0043.md b/weaknesses/MASVS-AUTH/MASWE-0043.md deleted file mode 100644 index 86cd3ff5..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0043.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: App Custom PIN Not Bound to Platform KeyStore -id: MASWE-0043 -alias: custom-pin-keystore -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] - cwe: [922, 326, 312] - -draft: - description: It's better to use the OS Local Auth / bind to a key stored in the platform KeyStore. Consider new title App Custom Password Not Bound to Platform KeyStore where password could be password or PIN. - topics: - - use the OS Local Auth - - binding to keys stored in the platform KeyStore - - https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/applicationpassword -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0044.md b/weaknesses/MASVS-AUTH/MASWE-0044.md deleted file mode 100644 index 06f55b12..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0044.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Biometric Authentication Can Be Bypassed -id: MASWE-0044 -alias: event-bound-biometric-auth -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-AUTH-8] - masvs-v2: [MASVS-AUTH-2] - cwe: [287] - -refs: -- https://developer.android.com/training/sign-in/biometric-auth#crypto -- https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication -- https://developer.apple.com/documentation/localauthentication/accessing_keychain_items_with_face_id_or_touch_id -- https://github.com/sensepost/objection/issues/136#issuecomment-419664574 -- https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass -draft: - description: It should be based on unlock platform KeyStore / crypto, use CryptoObject - topics: - - no use of CryptoObject - - keychain items protected with access control flags such as kSecAccessControlTouchIDAny - or kSecAccessControlTouchIDCurrentSet -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0045.md b/weaknesses/MASVS-AUTH/MASWE-0045.md deleted file mode 100644 index e7cf9772..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0045.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Fallback to Non-biometric Credentials Allowed for Sensitive Transactions -id: MASWE-0045 -alias: no-biometric-fallback -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-2] - cwe: [288, 287] - -refs: -- https://developer.android.com/training/sign-in/biometric-auth#allow-fallback -- https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id#3148834 -- https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthenticationwithbiometrics/ -draft: - description: e.g. via DEVICE_CREDENTIAL on Android and LAPolicy.deviceOwnerAuthentication - on iOS - topics: - - DEVICE_CREDENTIAL on Android - - LAPolicy.deviceOwnerAuthentication on iOS -status: placeholder - ---- - diff --git a/weaknesses/MASVS-AUTH/MASWE-0046.md b/weaknesses/MASVS-AUTH/MASWE-0046.md deleted file mode 100644 index 7822f9c0..00000000 --- a/weaknesses/MASVS-AUTH/MASWE-0046.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Crypto Keys Not Invalidated on New Biometric Enrollment -id: MASWE-0046 -alias: crypto-keys-biometric-enrollment -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-AUTH-2, MASVS-CRYPTO-2] - cwe: [287, 522] - -draft: - description: Biometric related crypto keys should be is invalidated by default whenever - new biometric enrollments are added. - topics: - - Enabled by default on Android but can be disabled by calling `setInvalidatedByBiometricEnrollment(false)` - - Disabled by default on iOS but can be enabled using `SecAccessControlCreateFlags.biometryCurrentSet` - (prev. `touchIDCurrentSet`) when setting access control (since iOS 9). This invalidates - keychain items when a fingerprint is added or removed. See kSecAccessControlTouchIDCurrentSet, - biometryCurrentSet. -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0040.md b/weaknesses/MASVS-CODE/MASWE-0040.md new file mode 100644 index 00000000..9890ebbc --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0040.md @@ -0,0 +1,41 @@ +--- +title: Enforced Updating Not Implemented +id: MASWE-0040 +alias: enforced-updating +requirement: "The app detects if it must be updated and reacts appropriately." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0040 +attacks: [MAS-ATTACK-0040, MAS-ATTACK-0053] +mappings: + masvs-v1: [MSTG-ARCH-9] + masvs-v2: [MASVS-CODE-2] + cwe: [602, 693] + maswe-beta: [MASWE-0075] +refs: +- https://developer.android.com/guide/playcore/in-app-updates +- https://developer.android.com/reference/com/google/android/play/core/appupdate/AppUpdateManager +- https://medium.com/swlh/updating-users-to-the-latest-app-release-on-ios-ed96e4c76705 +- https://gist.github.com/DineshKachhot/f63fcebceca6351fc982cafd38f6f05c +--- + +## Overview + +This weakness occurs when an app has no mechanism to force users to update to a more secure version after a critical vulnerability has been remediated. + +When a critical vulnerability is found in a production app, the developer needs a way to migrate existing users to the latest version as quickly as possible. Platforms provide building blocks for this, such as Android In-App Updates (`AppUpdateManager`) and store version checks on iOS, but robust enforcement requires the backend to signal and enforce the minimum acceptable version. + +## Modes of Introduction + +- **No Enforced-Update Mechanism**: Shipping the app without any in-app or enforced update flow, so vulnerable versions keep working indefinitely. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can exploit already-fixed vulnerabilities against users stuck on old versions, resulting in exposure of user data long after a patch was published. +- **Compromise of System Integrity and Business Operations**: The app owner cannot retire vulnerable versions from the installed base, resulting in a prolonged attack window. + +## Mitigations + +- **Implement an Enforced Update Flow**: Use platform mechanisms such as Android In-App Updates or a version check against the app store on iOS to require updating when a critical fix ships. +- **Enforce the Minimum Version Server-Side**: Have the backend declare the minimum supported app version and reject requests from older clients. +- **Distinguish Flexible and Immediate Updates**: Reserve blocking (immediate) updates for security-critical releases and use flexible updates otherwise, so users accept the mechanism when it matters. diff --git a/weaknesses/MASVS-CODE/MASWE-0041.md b/weaknesses/MASVS-CODE/MASWE-0041.md new file mode 100644 index 00000000..4c44c8f1 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0041.md @@ -0,0 +1,79 @@ +--- +title: Dependencies with Known Vulnerabilities +id: MASWE-0041 +alias: dependencies-with-known-vulnerabilities +requirement: "The app's third-party components are regularly checked for known vulnerabilities." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0041 +attacks: [MAS-ATTACK-0073] +mappings: + masvs-v1: [MSTG-CODE-5] + masvs-v2: [MASVS-CODE-3] + cwe: [1395, 1357] + android-risks: + - insecure-library + - unsafe-download-manager + android-core-app-quality: [SDK_Maintenance, Security_Provider_Initialization] + maswe-beta: [MASWE-0076] +refs: +- https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf +- https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf +- https://developer.android.com/guide/practices/sdk-best-practices +- https://developer.android.com/privacy-and-security/security-best-practices#services-dependencies-updated +- https://developer.android.com/privacy-and-security/security-best-practices#update-dependencies +- https://support.google.com/googleplay/android-developer/answer/14514531 +- https://support.google.com/googleplay/android-developer/answer/13326895 +- https://developer.apple.com/support/third-party-SDK-requirements/ +- https://www.youtube.com/watch?v=3klmiHX0uVQ +- https://developer.apple.com/videos/play/wwdc2023/10060/ +--- + +## Overview + +This weakness occurs when an app includes third-party libraries, software development kits (SDKs), or frameworks that contain publicly known vulnerabilities. + +Mobile apps often depend on such components, either open-source components maintained by the community or closed-source products provided by commercial vendors, to implement functionality, streamline development, or integrate platform services. Vulnerabilities in dependencies can be more easily exploited than vulnerabilities in first-party code because they (and some exploits) are often documented in public databases, such as the CVE list, or accessible through security advisories. + +**The developer is responsible** for ensuring all dependencies are secure and up to date because they are part of the app's codebase and therefore extend the app's attack surface. Google and Apple emphasize this in their security best practices: + +!!! quote "Google's [Using SDKs safely and securely](https://support.google.com/googleplay/android-developer/answer/13326895)" + + "If you include an SDK in your app, you are responsible for ensuring that their third-party code and practices are compliant with Google Play Developer Program Policies and do not cause your app to violate policies." + +!!! quote "Apple's [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)" + + "You are responsible for making sure everything in your app complies with these guidelines, including ad networks, analytics services, and third-party SDKs, so review and choose them carefully." + +In terms of privacy, dependencies can introduce risks if they collect or transmit user data without proper consent or transparency. Both Google and Apple require third-party SDKs used in apps to comply with their privacy policies and guidelines to ensure user data is handled securely and transparently. It is the developer's responsibility to ensure that any third-party libraries or SDKs used in the app adhere to these requirements, even if the libraries themselves are not under their direct control and even if they don't use the specific code that could violate the platform's policies. + +!!! quote "Google's [Using SDKs safely and securely](https://support.google.com/googleplay/android-developer/answer/13326895)" + + "App developers are required to treat any data collection from within their app by an SDK as if they collected it directly." + +!!! quote "Apple's [Third-party SDK requirements](https://developer.apple.com/support/third-party-SDK-requirements/)" + + "When you use a third-party SDK with your app, you are responsible for all the code the SDK includes in your app, and need to be aware of its data collection and use practices. + +For more information on privacy and data collection declarations, see @MASWE-0068. + +## Modes of Introduction + +- **Direct Dependencies**: Including vulnerable dependencies either manually (by copying and linking source or binary files) or, more commonly, via package managers and build tools (e.g., Gradle, CocoaPods, Swift Package Manager). This includes both first- and third-party SDKs, and may involve both statically and dynamically linked libraries. +- **Transitive Dependencies**: Pulling in vulnerable dependencies indirectly through other libraries or SDKs that the app uses, even if the app does not directly include the vulnerable library itself. +- **Dynamically Loaded Dependencies**: Loading libraries dynamically at runtime, which can make it difficult to track and manage dependencies and can lead to a vulnerable version being used without the developer's knowledge. +- **Outdated Platform Security Components**: Relying on platform-provided security components, such as cryptographic libraries or SSL/TLS implementations, that are outdated or lack timely updates. For instance, on Android, the system's security provider responsible for secure network communications must be explicitly updated by the developer at app startup. +- **Usage of Third-Party Frameworks**: Building the app on a third-party application framework such as Flutter or React Native, where the framework itself, as well as any platform-specific bindings, may contain vulnerabilities. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can exploit vulnerable components to bypass access controls or cryptographic protections and expose credentials, session tokens, or personally identifiable information (PII), resulting in data breaches with legal, financial, and reputational consequences for the app owner. +- **Execution of Unauthorized Code**: Attackers can exploit vulnerabilities in embedded dependencies to execute arbitrary code within the app's context (e.g., through code injection), escalate privileges, or manipulate app behavior, resulting in compromised user accounts, abuse of backend services, or persistent access to protected resources. +- **Legal and Regulatory Non-Compliance**: Shipping dependencies with publicly known CVEs can violate regulatory requirements (e.g., GDPR, HIPAA, PCI-DSS) or platform security policies (e.g., Google Play or App Store guidelines), resulting in app rejection, fines, or mandatory disclosures for the app owner. + +## Mitigations + +- **Use a Software Bill of Materials (SBOM)**: Produce and maintain an SBOM to track all components and transitive dependencies, ensuring visibility and accountability for third-party code. See [NIST SSDF (NIST SP 800-218) PS.3.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf), [NTIA The Minimum Elements For a Software Bill of Materials (SBOM)](https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf), [CISA SBOM Types document](https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf) for more information on SBOMs and their importance in managing software dependencies. +- **Update Dependencies Responsibly**: As part of secure [dependency management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html), regularly monitor all used third-party dependencies for security-related updates (for example, by using Software Composition Analysis (SCA) tools and SBOMs in your CI/CD pipelines). Apply updates when they fix known vulnerabilities, and pin versions explicitly to prevent unexpected changes and reduce the risk of supply-chain attacks. +- **Remove Unused or Obsolete Dependencies**: Periodically review and eliminate unused, legacy, or unnecessary libraries to reduce the app's attack surface and dependency footprint. +- **Use Trusted Sources**: Only include libraries and SDKs from reputable sources, such as official repositories or well-maintained open-source projects, to minimize the risk of introducing malicious or vulnerable code. diff --git a/weaknesses/MASVS-CODE/MASWE-0042.md b/weaknesses/MASVS-CODE/MASWE-0042.md new file mode 100644 index 00000000..ccb39d65 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0042.md @@ -0,0 +1,41 @@ +--- +title: Running on a Recent Platform Version Not Ensured +id: MASWE-0042 +alias: run-on-recent-platform-version +requirement: "The app detects if it is running on an unsupported OS version and reacts appropriately." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0042 +attacks: [MAS-ATTACK-0054, MAS-ATTACK-0055] +mappings: + masvs-v2: [MASVS-CODE-1] + cwe: [451, 693, 1104, 1357] + android-risks: + - strandhogg + - unsafe-download-manager + maswe-beta: [MASWE-0077, MASWE-0057] +refs: +- https://developer.android.com/topic/security/risks/strandhogg +--- + +## Overview + +This weakness occurs when an app does not ensure that it runs on a sufficiently recent platform version, e.g. via `minSdkVersion` on Android or `MinimumOSVersion` on iOS. + +Ensuring a recent minimum platform version guarantees the availability of security features and components the app relies on, such as hardware-backed key storage, runtime permissions, Network Security Configuration (Android 7.0+), and App Transport Security (iOS 9+), as well as secure WebView behavior. Supporting older versions also exposes users to platform-level vulnerabilities that were fixed in later releases, such as the StrandHogg task-affinity attacks on older Android versions, which the app cannot fix on its own. + +## Modes of Introduction + +- **Low Minimum Version with Modern Assumptions**: Setting a low minimum OS version to support older devices while implicitly or explicitly relying on security features (e.g. runtime permissions, hardware-backed keystore, network security policies) that do not exist on those versions. +- **Known-Vulnerable Platform Versions Supported**: Allowing the app to run on OS versions affected by relevant, unfixable platform vulnerabilities (e.g. StrandHogg v1/v2 task affinity and `allowTaskReparenting` abuse on older Android). + +## Impact + +- **Compromise of Sensitive Data**: Attackers can leverage missing platform protections or unpatched OS vulnerabilities to reach the app's data, resulting in exposure of user data on outdated devices. +- **Authentication or Authorization Bypass**: Attackers can abuse platform flaws such as task hijacking to phish credentials from the app's users on affected versions, resulting in account takeover. + +## Mitigations + +- **Raise the Minimum Platform Version**: Set `minSdkVersion` / `MinimumOSVersion` high enough that every security feature the app depends on is guaranteed to be present. +- **Gate Sensitive Features by Version**: Where supporting older versions is a hard business requirement, detect the platform version at runtime and disable sensitive functionality, or warn and terminate, on versions that cannot provide the required protections. +- **Reassess the Minimum Regularly**: Revisit the supported version floor as platform vulnerabilities are published and usage of old versions declines. diff --git a/weaknesses/MASVS-CODE/MASWE-0043.md b/weaknesses/MASVS-CODE/MASWE-0043.md new file mode 100644 index 00000000..ac6ff358 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0043.md @@ -0,0 +1,39 @@ +--- +title: Latest Platform Version Not Targeted +id: MASWE-0043 +alias: target-latest-platform-version +requirement: "The app targets the latest platform version." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0043 +attacks: [MAS-ATTACK-0056] +mappings: + masvs-v2: [MASVS-CODE-1] + cwe: [693, 1357] + android-core-app-quality: [Target_SDK_Version, Compile_SDK_Version] + maswe-beta: [MASWE-0078] +refs: +- https://developer.android.com/google/play/requirements/target-sdk +- https://developer.apple.com/news/upcoming-requirements/ +--- + +## Overview + +This weakness occurs when an app does not target the latest platform version, missing the newest platform-enforced security protections and behavior changes. + +Targeting the latest platform version, via `targetSdkVersion` on Android or by building with the latest Xcode/SDK on iOS, opts the app into protections such as scoped storage, stricter runtime-permission handling, permission auto-reset, and modern TLS defaults. When an app targets an old version, the OS applies backward-compatibility behaviors and the app silently misses these protections. This is distinct from the minimum supported version (see @MASWE-0042): here the concern is the target/compiled version. + +## Modes of Introduction + +- **Outdated Target Version**: Keeping `targetSdkVersion` on Android, or the Xcode/SDK used to build on iOS, below current requirements, so newer platform-enforced protections never apply to the app. +- **Compatibility Behaviors Left in Place**: Relying on legacy behaviors (e.g. broad storage access or lenient permission handling) that only continue to work because the app targets an old version. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can take advantage of legacy behaviors, such as broader file-system or permission access, resulting in exposure of user data that current platform defaults would have protected. +- **Compromise of System Integrity and Business Operations**: The app can fall below app-store target-version requirements, resulting in blocked updates or removal from distribution for the app owner. + +## Mitigations + +- **Target the Latest Platform Version**: Update `targetSdkVersion` and build with the latest SDK promptly each platform cycle, following the store requirements for [Android](https://developer.android.com/google/play/requirements/target-sdk) and [iOS](https://developer.apple.com/news/upcoming-requirements/). +- **Adopt New Protections**: Review each platform release's behavior changes and migrate off legacy behaviors. diff --git a/weaknesses/MASVS-CODE/MASWE-0044.md b/weaknesses/MASVS-CODE/MASWE-0044.md new file mode 100644 index 00000000..5f6d1647 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0044.md @@ -0,0 +1,43 @@ +--- +title: Unsafe Dynamic Code Loading +id: MASWE-0044 +alias: unsafe-code-loading +requirement: "The app loads dynamic code safely from trusted sources." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0044 +attacks: [MAS-ATTACK-0014, MAS-ATTACK-0057] +mappings: + masvs-v2: [MASVS-CODE-4] + cwe: [494] + android-risks: + - dynamic-code-loading + - create-package-context + android-core-app-quality: [App_Bundles] + maswe-beta: [MASWE-0085] +refs: +- dynamic-code-loading +--- + +## Overview + +This weakness occurs when an app loads and executes code resolved at runtime without verifying its source and integrity. + +Dynamic code loading includes loading native libraries via `dlopen`, loading DEX/JAR files through class loaders, and downloading executable code or scripts at runtime. When the loaded code comes from writable or external locations, or is fetched without integrity and authenticity verification, an attacker who can modify or substitute it gains arbitrary code execution within the app's context, with all the app's permissions and data access. + +## Modes of Introduction + +- **Loading from Writable or External Locations**: Loading native libraries or DEX/JAR files from writable, external, or world-accessible storage where other malicious apps can replace them. +- **Downloaded Code Without Verification**: Downloading and executing code, plugins, or scripts without verifying their integrity and authenticity (e.g. signature verification, see @MASWE-0015). +- **Code from Other Packages**: Executing code from other installed packages (e.g. via package contexts with code inclusion) whose identity and integrity are not verified. + +## Impact + +- **Execution of Unauthorized Code**: Attackers can run attacker-controlled code with the app's identity, permissions, and data access, resulting in full compromise of the app's functionality on the device. +- **Compromise of Sensitive Data**: Attackers can use the injected code to read the app's private data and credentials, resulting in unauthorized disclosure of user and app data. + +## Mitigations + +- **Avoid Dynamic Code Loading**: Ship all executable code inside the signed app package whenever possible; app stores also restrict runtime code delivery. +- **Load Only from Protected Locations**: When loading is unavoidable, load code only from the app's protected, read-only installation directories, never from writable or external storage. +- **Verify Integrity and Authenticity**: Verify a cryptographic signature over any dynamically delivered code against a pinned trusted key before loading it, and deliver it only over secure channels. diff --git a/weaknesses/MASVS-CODE/MASWE-0045.md b/weaknesses/MASVS-CODE/MASWE-0045.md new file mode 100644 index 00000000..ada076c9 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0045.md @@ -0,0 +1,42 @@ +--- +title: Compiler-Provided Security Features Not Used +id: MASWE-0045 +alias: compiler-provided-security-features-not-implemented +requirement: "The app uses the compiler-provided security features of the platform." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0045 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0059] +mappings: + masvs-v2: [MASVS-CODE-3, MASVS-CODE-4] + android-risks: + - use-of-native-code + maswe-beta: [MASWE-0116] +refs: +- https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md +- https://sensepost.com/blog/2021/on-ios-binary-protections/ +- https://www.sans.org/blog/stack-canaries-gingerly-sidestepping-the-cage/ +--- + +## Overview + +This weakness occurs when an app's native code is built without the exploit-mitigation features that compilers and toolchains provide. + +Mitigations such as stack canaries (stack-smashing protection), Address Space Layout Randomization (ASLR) via Position-Independent Executables (PIE/PIC), non-executable memory (NX/DEP), fortified (bounds-checked) libc functions, and Automatic Reference Counting (ARC) on iOS do not remove memory-corruption bugs, but they substantially raise the effort required to exploit them. Binaries built without these features make any memory-corruption vulnerability, in the app's own code or its native dependencies, far easier to turn into code execution. + +## Modes of Introduction + +- **Missing Stack Protection**: Compiling native code without stack canaries, leaving stack-based buffer overflows directly exploitable. +- **Missing PIE/ASLR Support**: Building binaries that are not position-independent, defeating address-space layout randomization. Note that on current Android versions the linker no longer loads non-PIE binaries, but legacy toolchains and other platforms can still produce them. +- **Missing Fortified Functions**: Building without fortify-source style bounds-checked replacements for risky libc functions. +- **Unsafe Memory Management Choices**: Disabling Automatic Reference Counting on iOS or otherwise opting out of memory-safety features where safer defaults exist. + +## Impact + +- **Execution of Unauthorized Code**: Attackers can convert memory-corruption bugs into reliable code execution in the app's context, resulting in full compromise of the app and its data. +- **Compromise of Sensitive Data**: Attackers can read process memory through exploited native bugs, resulting in exposure of credentials, keys, and user data held in memory. + +## Mitigations + +- **Enable Compiler Mitigations**: Build all native code and dependencies with stack canaries, PIE/PIC, non-executable memory, and fortified functions enabled, and verify the flags in release binaries rather than assuming toolchain defaults. +- **Keep Memory-Safety Features On**: Use Automatic Reference Counting on iOS and prefer memory-safe languages for new code where feasible. diff --git a/weaknesses/MASVS-CODE/MASWE-0046.md b/weaknesses/MASVS-CODE/MASWE-0046.md new file mode 100644 index 00000000..90b939b9 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0046.md @@ -0,0 +1,43 @@ +--- +title: Use of Deprecated APIs or Functionality +id: MASWE-0046 +alias: deprecated-apis +requirement: "The app does not use deprecated APIs or functionality." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0046 +attacks: [MAS-ATTACK-0058] +mappings: + masvs-v1: [MSTG-CRYPTO-4] + masvs-v2: [MASVS-CODE-3, MASVS-CRYPTO-2] + cwe: [327, 477, 522] + maswe-beta: [MASWE-0015] +refs: +- https://developer.android.com/about/versions/12/behavior-changes-all#bouncy-castle +- https://developer.android.com/reference/java/security/KeyStore +- https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication +--- + +## Overview + +This weakness occurs when an app relies on deprecated APIs or functionality that are no longer maintained, may lack security fixes, or have been superseded by safer alternatives. + +APIs may become deprecated for various reasons. This may be due to architectural changes, lack of developer adoption, reduced hardware support, or a better-designed replacement that addresses security shortcomings in the old API. Continuing to use deprecated security-relevant APIs can leave the app exposed to weaknesses that the platform has already addressed. A representative example is the use of deprecated Android KeyStore implementations such as Bouncy Castle (BKS), but this weakness covers deprecated APIs and functionality in general, including cryptography, storage, networking, and platform features. + +## Modes of Introduction + +- **Deprecated Cryptographic Providers**: Using deprecated keystore or cryptographic provider implementations (e.g. Bouncy Castle-backed KeyStore on Android) instead of their maintained replacements. +- **Deprecated Platform APIs**: Continuing to use platform APIs that have been superseded by safer alternatives with improved security behavior. +- **Deprecation Warnings Ignored**: Building with unresolved deprecation warnings, so the use of outdated functionality accumulates unnoticed. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can exploit the known shortcomings of deprecated implementations, resulting in exposure of data those APIs were supposed to protect. +- **Authentication or Authorization Bypass**: Attackers can abuse weaknesses in deprecated authentication- or keystore-related APIs, resulting in unauthorized access to protected keys or functionality. + +## Mitigations + +- **Migrate Off Deprecated APIs**: Replace deprecated APIs with the platform's recommended alternatives as part of regular maintenance. Prioritize migration of security-relevant APIs. +- **Treat Deprecation Warnings as Actionable**: Surface deprecation warnings in builds and reviews, and track migrations for security-relevant APIs with priority. +- **Follow Platform Release Notes**: Review each platform release's deprecation and behavior-change notes to plan migrations before old functionality is removed or breaks. +- **Test the App on All Supported Platforms**: Run the app on all platform API versions supported during development. diff --git a/weaknesses/MASVS-CODE/MASWE-0047.md b/weaknesses/MASVS-CODE/MASWE-0047.md new file mode 100644 index 00000000..d8048953 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0047.md @@ -0,0 +1,49 @@ +--- +title: Using Non-Standard APIs for Security-Critical Functionality +id: MASWE-0047 +alias: non-standard-security-apis +requirement: "The app uses standard APIs for security-critical functionality." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0047 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0014, MAS-ATTACK-0021] +mappings: + masvs-v1: [MSTG-CRYPTO-2, MSTG-NETWORK-6] + masvs-v2: [MASVS-CODE-3, MASVS-AUTH-1, MASVS-CRYPTO-1, MASVS-NETWORK-1] + cwe: [287, 326, 327, 1240] + android-risks: + - bad-dns + android-core-app-quality: [Cryptographic_Algorithms] + maswe-beta: [MASWE-0019, MASWE-0032, MASWE-0049] +refs: +- https://developer.android.com/privacy-and-security/security-tips#Credentials +- https://developer.apple.com/documentation/security/password_autofill +- https://developer.android.com/privacy-and-security/cryptography#crypto_provider +- https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile +--- + +## Overview + +This weakness occurs when security-critical functionality, such as cryptography, networking and TLS, DNS resolution, or authentication, is implemented with custom code or unproven components instead of platform-provided APIs or established, peer-reviewed libraries. + +Platform APIs and vetted libraries are designed and maintained by experts, incorporate security best practices, and receive timely updates. Custom or non-standard implementations are far more likely to contain subtle, exploitable flaws and to miss security updates. This weakness also covers failing to leverage secure functionality the platform already provides, for example using an insecure custom DNS setup instead of the platform's Private DNS / DNS-over-TLS support. It is the security-focused counterpart to @MASWE-0074, which applies the same principle from a privacy angle. + +## Modes of Introduction + +- **Roll-Your-Own Cryptography**: Implementing custom or non-compliant cryptography (e.g. not meeting standards such as FIPS 140-2/3), unproven algorithms, or home-grown constructions that have not undergone rigorous peer review and formal validation. +- **Custom Networking or TLS Stacks**: Rolling a custom networking/TLS stack or using outdated third-party networking libraries instead of proven APIs such as `URLSession` on iOS or `HttpsURLConnection`/OkHttp on Android. +- **Custom DNS Resolution**: Bypassing platform-provided name resolution with a custom resolver that lacks equivalent transport security, trust management, and update guarantees. +- **Custom Authentication**: Implementing custom authentication flows instead of platform-provided authentication APIs (e.g. Android Credential Manager/`AccountManager`, iOS Authentication Services / Password AutoFill). +- **Unmaintained Security Libraries**: Depending on unproven or unmaintained third-party components for security-critical functionality. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can break weak custom cryptography or intercept traffic handled by flawed custom stacks, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can exploit logic flaws in custom authentication implementations, resulting in unauthorized access to user accounts and protected functionality. + +## Mitigations + +- **Use Platform Security APIs**: Prefer platform-provided functionality for cryptography, TLS, DNS, and authentication; it is expert-maintained and updated with the OS. +- **Choose Vetted, Standards-Compliant Libraries**: Where a library is needed, use established, peer-reviewed components that comply with recognized standards (e.g. FIPS 140-2/3, BSI TR-02102) and are actively maintained. +- **Never Roll Your Own Crypto or TLS**: Do not design or implement custom cryptographic algorithms, protocols, or TLS stacks for production use. +- **Leverage Secure Platform Defaults**: Use the platform's secure name resolution (e.g. Private DNS / DNS-over-TLS) and credential-management flows instead of custom substitutes. diff --git a/weaknesses/MASVS-CODE/MASWE-0048.md b/weaknesses/MASVS-CODE/MASWE-0048.md new file mode 100644 index 00000000..c79f4c25 --- /dev/null +++ b/weaknesses/MASVS-CODE/MASWE-0048.md @@ -0,0 +1,63 @@ +--- +title: Unsafe Handling of Untrusted Data +id: MASWE-0048 +alias: unsafe-untrusted-data +requirement: "The app securely handles untrusted data." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0048 +attacks: [MAS-ATTACK-0047, MAS-ATTACK-0059] +mappings: + masvs-v1: [MSTG-PLATFORM-2] + masvs-v2: [MASVS-CODE-4] + cwe: [20, 22, 73, 89, 116, 345, 348, 349, 502, 611, 924] + android-risks: + - path-traversal + - zip-path-traversal + - sql-injection + - unsafe-deserialization + - xml-external-entities-injection + - untrustworthy-contentprovider-provided-filename + - use-of-native-code + maswe-beta: [MASWE-0079, MASWE-0080, MASWE-0081, MASWE-0082, MASWE-0083, MASWE-0084, MASWE-0086, MASWE-0087, MASWE-0088] +refs: +- https://developer.android.com/topic/security/risks/path-traversal +- https://developer.android.com/topic/security/risks/sql-injection +- unsafe-deserialization +- https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html +--- + +## Overview + +This weakness occurs when data originating outside the app's trust boundary reaches a sensitive sink without being validated, sanitized, or safely parsed. + +Untrusted data is any data the app did not create itself, regardless of how it arrives: network responses (even over TLS), data restored from backups, external interfaces such as Bluetooth, NFC, and USB, local files (including document pickers and archives), user interface input (text fields, QR codes, URLs, the clipboard), and the platform's IPC (e.g., for Android, received intents, broadcasts, content URIs, or deep links). + +When the untrusted data reaches a dangerous sink that has not been validated or sanitized, it cause unintended behavior of the application by exploiting vulnerabilities like SQL injection, path traversal (including variants like ZIP path traversal), XML external entity (XXE) injection, insecure object deserialization, output-encoding flaws, or memory corruption in native parsers, or misleading presentation of security-relevant information. + +## Modes of Introduction + +- **Missing Validation at Trust Boundaries**: Consuming untrusted data from the network, backups, external interfaces, files, UI, or platform IPC without validating type, length, format, and range before use. +- **Untrusted Data in Queries**: Concatenating untrusted input into queries like SQL queries instead of using parameterized APIs. +- **Untrusted Paths and Archives**: Using externally supplied file names or paths (e.g. from ZIP entries) without canonicalization and containment checks. +- **Insecure Parsing**: Parsing untrusted XML with external entities enabled, or emitting untrusted data without proper output encoding. +- **Insecure Deserialization**: Deserializing untrusted data into rich object types (e.g. `Serializable`, `Parcelable`, `NSCoding`, XML/JSON object mappers) without restricting the allowed types. +- **Weakly Validated URI Handling**: Relying on URI parsing classes that apply little to no validation of untrusted input when making security decisions. +- **Unsafe Presentation of Untrusted Data**: Displaying untrusted data in notifications, warnings, confirmation dialogs, or other security-sensitive interfaces without constraining its length or formatting. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can extract or overwrite private files and database contents through path traversal, SQL injection, or XXE, resulting in unauthorized disclosure or modification of user and app data. +- **Execution of Unauthorized Code**: Attackers can exploit insecure deserialization or memory corruption in parsers, resulting in attacker-controlled code running in the app's context. +- **Authentication or Authorization Bypass**: Attackers can manipulate queries or logic through injected input, resulting in access to data or functionality beyond what the caller is authorized for. +- **Compromise of Content or UI Integrity**: Attackers can obscure, alter, or impersonate trusted application content in interfaces or notifications, resulting in users approving unintended actions or ignoring legitimate security alerts. +- **Application Content Spoofing**: Attackers can obscure, alter, or impersonate trusted application content in interfaces or notifications, resulting in users approving unintended actions or ignoring legitimate security alerts. + +## Mitigations + +- **Validate at Every Trust Boundary**: Treat all externally originated data as untrusted and validate it against strict expectations before use. +- **Use Parameterized Queries**: Access databases exclusively through parameterized or prepared statements. Do not build queries by concatenating untrusted input. +- **Canonicalize and Contain Paths**: Canonicalize externally supplied file names and paths and verify they resolve inside the intended directory before any file operation. +- **Harden Parsers**: Disable external entity resolution for XML, apply correct output encoding for the destination context, and prefer hardened platform parsers. +- **Deserialize Safely**: Avoid deserializing untrusted data into rich object graphs; prefer simple data formats and safe APIs with explicit type allow-lists. +- **Distinguish Untrusted Data From Application-Generated Content**: Distinguish externally-provided values from trusted application content, especially in notifications and security-sensitive interfaces. Apply context-appropriate length, line, and formatting restrictions so untrusted data cannot obscure or alter the apparent meaning of the information presented. diff --git a/weaknesses/MASVS-CODE/MASWE-0075.md b/weaknesses/MASVS-CODE/MASWE-0075.md index c4f7ebed..36464376 100644 --- a/weaknesses/MASVS-CODE/MASWE-0075.md +++ b/weaknesses/MASVS-CODE/MASWE-0075.md @@ -1,25 +1,43 @@ --- -title: Enforced Updating Not Implemented +title: Malicious Code Included in the App id: MASWE-0075 -alias: enforced-updating +alias: malicious-code-included +requirement: "The app package does not contain malicious code." platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0075 +attacks: [MAS-ATTACK-0060, MAS-ATTACK-0061] mappings: - masvs-v1: [MSTG-ARCH-9] - masvs-v2: [MASVS-CODE-2] - cwe: [602, 693] - + masvs-v2: [MASVS-CODE-3] + cwe: [506, 507, 511] refs: -- https://developer.android.com/guide/playcore/in-app-updates -- https://developer.android.com/reference/com/google/android/play/core/appupdate/AppUpdateManager -- https://medium.com/swlh/updating-users-to-the-latest-app-release-on-ios-ed96e4c76705 -- https://gist.github.com/DineshKachhot/f63fcebceca6351fc982cafd38f6f05c -draft: - description: Check if the app enforces updates e.g. via AppUpdateManager on Android or itunes check on app version on iOS. However, the backend would be enforcing this and not only the app locally. - topics: - - The in‑app update mechanism isn't used at all (CWE-693). - - The update enforcement occurs purely locally (client‑side) without server‑side checks (CWE-602). -status: placeholder - +- insecure-library +- https://support.google.com/googleplay/android-developer/answer/13326895 +- https://developer.apple.com/support/third-party-SDK-requirements/ --- +## Overview + +This weakness occurs when an app ships with malicious code, introduced either intentionally by an insider or unintentionally through a compromised dependency, SDK, build tool, or other supply-chain attack. + +Malicious code can exfiltrate data, execute hidden or backdoored functionality, display unwanted content, or perform actions against the user's interest. Because the developer is responsible for all code shipped in the app, including third-party SDKs, the codebase must be reviewed and the supply chain examined to detect and prevent the inclusion of malicious code. This complements @MASWE-0041, which covers dependencies with known vulnerabilities, and @MASWE-0077, which covers the inability to verify what was actually built. + +## Modes of Introduction + +- **Malicious Developer**: Malicious code committed intentionally by someone with access to the codebase or through a compromised developer account. +- **Compromised Dependencies**: Malicious or trojanized third-party SDKs and libraries pulled into the app, including through typosquatting or hijacked packages. +- **Compromised Build Pipeline**: Build tools, plugins, or CI/CD infrastructure that inject code into the app during compilation or packaging. +- **Hidden Functionality**: Backdoors, hidden switches, or undisclosed capabilities shipped in the app or its components. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can exfiltrate user data and credentials from inside the app's trust boundary, resulting in large-scale disclosure across the entire user base. +- **Execution of Unauthorized Code**: Attackers can trigger backdoored or hidden functionality at will, resulting in attacker-controlled behavior running with the app's identity and permissions. +- **Compromise of System Integrity and Business Operations**: The app owner distributes malware to their own users, resulting in app-store removal, incident response costs, and severe reputational damage. + +## Mitigations + +- **Review Code and Changes**: Enforce code review for all changes, restrict and monitor access to the codebase, and require strong authentication for developer accounts. +- **Examine the Supply Chain**: Pin dependency versions, verify package integrity and provenance, source components only from reputable publishers, and monitor them with Software Composition Analysis (see @MASWE-0041). +- **Protect the Build Pipeline**: Harden and monitor CI/CD infrastructure, restrict who and what can alter build configurations, and generate build provenance attestations (see @MASWE-0077). +- **Analyze the Shipped Artifact**: Scan and behaviorally analyze release builds to detect unexpected code, permissions, or network endpoints before distribution. diff --git a/weaknesses/MASVS-CODE/MASWE-0076.md b/weaknesses/MASVS-CODE/MASWE-0076.md index aa678db5..6f7795be 100644 --- a/weaknesses/MASVS-CODE/MASWE-0076.md +++ b/weaknesses/MASVS-CODE/MASWE-0076.md @@ -1,79 +1,42 @@ --- -title: Dependencies with Known Vulnerabilities +title: Non-Reproducible Builds id: MASWE-0076 -alias: dependencies-with-known-vulnerabilities +alias: non-reproducible-builds +requirement: "The app offers reproducible builds." platform: [android, ios] -profiles: [L1, L2] +profiles: [L2] +threat: MAS-THREAT-0077 +attacks: [MAS-ATTACK-0060, MAS-ATTACK-0062] mappings: - masvs-v1: [MSTG-CODE-5] masvs-v2: [MASVS-CODE-3] - cwe: [1395, 1357] - android-core-app-quality: [SC-N3, PS-T4] - android-risks: - - https://developer.android.com/privacy-and-security/risks/insecure-library - nist-ssdf: [PS.3.2] -status: new + cwe: [1357, 494] refs: -- https://developer.android.com/privacy-and-security/risks/insecure-library -- https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf -- https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf -- https://developer.android.com/guide/practices/sdk-best-practices -- https://developer.android.com/privacy-and-security/security-best-practices#services-dependencies-updated -- https://developer.android.com/privacy-and-security/security-best-practices#update-dependencies -- https://support.google.com/googleplay/android-developer/answer/14514531 -- https://support.google.com/googleplay/android-developer/answer/13326895 -- https://developer.apple.com/support/third-party-SDK-requirements/ -- https://www.youtube.com/watch?v=3klmiHX0uVQ -- https://developer.apple.com/videos/play/wwdc2023/10060/ +- https://reproducible-builds.org/ +- https://slsa.dev/ +- https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md --- ## Overview -Mobile apps often depend on third-party libraries, software development kits (SDKs), or frameworks, either open-source components maintained by the community or closed-source products provided by commercial vendors, to implement functionality, streamline development, or integrate platform services. +This weakness occurs when compiling the app's source with the same build environment does not yield a bit-for-bit identical binary, making it impossible to independently verify that a distributed binary was built from the claimed, unmodified source. -When these dependencies contain vulnerabilities, they can be more easily exploited than vulnerabilities in first-party code because these vulnerabilities (and some exploits) are often documented in public databases, such as the CVE list, or accessible through security advisories. +Reproducible builds allow third parties, and the developers themselves, to detect tampering or injected malicious code by rebuilding from source and comparing the result with the released artifact. Without reproducibility, this verification is impossible, weakening supply-chain integrity. Together with build provenance and attestation frameworks (e.g. SLSA), reproducible builds let stakeholders verify the integrity of released artifacts. -**The developer is responsible** for ensuring all dependencies are secure and up to date because they are part of the app's codebase and therefore extend the app's attack surface. Google and Apple emphasize this in their security best practices: - -!!! quote "Google's [Using SDKs safely and securely](https://support.google.com/googleplay/android-developer/answer/13326895)" - - "If you include an SDK in your app, you are responsible for ensuring that their third-party code and practices are compliant with Google Play Developer Program Policies and do not cause your app to violate policies." - -!!! quote "Apple's [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)" - - "You are responsible for making sure everything in your app complies with these guidelines, including ad networks, analytics services, and third-party SDKs, so review and choose them carefully." - -In terms of privacy, dependencies can introduce risks if they collect or transmit user data without proper consent or transparency. Both Google and Apple require third-party SDKs used in apps to comply with their privacy policies and guidelines to ensure user data is handled securely and transparently. It is the developer's responsibility to ensure that any third-party libraries or SDKs used in the app adhere to these requirements, even if the libraries themselves are not under their direct control and even if they don't use the specific code that could violate the platform's policies. - -!!! quote "Google's [Using SDKs safely and securely](https://support.google.com/googleplay/android-developer/answer/13326895)" - - "App developers are required to treat any data collection from within their app by an SDK as if they collected it directly." - -!!! quote "Apple's [Third-party SDK requirements](https://developer.apple.com/support/third-party-SDK-requirements/)" - - "When you use a third-party SDK with your app, you are responsible for all the code the SDK includes in your app, and need to be aware of its data collection and use practices. +## Modes of Introduction -For more information on privacy and data collection declarations, see @MASWE-0112. +- **Non-Deterministic Build Outputs**: Embedding timestamps, absolute paths, environment data, or unstable orderings in build artifacts, so identical inputs produce differing outputs. +- **Unpinned Build Environments**: Building with undocumented or unpinned toolchains and dependencies, so it's impossible to recreate the environment that produced a release. +- **No Provenance or Attestation**: Publishing releases without provenance describing what was built, from which source, and by which pipeline. +- **Applying Non-Deterministic Obfuscation Controls**: By applying non-deterministic obfuscation controls, each build will generate a new random binary which cannot directly be compared with previous builds from the same code. ## Impact -Using dependencies with known vulnerabilities in mobile apps can result in various security risks, including but not limited to: - -- **Sensitive Data Exposure**: Vulnerable dependencies may be exploited to bypass access controls or cryptographic protections, which could lead to the exposure of sensitive user data, including credentials, session tokens, and personally identifiable information (PII). This can result in data breaches, which can have legal, financial and reputational consequences. -- **Execution of Unauthorized Code or Privilege Escalation**: Exploitable vulnerabilities in embedded dependencies can allow attackers to execute arbitrary code within the app's context (e.g., through code injection), escalate privileges, or manipulate app behavior. The overall impact can range from full compromise of user accounts, abuse of backend services or persistent access to protected resources. The business impact can be severe, including financial loss, service disruption, and damage to customer trust. -- **Regulatory and Policy Non-Compliance**: Including dependencies with publicly known CVEs may violate regulatory requirements (e.g., GDPR, HIPAA, PCI-DSS) or platform security policies (e.g., Google Play or App Store guidelines). Failure to update or remediate such vulnerabilities can result in app rejection, fines, or mandatory disclosures. - -## Modes of Introduction - -- **Direct Dependencies**: Vulnerable dependencies can be introduced into the app either manually (by copying and linking source or binary files) or more commonly via package managers and build tools (e.g., Gradle, CocoaPods, Swift Package Manager). This includes both first- and third-party SDKs, and may involve both statically and dynamically linked libraries. -- **Transitive Dependencies**: Dependencies can be pulled in indirectly through other libraries or SDKs that the app uses. This means that an app may still be affected by a vulnerable library if one of its dependencies includes it, even if the app does not directly include the library itself. -- **Dynamically Loaded Dependencies**: Some libraries may be dynamically loaded at runtime, which can make it difficult to track and manage dependencies. This can lead to situations where a vulnerable version of a library is used without the developer's knowledge. -- **Outdated Platform Security Components**: Mobile apps may depend on platform-provided security components, such as cryptographic libraries or SSL/TLS implementations. If these components are outdated or lack timely updates, they can introduce known vulnerabilities into the application. For instance, on Android, the system's security provider responsible for secure network communications must be explicitly updated by the developer at app startup. -- **Usage of Third-Party Frameworks**: Applications may be built in a third-party application framework such as Flutter or React Native. The framework itself, as well as any platform-specific bindings may contain vulnerabilities. +- **Execution of Unauthorized Code**: Attackers can inject code during the build or distribution process without straightforward detection, since no independent party can verify the binary against the source, resulting in malicious code shipping to the entire user base. +- **Loss of User Trust**: Users and auditors cannot verify that the shipped app matches the published source, resulting in weakened trust in the app, particularly for security- and privacy-sensitive apps. ## Mitigations -- **Use a Software Bill of Materials (SBOM)**: Produce and maintain an SBOM to track all components and transitive dependencies, ensuring visibility and accountability for third-party code. See [NIST SSDF (NIST SP 800-218) PS.3.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf), [NTIA The Minimum Elements For a Software Bill of Materials (SBOM)](https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf), [CISA SBOM Types document](https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf) for more information on SBOMs and their importance in managing software dependencies. -- **Update Dependencies Responsibly**: As part of secure [dependency management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html), regularly monitor all used third-party dependencies for security-related updates (for example, by using Software Composition Analysis (SCA) tools and SBOMs in your CI/CD pipelines). Apply updates when they fix known vulnerabilities, and pin versions explicitly to prevent unexpected changes and reduce the risk of supply-chain attacks. -- **Remove Unused or Obsolete Dependencies**: Periodically review and eliminate unused, legacy, or unnecessary libraries to reduce the app's attack surface and dependency footprint. -- **Use Trusted Sources**: Only include libraries and SDKs from reputable sources, such as official repositories or well-maintained open-source projects, to minimize the risk of introducing malicious or vulnerable code. +- **Make Builds Deterministic**: Eliminate timestamps, absolute paths, environment-dependent data, and unstable orderings from build outputs, following [reproducible-builds.org](https://reproducible-builds.org/) guidance. +- **Pin and Document the Build Environment**: Define the exact toolchain and dependency versions in version control so any party can recreate the build environment. +- **Publish Provenance and Attestations**: Generate build provenance (e.g. per [SLSA](https://slsa.dev/)) and, where feasible, publish verification instructions so third parties can reproduce and compare releases. +- **Use Deterministic Obfuscation Techniques**: Use obfuscation techniques which will always generate the same deterministic result. diff --git a/weaknesses/MASVS-CODE/MASWE-0077.md b/weaknesses/MASVS-CODE/MASWE-0077.md deleted file mode 100644 index d0ece2d4..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0077.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Running on a recent Platform Version Not Ensured -id: MASWE-0077 -alias: run-on-recent-platform-version -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CODE-1] - cwe: [693, 1357] - -draft: - description: e.g. via minSdkVersion on Android and MinimumOSVersion on iOS. with - this we Ensure services/components availability (MASVS-STORAGE-1), also the NSC/ATS - availability - Android > 7.0 / iOS > 9.0 (MASVS-NETWORK-1) and WebView secure - config (MASVS-PLATFORM-2). - topics: - - The app sets a low minimum OS version to support older devices, but still relies, implicitly or explicitly, on security features (e.g., runtime permissions, hardware-backed keystore, network security policies) that may not exist on those versions (CWE-693 and CWE-1357). -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0078.md b/weaknesses/MASVS-CODE/MASWE-0078.md deleted file mode 100644 index 8c333c4d..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0078.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Latest Platform Version Not Targeted -id: MASWE-0078 -alias: target-latest-platform-version -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CODE-1] - cwe: [693, 1357] - -draft: - description: The app does not target the latest platform version (e.g., via targetSdkVersion on Android or by using an older Xcode/toolchain), and as a result, misses out on the most recent platform-enforced security protections (e.g., scoped storage, permission auto-reset, modern TLS handling) (CWE-693 and CWE-1357). - topics: - - targetSDK on Android - - XCode version on iOS -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0079.md b/weaknesses/MASVS-CODE/MASWE-0079.md deleted file mode 100644 index afaad75c..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0079.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Unsafe Handling of Data from the Network -id: MASWE-0079 -alias: unsafe-network-data -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [924] - -draft: - description: Data received from the network should be treated as untrusted even if it is received over a secure channel. - topics: - - network -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0080.md b/weaknesses/MASVS-CODE/MASWE-0080.md deleted file mode 100644 index c064ad5a..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0080.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Unsafe Handling of Data from Backups -id: MASWE-0080 -alias: unsafe-backup-data -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [349] - -refs: -- https://developer.android.com/guide/topics/data/keyvaluebackup#RestoreVersion -draft: - description: The app does not validate restored backup data, potentially accepting untrusted modifications alongside trusted data (CWE-349). - topics: - - backup data validation - - backup data integrity -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0081.md b/weaknesses/MASVS-CODE/MASWE-0081.md deleted file mode 100644 index 0d4f32dd..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0081.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Unsafe Handling Of Data From External Interfaces -id: MASWE-0081 -alias: unsafe-external-data -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [924] - -draft: - description: When data is received from external interfaces (e.g. Bluetooth, NFC, - etc.), it should be treated as untrusted. - topics: - - Bluetooth - - NFC -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0082.md b/weaknesses/MASVS-CODE/MASWE-0082.md deleted file mode 100644 index 335765f8..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0082.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Unsafe Handling of Data From Local Storage -id: MASWE-0082 -alias: unsafe-local-storage -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [20, 22, 73, 349] - -refs: -- https://developer.android.com/topic/security/risks/path-traversal -- https://developer.android.com/topic/security/risks/zip-path-traversal -draft: - description: When data is read from local storage, it should be treated as untrusted. - topics: - - Internal Storage - - External Storage - - UIDocumentPickerViewController used by the receiver app - - The app does not validate or sanitize input from local storage, which may lead to injection vulnerabilities when the data is interpreted or used in sensitive operations (CWE-20). - - The app does not validate or sanitize file paths read from local storage, enabling potential path traversal attacks (CWE-22). - - Paths to local files are influenced by attacker-controlled input, and their content can be modified (common in external storage or document pickers), leading to unintended file access or tampering (CWE-73). - - The app processes data from local storage as if it were inherently trustworthy, without isolating or verifying it, allowing attackers to alter app state or behavior (CWE-349). -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0083.md b/weaknesses/MASVS-CODE/MASWE-0083.md deleted file mode 100644 index 6dea879e..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0083.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Unsafe Handling of Data From The User Interface -id: MASWE-0083 -alias: unsafe-ui-data -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-2] - masvs-v2: [MASVS-CODE-4, MASVS-PLATFORM-3] - cwe: [345, 348] - -draft: - description: e.g. text fields, QR codes, URLs, pasteboard, etc. - topics: - - text Fields - - QR Codes - - URLs - - Pasteboard -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0084.md b/weaknesses/MASVS-CODE/MASWE-0084.md deleted file mode 100644 index 74365696..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0084.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Unsafe Handling of Data from IPC -id: MASWE-0084 -alias: unsafe-ipc-data -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-2] - masvs-v2: [MASVS-CODE-4, MASVS-PLATFORM-1] - cwe: [20, 345, 349] - -draft: - description: e.g. received intents, broadcast receivers, URL validation, URL schemes, - etc. - topics: - - The app does not validate or sanitize input received through inter-process communication channels (e.g., intents, content URIs, broadcast receivers), which may lead to injection or logic vulnerabilities when the data is used in sensitive operations (CWE-20). - - The app assumes that data received from other apps via IPC is trustworthy, without verifying its authenticity or origin (CWE-345). - - The app combines untrusted IPC data with trusted inputs or internal state, which may allow attackers to influence app behavior or corrupt logic flows (CWE-349). -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0085.md b/weaknesses/MASVS-CODE/MASWE-0085.md deleted file mode 100644 index 009c0223..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0085.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Unsafe Dynamic Code Loading -id: MASWE-0085 -alias: unsafe-code-loading -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [494] - -draft: - description: e.g. when using dlopen, DexClassLoader, etc. - topics: - - dlopen - - DexClassLoader -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0086.md b/weaknesses/MASVS-CODE/MASWE-0086.md deleted file mode 100644 index 14317572..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0086.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: SQL Injection -id: MASWE-0086 -alias: sql-injection -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [89] - -refs: -- https://developer.android.com/topic/security/risks/sql-injection -draft: - description: e.g. prepared statements with variable binding (i.e. parameterized - queries) - topics: - - not using prepared statements -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0087.md b/weaknesses/MASVS-CODE/MASWE-0087.md deleted file mode 100644 index bc2c70d5..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0087.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Insecure Parsing and Escaping -id: MASWE-0087 -alias: insecure-parsing-escaping -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [116, 611] - -draft: - description: e.g. XML External Entity (XXE) attacks, X509 certificate parsing, character escaping. - topics: - - The app does not properly escape or encode special characters when handling structured output formats (e.g., HTML, XML, JSON), which may lead to injection or rendering issues in downstream components (CWE-116). - - The app parses XML input without restricting external entity resolution, allowing XML External Entity (XXE) attacks that can expose files, initiate SSRF, or disrupt app logic (CWE-611). -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0088.md b/weaknesses/MASVS-CODE/MASWE-0088.md deleted file mode 100644 index 08870c61..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0088.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Insecure Object Deserialization -id: MASWE-0088 -alias: insecure-deserialization -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CODE-4] - cwe: [502] - android-risks: - - https://developer.android.com/privacy-and-security/risks/unsafe-deserialization -draft: - description: e.g. XML, JSON, java.io.Serializable, Parcelable on Android or NSCoding - on iOS. - topics: - - XML - - JSON - - java.io.Serializable - - Parcelable - - NSCoding -status: placeholder -refs: -- https://i.blackhat.com/EU-22/Wednesday-Briefings/EU-22-Ke-Android-Parcels-Introducing-Android-Safer-Parcel.pdf -- https://github.com/michalbednarski/ReparcelBug2 -- https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html -- https://blog.oversecured.com/Exploiting-memory-corruption-vulnerabilities-on-Android ---- - diff --git a/weaknesses/MASVS-CODE/MASWE-0116.md b/weaknesses/MASVS-CODE/MASWE-0116.md deleted file mode 100644 index fdc3afd2..00000000 --- a/weaknesses/MASVS-CODE/MASWE-0116.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Compiler-Provided Security Features Not Used -id: MASWE-0116 -alias: compiler-provided-security-features-not-implemented -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CODE-3, MASVS-CODE-4] - cwe: [693] -refs: -- https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=397?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain -- https://partners.trellix.com/enterprise/en-us/assets/white-papers/wp-secure-coding-android-applications.pdf -- https://mas.owasp.org/MASTG/0x05i-Testing-Code-Quality-and-Build-Settings/#binary-protection-mechanisms -- https://mas.owasp.org/MASTG/0x06i-Testing-Code-Quality-and-Build-Settings/#binary-protection-mechanisms -- https://sensepost.com/blog/2021/on-ios-binary-protections/ -- https://www.sans.org/blog/stack-canaries-gingerly-sidestepping-the-cage/ -draft: - description: The app is compiled without enabling memory protection mechanisms such as stack canaries, address space layout randomization (ASLR), non-executable memory, or position-independent executables (PIE), reducing resistance to memory corruption attacks (CWE-693). - topics: - - PIC - - stack canaries - note: PIC cannot be switched off in newer versions of Android, the NDK does not link against such libraries anymore [source](https://cs.android.com/android/platform/superproject/main/+/main:bionic/linker/linker_main.cpp;l=397?q=linker_main&ss=android%2Fplatform%2Fsuperproject%2Fmain). Alternative title could be Memory Anti-Exploitation Mechanisms Not Implemented. -status: placeholder -observed_examples: -- https://nvd.nist.gov/vuln/detail/CVE-2019-3568 ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0007.md b/weaknesses/MASVS-CRYPTO/MASWE-0007.md new file mode 100644 index 00000000..6b9b411f --- /dev/null +++ b/weaknesses/MASVS-CRYPTO/MASWE-0007.md @@ -0,0 +1,54 @@ +--- +title: Improper Cryptographic Key Generation +id: MASWE-0007 +alias: improper-crypto-key-generation +requirement: "The app securely generates cryptographic keys." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0007 +attacks: [MAS-ATTACK-0018, MAS-ATTACK-0019, MAS-ATTACK-0020] +mappings: + masvs-v1: [MSTG-CRYPTO-2] + masvs-v2: [MASVS-CRYPTO-2] + cwe: [331, 326, 337, 338, 522] + android-risks: + - weak-prng + android-core-app-quality: [Cryptographic_Algorithms] + maswe-beta: [MASWE-0009, MASWE-0017] +refs: +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf +- https://developer.android.com/privacy-and-security/cryptography +- https://developer.android.com/reference/javax/crypto/KeyGenerator +- https://developer.android.com/reference/kotlin/android/security/keystore/KeyProtection +- https://developer.apple.com/documentation/cryptokit/aes/keywrap +--- + +## Overview + +This weakness occurs when cryptographic keys are generated with insufficient length, insufficient entropy, or otherwise flawed generation processes, weakening every protection built on top of them. + +In cryptography, security strength is heavily influenced by how keys are generated. One critical aspect is the key size (key length), measured in bits, which must comply with current security best practices: algorithms used with insufficient key sizes are vulnerable to attack. Even with a sufficiently large key size, security can be compromised if the generation process is flawed. Failing to use strong, cryptographically secure pseudorandom number generators (CSPRNGs) with sufficient entropy can produce predictable keys that are easier for attackers to guess or reproduce. + +Mobile platforms provide additional layers of protection for key material, such as generating and storing keys in secure hardware or key attestation. Failing to use these mechanisms where required results in weak key protection. + +## Modes of Introduction + +- **Insufficient Entropy**: Generating keys from a source of randomness with insufficient entropy or from predictable seeds. +- **Insufficient Key Length**: Generating keys shorter than the lengths recommended by current standards for the chosen algorithm. +- **Risky or Broken Algorithms**: Generating keys using deprecated, risky, or inherently broken cryptographic algorithms, which often only support weak key lengths. +- **Insecure Key Export**: Exporting a key in plaintext when it must leave the secure environment in which it was created (for example, to be backed up or shared with another device), instead of "wrapping" it (encrypting it with another key) as specified in [NIST.SP.800-175Br1 5.3.5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf), even when the key is sent over a secure channel. +- **Insecure Key Properties**: Generating keys with properties such as an unspecified or overly broad purpose, insecure storage location (e.g. not using secure hardware if available) or access requirements (see @MASWE-0010). + +## Impact + +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can create valid cryptographic values or impersonate trusted parties, resulting in unauthorized access to protected accounts, data, or functionality. + +## Mitigations + +- **Use Established Cryptographic Libraries**: Always use modern, well-established cryptographic libraries and APIs that follow best practices for entropy generation and key management. +- **Wrap Keys Before Export**: When keys must be exported, protect them with key wrapping (e.g. AES Key Wrap or an equivalent authenticated scheme) so they are never exposed in plaintext outside a secure environment. +- **Use Sufficient Key Lengths**: Ensure that key lengths meet or exceed current standards for cryptographic security, such as 256-bit for AES encryption and 2048-bit for RSA (considering quantum computing attacks). See ["NIST Special Publication 800-57: Recommendation for Key Management: Part 1 – General"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), ["NIST Special Publication 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf), and ["BlueKrypt's Cryptographic Key Length Recommendation"](https://www.keylength.com/) for more information on cryptographic key sizes. +- **Key Attestation**: Use platform key attestation to obtain cryptographic proof that a key was generated and is stored inside secure hardware (e.g. a hardware-backed keystore, TEE, or Secure Element) with the expected properties. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0008.md b/weaknesses/MASVS-CRYPTO/MASWE-0008.md new file mode 100644 index 00000000..fc62b884 --- /dev/null +++ b/weaknesses/MASVS-CRYPTO/MASWE-0008.md @@ -0,0 +1,44 @@ +--- +title: Improper Cryptographic Key Derivation +id: MASWE-0008 +alias: improper-crypto-key-derivation +requirement: "The app derives cryptographic keys using approved key derivation functions." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0008 +attacks: [MAS-ATTACK-0025, MAS-ATTACK-0026] +mappings: + masvs-v1: [MSTG-CRYPTO-2] + masvs-v2: [MASVS-CRYPTO-2] + cwe: [326, 327, 759, 760, 916] + maswe-beta: [MASWE-0010] +refs: +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf +- https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf +- https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html +--- + +## Overview + +This weakness occurs when cryptographic keys are derived from passwords, passphrases, or other low-entropy inputs using a key derivation function (KDF) that is missing, unsuitable, or misconfigured. + +Dedicated password-based KDFs, such as PBKDF2, scrypt, or Argon2, are deliberately expensive to compute and combine the input with a unique random salt, so that each guess costs the attacker significant effort and precomputed tables become useless. When a fast, general-purpose hash is used instead, or when the KDF is configured with a weak work factor or salt, the derived key is far weaker than its nominal length suggests and can be recovered with far less effort than intended. + +## Modes of Introduction + +- **Plain Hash Instead of a KDF**: Deriving keys by applying a fast, general-purpose hash function to a password or passphrase instead of using a dedicated password-based KDF. +- **Insufficient Work Factor**: Configuring the KDF with too few iterations or with memory and parallelism parameters below current recommendations. +- **Missing or Predictable Salt**: Omitting the salt, hardcoding it in the app, or reusing the same salt across users or installations. +- **Low-Entropy Input**: Deriving keys from inputs with insufficient entropy, such as short PINs or predictable device values, without combining them with additional secret material. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can recover passwords or derived credentials, resulting in unauthorized access to protected accounts, data, or functionality. + +## Mitigations + +- **Use a Password-Based KDF**: Derive keys from passwords or passphrases only with a dedicated password-based KDF such as PBKDF2, scrypt, or Argon2, following [NIST.SP.800-132](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf) and the current [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) recommendations. +- **Use an Adequate Work Factor**: Configure iteration counts, memory, and parallelism parameters according to current guidance, and revisit them periodically as hardware improves. +- **Use Unique Random Salts**: Generate a unique salt with a cryptographically secure random number generator for every derivation and store it alongside the derived material; never hardcode or reuse salts. +- **Strengthen Low-Entropy Inputs**: When the input has low entropy (e.g. a PIN), combine the derived key with additional secret material, such as a random key stored in the platform keystore, so the result cannot be brute-forced from the user input alone. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0009.md b/weaknesses/MASVS-CRYPTO/MASWE-0009.md index 4ae3a540..4a808d6d 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0009.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0009.md @@ -1,43 +1,40 @@ --- -title: Improper Cryptographic Key Generation +title: Cryptographic Key Rotation Not Implemented id: MASWE-0009 -alias: weak-crypto-key-generation +alias: no-key-rotation +requirement: "The app rotates cryptographic keys regularly." platform: [android, ios] -profiles: [L1, L2] +profiles: [L2] +threat: MAS-THREAT-0009 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0005] mappings: - masvs-v1: [MSTG-CRYPTO-2] masvs-v2: [MASVS-CRYPTO-2] - cwe: [331, 337, 338] - android-risks: - - https://developer.android.com/privacy-and-security/risks/weak-prng + cwe: [324] + maswe-beta: [MASWE-0011] refs: - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf -- https://developer.android.com/privacy-and-security/cryptography -- https://developer.android.com/reference/javax/crypto/KeyGenerator - -status: new +- https://developers.google.com/tink/managing-key-rotation --- ## Overview -In cryptography, the security strength is heavily influenced by the methods used to generate cryptographic keys. One critical aspect is the key size, also known as the key length, which is measured in bits and must comply with the latest security best practices. Encryption algorithms that use insufficient key sizes are vulnerable to attack, while longer keys typically result in more complex encryption. +This weakness occurs when an app uses cryptographic keys beyond their intended cryptoperiod without rotating them, so that a single key protects an ever-growing amount of data over an unbounded lifetime. -However, even with a sufficiently large key size, the security of the encryption can be compromised if the key generation process is flawed. Failing to use strong, cryptographically secure pseudorandom number generators (CSPRNGs) with sufficient entropy can generate predictable keys that are easier for attackers to guess or reproduce and that are susceptible to repetitive patterns. +Cryptographic keys have a limited cryptoperiod, as defined in [NIST.SP.800-57pt1r5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), after which they should be retired and replaced. Key rotation limits the amount of data protected by any single key and bounds the impact of a key compromise. This is especially important for long-lived symmetric keys and asymmetric key pairs. Rotation must be implemented so that data protected under old keys can still be decrypted or verified, for example via keysets with versioned keys, while new operations use the current key. -## Impact +## Modes of Introduction -- **Risk of Brute-Force Attacks**: Improper key generation, whether due to shorter key length or predictable random number generator (PRNG) inputs, increases the risk of brute-force attacks. Attackers can more easily guess or systematically try possible keys until they find the correct one. -- **Loss of Confidentiality**: Encryption relies on strong keys to maintain the confidentiality of sensitive data. Seed values with insufficient entropy can allow attackers to decrypt and access confidential information, leading to unauthorized disclosure and potential data breaches. -- **Loss of Integrity**: Improper key generation can compromise data integrity, allowing attackers to exploit vulnerabilities and potentially alter or tamper with the information without detection. +- **No Rotation Mechanism**: Designing storage formats or protocols around a single static key, with no key versioning or keyset support that would allow the key to be replaced. +- **Unbounded Cryptoperiods**: Using keys indefinitely without defining a cryptoperiod or expiry after which they must be retired and replaced. +- **Superseded Keys Not Retired**: Keeping old keys active and usable for new operations after rotation, instead of restricting them to decryption or verification of existing data and eventually destroying them. -## Modes of Introduction +## Impact -- **Insufficient Entropy**: Using a source of randomness with insufficient entropy can lead to predictable cryptographic keys. -- **Insufficient Key Length**: Cryptographic keys that are too short provide inadequate security. For example, keys shorter than recommended lengths for modern algorithms may be vulnerable to brute force attacks, making them easier for attackers to break. -- **Using Risky or Broken Algorithms**: Relying on deprecated, risky or inherently broken cryptographic algorithms can result in the generation of weaker keys. As these algorithms often have vulnerabilities or support shorter key lengths, they are more susceptible to modern attacks, compromising the overall security of the app. +- **Compromise of Sensitive Data**: Attackers can decrypt the entire history of data protected with the compromised key, resulting in a much larger disclosure than a rotation-bounded compromise would allow. +- **Authentication or Authorization Bypass**: Attackers can keep forging valid cryptographic values indefinitely with a long-lived compromised key, resulting in persistent unauthorized access that is not curtailed by key expiry. ## Mitigations -- Always use modern, well-established cryptographic libraries and APIs that follow best practices for entropy generation and key management. -- Ensure that key lengths meet or exceed current standards for cryptographic security, such as 256-bit for AES encryption and 2048-bit for RSA (considering quantum computing attacks). See ["NIST Special Publication 800-57: Recommendation for Key Management: Part 1 – General"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) and ["NIST Special Publication 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) and ["BlueKrypt's Cryptographic Key Length Recommendation"](https://www.keylength.com/) for more information on cryptographic key sizes. +- **Define Cryptoperiods**: Assign each key a cryptoperiod appropriate to its type and usage as outlined in [NIST.SP.800-57pt1r5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), and replace keys when it elapses or upon suspicion of compromise. +- **Use Versioned Keysets**: Structure key material as a keyset with key versions (e.g. as implemented by [Tink key rotation](https://developers.google.com/tink/managing-key-rotation)), so that new data is protected with the current key while older data remains readable during migration. +- **Re-Encrypt and Retire Old Keys**: After rotating, re-encrypt or re-protect existing data under the new key where feasible, restrict superseded keys to decryption or verification only, and securely destroy them once they are no longer needed. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0010.md b/weaknesses/MASVS-CRYPTO/MASWE-0010.md index 847c7a3a..209ae5d6 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0010.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0010.md @@ -1,22 +1,50 @@ --- -title: Improper Cryptographic Key Derivation +title: Cryptographic Key Access Not Restricted id: MASWE-0010 -alias: weak-crypto-key-derivation +alias: crypto-key-access-not-restricted +requirement: "The app restricts access to cryptographic keys." platform: [android, ios] -profiles: [L1, L2] +profiles: [L2] +threat: MAS-THREAT-0010 +attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003, MAS-ATTACK-0027] mappings: - masvs-v1: [MSTG-CRYPTO-2] - masvs-v2: [MASVS-CRYPTO-2] - cwe: [326, 327] - + masvs-v2: [MASVS-CRYPTO-2, MASVS-AUTH-2, MASVS-AUTH-3] + cwe: [284, 306] + maswe-beta: [MASWE-0018] refs: -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf -draft: - description: e.g. PBKDF2 with insufficient iterations, lack of salt, etc. - topics: - - sources with insufficient entropy - - lack of salt encryption when doing PBKDF2 -status: placeholder - +- https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setUnlockedDeviceRequired(boolean) +- https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly +- https://developer.android.com/training/sign-in/biometric-auth#prompt-the-user-to-authenticate-with-biometrics +- https://developer.apple.com/documentation/security/restricting-keychain-item-accessibility +- https://developer.android.com/privacy-and-security/keystore#StrongBoxKeyMint +- https://developer.apple.com/documentation/security/ksecattrtokenidsecureenclave --- +## Overview + +This weakness occurs when cryptographic keys can be used without restrictions on who may use them, under which device conditions, and for how long. + +Platform keystores allow developers to bind key usage to strict conditions, such as requiring user authentication, requiring the device to be unlocked, binding the key to the current device, or limiting the validity of an authorization to a short period or a single operation. + +When these restrictions are not configured, any code running as the app, or any actor in possession of the unlocked device, can use the keys freely. This applies even to keys generated inside a hardware security module such as Android StrongBox or the iOS Secure Enclave: hardware backing protects the key material from extraction, but usage restrictions must still be configured explicitly. + +## Modes of Introduction + +- **No User Authentication Requirement**: Creating keys that can be used without requiring the user to authenticate (e.g. with biometrics or device credentials) for each sensitive operation. +- **Usable While the Device Is Locked**: Not restricting key or Keychain item availability to the unlocked device state (e.g. `setUnlockedDeviceRequired` on Android or `kSecAttrAccessibleWhenUnlockedThisDeviceOnly` on iOS). +- **Not Device-Bound**: Allowing key material to migrate to other devices via backups or transfers instead of using device-only protection classes. +- **Unbounded Authorization Validity**: Configuring long authentication validity durations so that a single user authentication authorizes key use indefinitely, rather than for a short window or a single operation. +- **Assuming Hardware Implies Restriction**: Generating keys inside StrongBox or the Secure Enclave without configuring access restrictions, assuming the hardware alone limits who can use the key. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data without ever extracting the key, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can perform signing or authentication operations reserved for the legitimate user, resulting in unauthorized transactions or access to protected functionality. + +## Mitigations + +- **Require User Authentication for Key Use**: Bind keys used for sensitive operations to user authentication, e.g. biometric or device-credential authentication on Android (`setUserAuthenticationRequired`) or Keychain access control flags on iOS, so each use requires the user's presence. +- **Restrict Keys to Unlocked Devices**: Configure keys and Keychain items so they are only available while the device is unlocked (e.g. `setUnlockedDeviceRequired(true)` on Android, `kSecAttrAccessibleWhenUnlockedThisDeviceOnly` on iOS). +- **Bind Keys to the Device**: Use device-only protection classes so key material cannot leave the device via backups or transfers. +- **Limit Authorization Validity**: Keep authentication validity durations short or require authentication per operation, so a single unlock does not authorize unlimited key use. +- **Configure Restrictions Even for Hardware-Backed Keys**: Apply the same user-authentication, unlocked-device, and validity restrictions to keys generated in StrongBox or the Secure Enclave; hardware backing protects against extraction, not against unauthorized use. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0011.md b/weaknesses/MASVS-CRYPTO/MASWE-0011.md index fe485600..89830f06 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0011.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0011.md @@ -1,22 +1,56 @@ --- -title: Cryptographic Key Rotation Not Implemented +title: Improper Encryption id: MASWE-0011 -alias: no-key-rotation +alias: improper-encryption +requirement: "The app properly encrypts sensitive data." platform: [android, ios] -profiles: [L2] +profiles: [L1, L2] +threat: MAS-THREAT-0011 +attacks: [MAS-ATTACK-0018, MAS-ATTACK-0021, MAS-ATTACK-0022, MAS-ATTACK-0023] mappings: - masvs-v2: [MASVS-CRYPTO-2] - cwe: [262, 324] - + masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] + masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] + cwe: [208, 323, 325, 326, 327, 329, 780] + android-risks: + - broken-cryptographic-algorithm + android-core-app-quality: [Cryptographic_Algorithms] + maswe-beta: [MASWE-0020, MASWE-0012, MASWE-0022, MASWE-0023] refs: -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf -- https://developers.google.com/tink/managing-key-rotation -draft: - description: Key rotation is a best practice to limit the impact of a key compromise. - It is especially important for long-lived keys such as asymmetric keys. - topics: - - long-lived keys (cryptoperiods as per NIST.SP.800-57pt1r5) -status: placeholder - +- https://support.google.com/faqs/answer/10046138?hl=en +- https://support.google.com/faqs/answer/9450925?hl=en +- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality +- https://developer.android.com/privacy-and-security/cryptography#pbe-without-iv +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf +- https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf --- +## Overview + +This weakness occurs when encryption is implemented with broken algorithms, insecure modes or parameters, or non-cryptographic techniques, leaving the protected data recoverable or forgeable without the key. + +Encryption is only as strong as its weakest component: the algorithm, the mode of operation, the padding scheme, the initialization vectors (IVs) or nonces, and the way keys are used all contribute to the actual security of the ciphertext. + +## Modes of Introduction + +- **Broken Algorithms**: Relying on broken encryption algorithms (i.e., that are deprecated or disallowed by NIST or other standards) such as RC4, DES, or 3DES. +- **Predictable or Reused Initialization Vectors (IVs)**: Using IVs that are hardcoded, null, predictable, or reused in modes like AES-CBC or AES-CTR, or reusing nonces or using authentication tags of insufficient length in AEAD modes like AES-GCM. +- **Risky Padding**: Using a padding scheme susceptible to padding oracle attacks (e.g. PKCS#7 with unauthenticated AES-CBC, or PKCS#1 v1.5 for RSA) in combination with observable padding-error signals. +- **Broken Modes of Operation**: Using modes that are considered broken. For example, NIST disallows AES-ECB because it is deterministic, meaning identical plaintext blocks yield identical ciphertext blocks, which leaks data patterns. +- **Insufficient Key Length**: Using key sizes below current recommendations for the chosen algorithm. +- **Insecure or Wrong Key Usage**: Reusing a single key for multiple purposes (e.g. encryption and signing) or with an unauthorized algorithm, violating key-separation principles. Per [NIST.SP.800-57pt1r5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), a single key should be used for only one purpose. +- **Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can decipher protected information or alter it without detection, resulting in unauthorized disclosure or manipulation of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can forge ciphertexts, tokens, or signatures accepted by the app or its backend, resulting in unauthorized access to protected accounts, data, or functionality. + +## Mitigations + +- **Use Secure Encryption Modes**: Choose secure, authenticated modes (e.g. approved by NIST) such as `AES/GCM/NoPadding`. If AES-CBC must be used, apply Encrypt-then-MAC (e.g. append HMAC) and, for RSA, prefer OAEP over PKCS#1 v1.5. +- **Ensure Proper Initialization Vector Management**: Generate IVs using cryptographically secure random number generators (with sufficient entropy) and ensure they are unique for every operation; never hardcode, null, or reuse them. On Android, use `GCMParameterSpec` (not the legacy `IvParameterSpec`) for GCM. +- **Use Sufficiently Long Keys**: Enforce sufficiently long keys such as those approved by NIST, e.g., a minimum of 128 bits for AES. +- **Use Each Key for a Single Purpose**: Derive or generate separate keys for encryption, authentication, and signing, and only use each key with its authorized algorithm. +- **Do Not Expose Cryptographic Errors**: Avoid leaking detailed padding or decryption error messages or timing differences that could serve as an oracle. +- **Rely on Proper Cryptographic Primitives**: Rely on well-vetted cryptographic primitives that have undergone rigorous peer review and formal validation. See @MASWE-0015 for signature verification. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0012.md b/weaknesses/MASVS-CRYPTO/MASWE-0012.md index a1d2c7f1..77548a16 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0012.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0012.md @@ -1,24 +1,44 @@ --- -title: Insecure or Wrong Usage of Cryptographic Key +title: Improper Hashing id: MASWE-0012 -alias: insecure-key-usage +alias: improper-hashing +requirement: "The app properly hashes sensitive data." platform: [android, ios] -profiles: [L2] +profiles: [L1, L2] +threat: MAS-THREAT-0012 +attacks: [MAS-ATTACK-0028] mappings: - masvs-v1: [MSTG-CRYPTO-5] - masvs-v2: [MASVS-CRYPTO-2] - cwe: [323] - + masvs-v1: [MSTG-CRYPTO-4] + masvs-v2: [MASVS-CRYPTO-1] + cwe: [328] + android-core-app-quality: [Cryptographic_Algorithms] + maswe-beta: [MASWE-0021] refs: -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf -draft: - description: According to NIST.SP.800-57pt1r5, in general, a single key shall be - used for only one purpose (e.g., encryption, integrity, authentication, key wrapping, - random bit generation, or digital signatures) - topics: - - key used together with an authorized algorithm - - key reuse for different purposes or operations (encrypt, decrypt, sign,...) -status: placeholder - +- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf +- https://en.wikipedia.org/wiki/Collision_attack +- https://csrc.nist.gov/pubs/ir/8547/ipd --- +## Overview + +This weakness occurs when a broken or unsuitable hash function is used in a security-sensitive context, such as integrity checks, digital signatures, or certificate fingerprints. + +Broken algorithms such as MD5 and SHA-1 have practical collision attacks, and NIST has deprecated both for all security purposes; they must not be used in any security-sensitive context. Using an otherwise sound hash function for the wrong job is equally problematic: passwords and passphrases require a dedicated password-based key derivation function rather than a plain hash (see @MASWE-0008), and non-cryptographic checksums provide no security at all. + +## Modes of Introduction + +- **Broken Hash Algorithms**: Using algorithms such as MD5 or SHA-1 in contexts that require collision or second-preimage resistance, e.g. digital signatures, integrity verification, or fingerprinting. +- **Wrong Hash for the Job**: Using a plain, fast hash for password storage or key derivation instead of a password-based KDF (see @MASWE-0008), or using non-cryptographic checksums such as CRC-32 where a cryptographic hash is required. +- **Truncated Digests**: Truncating hash output below the security strength required by the use case, reducing collision and preimage resistance. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can substitute or modify data without invalidating its hash, resulting in undetected manipulation of sensitive information. +- **Authentication or Authorization Bypass**: Attackers can forge artifacts whose authenticity is established via hashes, such as signed payloads or fingerprinted certificates, resulting in impersonation or unauthorized access. + +## Mitigations + +- **Use Approved Hash Functions**: Use hash functions approved by current standards, such as SHA-256 or stronger members of the SHA-2 and SHA-3 families, per [NIST.SP.800-131Ar2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf), and follow emerging post-quantum guidance such as [NIST IR 8547](https://csrc.nist.gov/pubs/ir/8547/ipd). +- **Use Password-Based KDFs for Passwords**: Never hash passwords or passphrases directly; use a dedicated password-based KDF as described in @MASWE-0008. +- **Preserve Digest Length**: Do not truncate digests below the security strength required by the use case. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0013.md b/weaknesses/MASVS-CRYPTO/MASWE-0013.md index 907ab4a7..832047a3 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0013.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0013.md @@ -1,13 +1,52 @@ --- -title: Hardcoded Cryptographic Keys in Use +title: Improper Use of Message Authentication Code (MAC) id: MASWE-0013 -alias: hardcoded-crypto-keys-usage +alias: improper-mac +requirement: "The app properly uses Message Authentication Codes (MACs)." platform: [android, ios] -profiles: [] +profiles: [L1, L2] +threat: MAS-THREAT-0013 +attacks: [MAS-ATTACK-0018, MAS-ATTACK-0021, MAS-ATTACK-0029, MAS-ATTACK-0090] mappings: - masvs-v1: [MSTG-CRYPTO-1] - masvs-v2: [MASVS-CRYPTO-2] -status: deprecated -covered_by: [MASWE-0014] -deprecation_note: Content overlap. + masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] + masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] + cwe: [208, 323, 327, 354, 807] + maswe-beta: [MASWE-0024, MASWE-0012] +refs: +- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf +- https://csrc.nist.gov/pubs/sp/800/224/ipd +- https://datatracker.ietf.org/doc/html/rfc6151 +- https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf +- https://en.wikipedia.org/wiki/Replay_attack --- + +## Overview + +This weakness occurs when a Message Authentication Code (MAC) is missing, built on broken primitives, or used incorrectly in a security-sensitive context, so the integrity and authenticity of messages are no longer guaranteed. + +A MAC provides integrity and authenticity for a message using a shared secret key. These guarantees only hold when the MAC algorithm is sound, the key is strong and used for a single purpose, the tag is long enough, verification does not leak information, and the protocol prevents captured messages from being accepted again. + +## Modes of Introduction + +- **Non-Cryptographic Checksums**: Using checksums such as CRC-32 where a MAC is required; checksums detect accidental corruption but can be trivially recomputed by an attacker. +- **MACs Built on Weak Hashes**: Building MACs on deprecated hash functions such as MD5 or SHA-1, or using naive constructions such as `hash(key ‖ message)` that are vulnerable to length-extension attacks. +- **Weak or Reused MAC Keys**: Using MAC keys with insufficient entropy, or using a MAC key for more than one purpose or with an unauthorized algorithm, violating key-separation principles. +- **Fragile Constructions**: Using constructions that fail outside narrow assumptions, such as raw CBC-MAC on variable-length messages, or composing encryption and authentication incorrectly (e.g. MAC-then-encrypt where encrypt-then-MAC is required). +- **Truncated Tags**: Using authentication tags that are too short, significantly lowering the effort required for forgery. +- **Missing Replay Protection**: Authenticating messages without a timestamp, nonce, or sequence number, so previously captured valid messages remain acceptable. +- **Observable Verification Failures**: Exposing timing differences or detailed error messages during MAC verification that can serve as an oracle. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can modify protected messages or stored data without detection, resulting in undetected manipulation of sensitive information. +- **Authentication or Authorization Bypass**: Attackers can forge or replay authenticated messages, such as commands or transactions, resulting in unauthorized actions being executed on behalf of the user. + +## Mitigations + +- **Use Standard MAC Algorithms**: Use HMAC with an approved hash function (SHA-256 or stronger) or an approved authenticated mode, following [NIST SP 800-224](https://csrc.nist.gov/pubs/sp/800/224/ipd) and [NIST.SP.800-131Ar2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf); never use non-cryptographic checksums for security purposes. +- **Use Strong, Single-Purpose Keys**: Generate MAC keys with a cryptographically secure random number generator and use each key for only one purpose and algorithm. +- **Prefer AEAD or Encrypt-then-MAC**: When combining encryption and authentication, use an AEAD mode (e.g. AES-GCM) or the encrypt-then-MAC composition. +- **Use Full-Length Tags**: Do not truncate authentication tags below the length required by the security level of the use case. +- **Add Replay Protection**: Include and verify a timestamp, nonce, or sequence number in authenticated messages so captured messages cannot be replayed. +- **Verify in Constant Time**: Compare tags using constant-time comparison and return uniform errors so verification cannot be used as an oracle. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0014.md b/weaknesses/MASVS-CRYPTO/MASWE-0014.md index 1440d848..d482b28b 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0014.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0014.md @@ -1,43 +1,45 @@ --- -title: Cryptographic Keys Not Properly Protected at Rest +title: Improper Generation of Cryptographic Signatures id: MASWE-0014 -alias: crypto-keys-not-protected-at-rest +alias: improper-signature-generation +requirement: "The app properly generates cryptographic signatures." platform: [android, ios] profiles: [L1, L2] +threat: MAS-THREAT-0014 +attacks: [MAS-ATTACK-0018, MAS-ATTACK-0021, MAS-ATTACK-0030] mappings: - masvs-v1: [MSTG-STORAGE-1] - masvs-v2: [MASVS-CRYPTO-2, MASVS-STORAGE-1] - cwe: [312, 318, 321] - android-risks: - - https://developer.android.com/privacy-and-security/risks/hardcoded-cryptographic-secrets + masvs-v1: [MSTG-CRYPTO-4, MSTG-CRYPTO-5] + masvs-v2: [MASVS-CRYPTO-1, MASVS-CRYPTO-2] + cwe: [323, 326, 327, 330] + maswe-beta: [MASWE-0025, MASWE-0012] refs: -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf -status: new +- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf +- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf +- https://csrc.nist.gov/pubs/ir/8547/ipd --- ## Overview -Cryptographic keys are essential for securing sensitive data in mobile applications. However, if these keys are not properly protected at rest, they can be easily compromised. This weakness involves storing cryptographic keys in insecure locations, such as unencrypted SharedPreferences, unprotected files, hardcoding them within the application code, or including them in source control and versioning systems which may end in the final application package in production. +This weakness occurs when cryptographic signatures are generated with weak algorithms, insufficient parameters, or flawed randomness, undermining the integrity and authenticity guarantees they are meant to provide. -Attackers can decompile or reverse-engineer the app to extract hardcoded keys. +Signatures are only as strong as the scheme and parameters behind them: deprecated combinations such as SHA1withRSA, keys that are too short, and signing keys reused for other purposes all weaken the guarantee. In addition, the randomness used during signing is critical: in (EC)DSA, a predictable or reused per-signature nonce allows the private key itself to be recovered from observed signatures. -## Impact +## Modes of Introduction -- **Unauthorized Access**: If cryptographic keys are not properly protected, attackers may gain unauthorized access to sensitive data and potential identity theft. -- **Loss of Integrity**: Compromised keys can allow attackers to tamper with encrypted data. -- **Loss of Confidentiality**: Sensitive information can be exposed, resulting in a loss of confidentiality. Once keys are exposed, all data encrypted with those keys is at risk. +- **Weak or Deprecated Signature Algorithms**: Generating signatures with deprecated schemes or digest combinations, such as SHA1withRSA. +- **Insufficient Key Length**: Using signing keys shorter than the lengths recommended by current standards for the chosen algorithm. +- **Predictable Signature Nonces**: Generating the per-signature nonce in (EC)DSA with insufficient entropy, or reusing it across signatures. +- **Key Reuse Across Purposes**: Using a signing key for other purposes, such as encryption or key agreement, violating key-separation principles. -## Modes of Introduction +## Impact -- **Insecure Storage Locations**: Storing cryptographic keys in locations that are not designed for secure storage, such as regular configuration or user preferences files, application data directories, or other areas lacking encryption and access control mechanisms. -- **Hardcoded Keys**: Including cryptographic keys directly in the application code, making them susceptible to extraction through decompilation and reverse-engineering. -- **Lack of Encryption**: Exporting cryptographic keys in plain text without encrypting them using a secure method. +- **Authentication or Authorization Bypass**: Attackers can sign arbitrary data as the app or user, resulting in impersonation and unauthorized transactions or API calls accepted by peers that trust the signature. +- **Compromise of Sensitive Data**: Attackers can tamper with signed data while producing valid signatures for it, resulting in undetected manipulation of information whose integrity depends on the signature. ## Mitigations -- **Use Platform Keystores**: Where possible, generate cryptographic keys dynamically on the device, rather than using predefined keys, and ensure that they are securely stored after creation. For this you can use the platform-specific keystores, such as the [Android KeyStore](https://developer.android.com/training/articles/keystore) or [iOS KeyChain](https://developer.apple.com/documentation/security/keychain_services). -- **Implement Strongest Hardware Security Solutions**: For the most critical cases and whenever [available and compatible](https://developer.android.com/privacy-and-security/keystore#HardwareSecurityModule) for the use case at hand, leverage the strongest hardware-backed security options such as [Android StrongBox](https://source.android.com/docs/security/features/keystore/strongbox) or iOS's Secure Enclave [`kSecAttrTokenIDSecureEnclave`](https://developer.apple.com/documentation/security/ksecattrtokenidsecureenclave) option to ensure the highest protection including physical and side-channel attacks. -- **Use Cryptographic Key Management Systems**: Securely retrieve keys from server-side services that provide secure storage, access control, and auditing for sensitive data. For example, AWS Secrets Manager, Azure Key Vault, or Google Cloud Secret Manager are some popular managed secrets storage solutions. The app can securely retrieve the necessary secrets at runtime through secure, authenticated API calls. -- **Encrypt and Wrap Keys**: Whenever storing keys in platform keystores is not suitable for the use case or keys need to be exported, use envelope encryption (DEK+KEK) and key wrapping techniques as specified in [NIST.SP.800-175Br1 5.3.5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf) to protect cryptographic keys before storing them. -- **Follow Standard Key Management Best Practices**: Implement proper key management practices, including key rotation and robust protection mechanisms for keys in storage as outlined in [NIST.SP.800-57pt1r5 6.2.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), ensuring availability, integrity, confidentiality, and proper association with usage, entities, and related information. +- **Use Approved Signature Schemes**: Generate signatures with schemes approved in [NIST FIPS 186-5](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf), such as ECDSA, RSA-PSS, or EdDSA, with approved digests, and follow post-quantum migration guidance such as [NIST IR 8547](https://csrc.nist.gov/pubs/ir/8547/ipd). +- **Use Sufficient Key Lengths**: Ensure signing keys meet or exceed the lengths recommended by [NIST.SP.800-131Ar2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) for the chosen algorithm. +- **Ensure Nonce Uniqueness**: Generate (EC)DSA per-signature nonces with a cryptographically secure random number generator, or use deterministic schemes (e.g. RFC 6979 deterministic ECDSA or Ed25519) that eliminate nonce misuse. +- **Use Signing Keys for a Single Purpose**: Keep signing keys dedicated to signing and generate separate keys for other operations. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0015.md b/weaknesses/MASVS-CRYPTO/MASWE-0015.md index 0ac41a7f..dfb34fce 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0015.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0015.md @@ -1,23 +1,43 @@ --- -title: Deprecated Android KeyStore Implementations +title: Improper Verification of Cryptographic Signature id: MASWE-0015 -alias: deprecated-keystore -platform: [android] -profiles: [L2] +alias: improper-signature-verification +requirement: "The app properly verifies cryptographic signatures." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0015 +attacks: [MAS-ATTACK-0031] mappings: masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-2, MASVS-CODE-3] - cwe: [327, 477, 522] - + masvs-v2: [MASVS-CRYPTO-1] + cwe: [295, 347] + maswe-beta: [MASWE-0026] refs: -- https://labs.withsecure.com/publications/how-secure-is-your-android-keystore-authentication -- https://developer.android.com/reference/java/security/KeyStore -- https://developer.android.com/about/versions/12/behavior-changes-all#bouncy-castle -draft: - description: Avoid deprecated implementations such as BKS - topics: - - Bouncy Castle (BKS) -status: placeholder - +- https://cwe.mitre.org/data/definitions/347.html +- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf --- +## Overview + +This weakness occurs when an app fails to verify cryptographic signatures correctly, accepting forged or tampered data as authentic. + +Signature verification protects the integrity and authenticity of data such as updates, configuration, licenses, or tokens. The guarantee breaks down when verification is skipped, when its result is ignored, when the signer's key is not validated against a trusted identity, or when the app lets the attacker influence which algorithm or key is used for verification. + +## Modes of Introduction + +- **Verification Skipped or Result Ignored**: Not verifying signatures on security-relevant data, or computing the verification but proceeding regardless of its result. +- **Untrusted or Unpinned Signer Keys**: Accepting signatures without validating the signer's key against a trusted set or certificate chain, or verifying against public keys that ship alongside the data and can be replaced by an attacker. +- **Algorithm Confusion**: Accepting the algorithm declared by the data being verified (e.g. a token header), including weak, deprecated, or "none" algorithms, instead of enforcing the expected one. + +## Impact + +- **Execution of Unauthorized Code**: Attackers can deliver tampered updates, plugins, or configuration that the app accepts as genuine, resulting in attacker-controlled code or behavior running within the app. +- **Authentication or Authorization Bypass**: Attackers can forge signed tokens or assertions (e.g. session or license tokens), resulting in unauthorized access to protected accounts, data, or functionality. +- **Compromise of Sensitive Data**: Attackers can substitute tampered data for authentic data without detection, resulting in the app processing or displaying manipulated information. + +## Mitigations + +- **Always Verify and Check the Result**: Verify signatures on all security-relevant data and treat any verification failure as fatal for the operation; never proceed on an ignored or swallowed result. +- **Validate the Signer's Identity**: Verify signatures only against keys anchored in a trusted set, such as pinned keys or a validated certificate chain, and never against keys delivered alongside the data itself. +- **Enforce the Expected Algorithm**: Allow-list the exact signature algorithms the app expects and reject anything else, including "none" or algorithms chosen by the data being verified. +- **Use Approved Schemes**: Verify with signature schemes approved in [NIST FIPS 186-5](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf) and reject weak or deprecated ones. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0016.md b/weaknesses/MASVS-CRYPTO/MASWE-0016.md index a81a5cae..ea7aaa1d 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0016.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0016.md @@ -1,26 +1,44 @@ --- -title: Unsafe Handling of Imported Cryptographic Keys +title: Improper Random Number Generation id: MASWE-0016 -alias: unsafe-imported-key-handling +alias: improper-random-number-generation +requirement: "The app properly generates random numbers." platform: [android, ios] -profiles: [L2] +profiles: [L1, L2] +threat: MAS-THREAT-0016 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0019, MAS-ATTACK-0024] mappings: - masvs-v2: [MASVS-CRYPTO-2, MASVS-CODE-4] - cwe: [322] - + masvs-v1: [MSTG-CRYPTO-6] + masvs-v2: [MASVS-CRYPTO-1] + cwe: [332, 337, 338] + android-risks: + - weak-prng + android-core-app-quality: [Cryptographic_Algorithms] + maswe-beta: [MASWE-0027] refs: -- https://mas.owasp.org/MASTG/0x05d-Testing-Data-Storage/#secure-key-import-into-keystore -- https://developer.android.com/privacy-and-security/keystore#ImportingEncryptedKeys -- https://developer.android.com/reference/kotlin/android/security/keystore/KeyProtection -- https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_as_data#2933724 -draft: - description: Importing keys without validating their origin or integrity, or using - insecure custom key exchange protocols, can inadvertently introduce malicious - or compromised keys into the app environment. - topics: - - key import from untrusted sources - - key import from untrusted storage -status: placeholder - +- https://datatracker.ietf.org/doc/html/rfc4086 +- https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation --- +## Overview + +This weakness occurs when random values used in a security context are produced by a non-cryptographic pseudorandom number generator (PRNG) or derived from predictable seeds. + +A [PRNG](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) generates sequences deterministically from a seed. Common implementations are not cryptographically secure; for example, they typically use a linear congruential formula whose future outputs can be predicted after observing enough previous outputs. Such generators are not suitable for security-critical purposes like generating session tokens, one-time passwords, or cryptographic key material. + +## Modes of Introduction + +- **Risky Random APIs**: Using general-purpose random APIs, which do not provide cryptographically secure output, in security-relevant contexts. +- **Non-Random Sources**: Using custom methods to create "supposedly random" values from non-random sources such as the current time. +- **Hardcoded or Predictable Seeds**: Seeding a generator deterministically, e.g. with a hardcoded seed value shipped in the app. + +## Impact + +- **Authentication or Authorization Bypass**: Attackers can predict session tokens, one-time passwords, or password-reset codes, resulting in unauthorized access to user accounts or privileged functionality. +- **Compromise of Sensitive Data**: Attackers can reproduce cryptographic material derived from predictable values and decrypt protected information, resulting in unauthorized disclosure of sensitive data. + +## Mitigations + +- **Use Cryptographically Secure RNGs**: For security-relevant contexts, always generate random values with a cryptographically secure random number generator provided by the platform. +- **Avoid Deterministic Seeding**: Do not use any random function in a deterministic way, even a secure one, and especially avoid hardcoded seed values, which can be recovered by decompiling the app. +- **Follow Established Guidance**: Refer to [RFC 4086 - Randomness Requirements for Security](https://datatracker.ietf.org/doc/html/rfc4086) and the [OWASP Cryptographic Storage Cheat Sheet - Secure Random Number Generation](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation) for recommendations on random number generation. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0017.md b/weaknesses/MASVS-CRYPTO/MASWE-0017.md deleted file mode 100644 index 1cef7d01..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0017.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Cryptographic Keys Not Properly Protected on Export -id: MASWE-0017 -alias: crypto-keys-not-protected-export -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CRYPTO-2, MASVS-STORAGE-1, MASVS-NETWORK-1] - cwe: [522] - -refs: -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf -- https://developer.android.com/reference/kotlin/android/security/keystore/KeyProtection -- https://developer.apple.com/documentation/cryptokit/aes/keywrap -- https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_as_data#2933723 -draft: - description: Before exporting, keys should be "wrapped" or encrypted with another - key. This process ensures that the cryptographic key is protected during and after - export. This is true even if the key is sent over a secure channel. - topics: - - key wrapping (NIST.SP.800-175Br1 5.3.5) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0018.md b/weaknesses/MASVS-CRYPTO/MASWE-0018.md deleted file mode 100644 index 6375f126..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0018.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Cryptographic Keys Access Not Restricted -id: MASWE-0018 -alias: crypto-key-access-not-restricted -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-CRYPTO-2, MASVS-AUTH-2, MASVS-AUTH-3] - cwe: [284] - -refs: -- https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder#setUnlockedDeviceRequired(boolean) -- https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly -- https://developer.android.com/training/sign-in/biometric-auth#prompt-the-user-to-authenticate-with-biometrics -- https://developer.apple.com/documentation/security/restricting-keychain-item-accessibility -draft: - description: Ensuring that cryptographic keys are accessible only under strict conditions, - such as when the device is unlocked by an authenticated user, within secure application - contexts, bound to the current device, or for limited periods of time, is critical to maintaining the confidentiality - and integrity of encrypted data. - topics: - - from a Background Process - - locked device (iOS kSecAttrAccessibleWhenUnlockedThisDeviceOnly, Android setUnlockedDeviceRequired) - - device-bound or non-transferable (iOS ThisDeviceOnly) - - time-based access (duration) - - Require User Presence - - application-specific password - - biometric authentication - - key use restricted e.g. requiring user auth with biometrics, User Presence. - - especially for sensitive operations - - keys restricted/authorized for a duration of time or specific crypto operation, - etc. -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0019.md b/weaknesses/MASVS-CRYPTO/MASWE-0019.md deleted file mode 100644 index 31628cb4..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0019.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Risky Cryptography Implementations -id: MASWE-0019 -alias: potentially-weak-crypto-impl -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-CRYPTO-2] - masvs-v2: [MASVS-CRYPTO-1, MASVS-CODE-3] - mastg-v1: [MASTG-TEST-0061, MASTG-TEST-0014] - cwe: [326, 327, 1240] - -refs: - - https://book.hacktricks.xyz/crypto-and-stego/cryptographic-algorithms - - https://eudl.eu/pdf/10.4108/eai.3-12-2015.2262471 - - https://www.scitepress.org/papers/2014/50563/50563.pdf - - https://pure.tugraz.at/ws/portalfiles/portal/23858147/main.pdf - - https://github.com/Wind-River/crypto-detector - - https://github.com/Rami114/cryptoscan/ - - https://github.com/IAIK/CryptoSlice - - https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String) - - https://developer.android.com/privacy-and-security/security-gms-provider - - https://developer.android.com/privacy-and-security/cryptography#bc-algorithms - - https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library - - https://developer.android.com/privacy-and-security/cryptography#crypto_provider - - https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality - - https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile ---- - -## Overview - -Risky or noncompliant cryptographic implementations, such as those that do not meet established security standards such as FIPS 140-2/3 (Federal Information Processing Standards), may use algorithms that have not been sufficiently tested or that lack certification, may not follow best practices for secure key management, or may include custom cryptographic solutions that haven't undergone rigorous peer review or formal validation. - -## Impact - -Custom cryptographic implementations created without following established standards make them more susceptible to attacks such as brute force or differential cryptanalysis. In addition, cryptography is notoriously difficult to implement correctly, and even small errors in a custom solution, such as incorrect padding or faulty random number generation, can completely undermine the security of the system, exposing sensitive data to attackers. - -The impact associated with such defects can be very broad and difficult to predict or measure: - -- **Data breaches**: Risky cryptography implementations can lead to unauthorized access to sensitive data, resulting in data breaches. -- **Compromised confidentiality, integrity, and authenticity**: The core principles of cryptography (confidentiality, integrity, and authenticity) are compromised. Attackers can decrypt, manipulate, or impersonate legitimate users or systems. - -## Modes of Introduction - -- **Deviation from standard libraries**: Not using well-known libraries for cryptography, such as those provided by the platforms like Conscrypt or CryptoKit, or other well-established libraries like OpenSSL, BouncyCastle, etc. -- **Use of cryptographic constants**: Hardcoded cryptographic constants are typically used to implement cryptographic algorithms. These constants include S-boxes (substitution boxes) for block ciphers, permutation tables, etc. -- **Use of low-level mathematical operations**: Low-level mathematical operations (such as bitwise operations, shifts, custom padding schemes) typically used in cryptographic algorithms. -- **High entropy code**: An indicator of cryptographic implementations or heavily obfuscated code that may hide cryptographic algorithms from reverse engineering. -- **Use of non-cryptographic functions**: Non-cryptographic functions such as Base64 encoding or XOR instead of encryption. - -## Mitigations - -- **Use standard cryptographic libraries and avoid custom cryptography**: Avoid developing custom cryptographic algorithms or protocols. Always prefer well-established and widely accepted cryptographic libraries such as OpenSSL, BoringSSL, or platform-specific libraries such as Android's Conscrypt and Apple's CryptoKit. These libraries have undergone extensive testing and are regularly updated to address new security threats. - -- **Ensure compliance with security standards**: If you can't avoid using custom cryptography, make sure it's implemented to meet industry standards such as FIPS 140-2/3 (Federal Information Processing Standards) or the latest National Institute of Standards and Technology (NIST) recommendations. -- **Perform periodic security audits**: If using custom cryptography is unavoidable, perform regular security audits (including thorough code reviews) to identify and remediate any flaws in your custom cryptographic implementations. Engage external security experts to provide an unbiased assessment. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0020.md b/weaknesses/MASVS-CRYPTO/MASWE-0020.md deleted file mode 100644 index 81cbb8f5..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0020.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Improper Encryption -id: MASWE-0020 -alias: weak-encryption -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [326] - -refs: -- https://support.google.com/faqs/answer/10046138?hl=en -- https://support.google.com/faqs/answer/9450925?hl=en -- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf - -status: new - ---- - -## Overview - -Improper encryption refers to cryptographic systems or implementations that are vulnerable to attack, allowing unauthorized individuals to decrypt secured data. - -## Impact - -- **Loss of Confidentiality**: Improper encryption may enable attackers to decipher and obtain sensitive information, resulting in unauthorized exposure and possible data breaches. -- **Loss of Integrity**: Improper encryption can compromise the integrity of data, allowing adversaries to alter or manipulate the information without detection. - -## Mode of Introduction - -- **Broken Algorithms**: Relying on broken encryption algorithms (i.e., that are deprecated or disallowed by NIST or other standards) such as RC4. -- **Risky Algorithm Configurations**: Using IVs with insufficient entropy or reusing them in modes like AES-CBC or AES-CTR breaks semantic security, allowing attackers to detect patterns or recover plaintext differences. In AEAD modes like AES-GCM, reusing nonces or using authentication tags of insufficient length compromises both confidentiality and integrity. -- **Broken Modes of Operation**: Using modes that are considered broken. For example, AES-ECB is broken due to practical known-plaintext attacks and it's disallowed by NIST. -- **Insufficient Key Length**: The use of insufficient key sizes (e.g., 128-bit keys in AES) can compromise encryption strength making the encryption susceptible to brute-force attacks. -- **Non-Cryptographic Operations**: Relying on techniques such as XOR, Base64 encoding, or simple obfuscation methods for security purposes. These methods provide no actual encryption and can be easily reversed or decoded, exposing sensitive data. - -## Mitigations - -- **Use Secure Encryption Modes**: Choose secure modes (e.g. approved by NIST) such as `AES/GCM/NoPadding`. -- **Ensure Proper Initialization Vector Management**: Generate IVs using cryptographically secure random number generators (with sufficient entropy) and ensure they are unique for every operation. -- **Use Sufficiently Long Keys**: Enforce sufficiently long keys such as those approved by NIST, e.g., a minimum of 256 bits for AES. -- **Rely on Proper Cryptographic Primitives**: Rely on well-vetted cryptographic primitives that have undergone rigorous peer review and formal validation. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0021.md b/weaknesses/MASVS-CRYPTO/MASWE-0021.md deleted file mode 100644 index 4d19d105..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0021.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Improper Hashing -id: MASWE-0021 -alias: improper-hashing -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [328] - -refs: -- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf -- https://en.wikipedia.org/wiki/Collision_attack -- https://csrc.nist.gov/pubs/ir/8547/ipd -draft: - description: Utilizing broken hashing algorithms such as MD5 and SHA1 in a security - sensitive context may compromise data integrity and authenticity. - topics: - - Broken hashing algorithms (e.g. MD5, SHA1, etc.) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0022.md b/weaknesses/MASVS-CRYPTO/MASWE-0022.md deleted file mode 100644 index 7ad15f6a..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0022.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Predictable Initialization Vectors (IVs) -id: MASWE-0022 -alias: predictable-ivs -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [329] - -refs: -- https://developer.android.com/privacy-and-security/cryptography#pbe-without-iv -draft: - description: The use of predictable IVs (hardcoded, null, reused) in a security - sensitive context can weaken data encryption strength and potentially compromise - confidentiality. - topics: - - not use the IvParameterSpec.class anymore for GCM, use the GCMParameterSpec.class - instead (Android) - - Hardcoded IVs - - Null IVs - - Reused IVs -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0023.md b/weaknesses/MASVS-CRYPTO/MASWE-0023.md deleted file mode 100644 index 24d09b72..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0023.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Risky Padding -id: MASWE-0023 -alias: risky-padding -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - mastg-v1: [MASTG-TEST-0014] - cwe: [208, 325, 327, 780] - -refs: -- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf -- https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile -- https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf -- https://capec.mitre.org/data/definitions/463.html -- https://robertheaton.com/2013/07/29/padding-oracle-attack/ -- https://cryptopals.com/sets/3/challenges/17 -- https://medium.com/@masjadaan/oracle-padding-attack-a61369993c86 -status: new ---- - -## Overview - -[Padding oracle attacks](https://www.usenix.org/legacy/event/woot10/tech/full_papers/Rizzo.pdf) are a type of side-channel exploit that lets attackers decrypt or manipulate data **without** knowing the key. These attacks aren't due to the padding scheme bring broken itself, they arise when the app reveals whether a padding error occurred (through error messages or timing differences), creating an **oracle**. By submitting modified ciphertexts and observing the app's response, an attacker can gradually recover plaintext or forge ciphertext, compromising both confidentiality and integrity. - -Below are two common examples of cryptographic contexts where risky padding can become a problem: - -- **Symmetric Cryptography**: In block cipher modes (e.g., AES-CBC), **PKCS#7 padding** is widely used and it's not broken (not disallowed by NIST). However, it becomes vulnerable to padding oracle attacks if the system leaks detailed error messages or timing differences. To mitigate this, cryptographers often use **authenticated encryption modes** like AES-GCM or pair AES-CBC with a separate integrity check (e.g., HMAC in an Encrypt-then-MAC scheme). -- **Asymmetric Cryptography**: With RSA, **PKCS#1 v1.5** is known to be susceptible to attacks such as [Bleichenbacher](https://link.springer.com/content/pdf/10.1007/BFb0055716.pdf) (based on padding oracles). This older scheme is now discouraged or disallowed by various standards (for example, see [RFC 8017, Section 7.2](https://datatracker.ietf.org/doc/html/rfc8017#section-7.2) from November 2016 or [NIST SP 800-131A Rev.2, Section 6](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) from March 2019). - -However, simply using a padding scheme susceptible to padding oracle attacks does not guarantee a vulnerability. As mentioned above, the app must **also** leak information (the "oracle") that indicates whether a padding error has occurred. If both conditions are met, attackers can use these signals to recover sensitive data or to craft malicious ciphertext. - -## Impact - -- **Loss of Integrity**: Attackers can modify ciphertext, exploiting the padding oracle to trick the system into accepting maliciously altered data, leading to unauthorized data modifications. -- **Loss of Confidentiality**: Attackers can use the padding oracle to iteratively decrypt sensitive information, such as passwords or session tokens, leading to exposure of confidential data. - -## Modes of Introduction - -- **Unauthenticated Padding for Symmetric Encryption**: Using padding schemes like PKCS#7 without authenticating the ciphertext (e.g., with HMAC) allows padding oracle attacks in modes like AES-CBC. -- **Risky Padding in Asymmetric Encryption**: Using schemes like PKCS#1 v1.5 for RSA encryption without strict, uniform handling of invalid ciphertext enables oracle attacks. -- **Exposure of Cryptographic Errors**: Revealing detailed error messages or timing variations during decryption can leak information exploitable by attackers. - -## Mitigations - -- **Use Authenticated Symmetric Encryption Modes**: Prefer authenticated encryption modes like AES-GCM, which eliminate the need for separate padding validation and incorporate integrity checks. If AES-CBC must be used, adopt the Encrypt-then-MAC paradigm (e.g., append HMAC). See [NIST SP 800-175B Rev.1, Section 4.3](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf). -- **Use Secure Padding Schemes for Asymmetric Encryption**: Replace risky schemes like PKCS#1 v1.5 with secure ones such as OAEP (Optimal Asymmetric Encryption Padding). See [NIST SP 800-56B Rev.2, Section 7.2.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf). -- **Don't Expose Cryptographic Errors**: Do not expose cryptographic error messages, such as padding errors, to users. This prevents attackers from gaining clues about the padding's correctness. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md deleted file mode 100644 index c0d5c0af..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Improper Use of Message Authentication Code (MAC) -id: MASWE-0024 -alias: improper-mac -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [327, 807, 915] - -refs: -- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf -- https://csrc.nist.gov/pubs/sp/800/224/ipd -- https://datatracker.ietf.org/doc/html/rfc6151 -- https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf -- https://en.wikipedia.org/wiki/Replay_attack -draft: - description: Improper use of MACs in security sensitive contexts affecting data integrity. - topics: - - Using HMAC with keys with insufficient entropy - - Using HMAC with missing timestamp (or nonce) - - Using MAC‑then‑encrypt or encrypt‑then‑MAC incorrectly, leaking information via timing or error messages - - Allowing predictors (users or attackers) to control data inputs, creating scenarios where forged or replayed tags bypass integrity checks. - - Hash functions lacking collision resistance (e.g., MD5 or SHA‑1 used in HMAC) - - Use of non‑cryptographic checksums (e.g., CRC‑32 instead of HMAC) - - MAC constructions that fail outside narrow assumptions (e.g., raw CBC‑MAC on variable‑length messages) - - Tags that are too short significantly lower the effort required for forgery -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0025.md b/weaknesses/MASVS-CRYPTO/MASWE-0025.md deleted file mode 100644 index f1df81e7..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0025.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Improper Generation of Cryptographic Signatures -id: MASWE-0025 -alias: improper-signature-generation -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [327] - -refs: -- https://developer.android.com/privacy-and-security/cryptography#deprecated-functionality -- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf -- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf -- https://csrc.nist.gov/pubs/ir/8547/ipd -draft: - description: The use of algorithms with insufficient strength for signatures such as SHA1withRSA, etc. in a security-sensitive context should be avoided to ensure the integrity and authenticity of the data. - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0026.md b/weaknesses/MASVS-CRYPTO/MASWE-0026.md deleted file mode 100644 index 87ec399d..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0026.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Improper Verification of Cryptographic Signature -id: MASWE-0026 -alias: improper-signature-verification -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-CRYPTO-4] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [347] - -refs: -- https://cwe.mitre.org/data/definitions/347.html -- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf -draft: - description: Cryptographic signature verification should be performed properly to - ensure the integrity and authenticity of the data. - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0027.md b/weaknesses/MASVS-CRYPTO/MASWE-0027.md deleted file mode 100644 index 47203c29..00000000 --- a/weaknesses/MASVS-CRYPTO/MASWE-0027.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Improper Random Number Generation -id: MASWE-0027 -alias: improper-random-number-generation -platform: ["android", "ios"] -profiles: ["L1", "L2"] -mappings: - masvs-v1: [MSTG-CRYPTO-6] - masvs-v2: [MASVS-CRYPTO-1] - cwe: [332, 337, 338] - android-risks: - - https://developer.android.com/privacy-and-security/risks/weak-prng -observed_examples: -- https://nvd.nist.gov/vuln/detail/CVE-2013-6386 -- https://nvd.nist.gov/vuln/detail/CVE-2013-6386 -- https://nvd.nist.gov/vuln/detail/CVE-2006-3419 -- https://nvd.nist.gov/vuln/detail/CVE-2008-4102 -- https://www.zellic.io/blog/proton-dart-flutter-csprng-prng/ -status: new ---- - -## Overview - -A [pseudorandom number generator (PRNG)](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) algorithm generates sequences based on a seed with insufficient entropy that may be predictable. Common implementations are not cryptographically secure. For example, they typically use a linear congruential formula, allowing an attacker to predict future outputs, given enough observed outputs. Therefore, it is not suitable for security-critical applications or protecting sensitive data. - -## Impact - -- **Bypass Protection Mechanism**: Using a non-cryptographically secure PRNG in a security context, such as authentication, poses significant risks. An attacker could potentially guess the generated numbers and gain access to privileged data or functionality. Predicting or regenerating random numbers can lead to encryption breaches, compromise sensitive user information, or enable user impersonation. - -## Modes of Introduction - -- **Risky Random APIs**: The app may use many existing APIs to generate random numbers with insufficient entropy. -- **Non-random Sources**: The app may use custom methods to create "supposedly random" values, using non-random sources such as the current time. - -## Mitigations - -For security-relevant contexts, use cryptographically secure random numbers. - -In general, it is strongly recommended not to use any random function in a deterministic way, even if it's a secure one, especially those involving hardcoded seed values (which are vulnerable to exposure by decompilation). - -Refer to the [RFC 1750 - Randomness Recommendations for Security](https://www.ietf.org/rfc/rfc1750.txt) and the [OWASP Cryptographic Storage Cheat Sheet - Secure Random Number Generation](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#secure-random-number-generation) for more information and recommendations on random number generation. diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0049.md b/weaknesses/MASVS-CRYPTO/MASWE-0049.md new file mode 100644 index 00000000..c24af3ba --- /dev/null +++ b/weaknesses/MASVS-CRYPTO/MASWE-0049.md @@ -0,0 +1,42 @@ +--- +title: Device Secure Lock Not Enforced +id: MASWE-0049 +alias: device-secure-lock-not-enforced +requirement: "The app verifies that the device has a secure lock configured." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0049 +attacks: [MAS-ATTACK-0063] +mappings: + masvs-v1: [MSTG-STORAGE-11] + masvs-v2: [MASVS-CRYPTO-2] + maswe-beta: [MASWE-0008] +refs: +- https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id +- https://developer.apple.com/documentation/localauthentication/lacontext/canevaluatepolicy(_:error:) +- https://developer.android.com/reference/android/app/KeyguardManager#isDeviceSecure() +- https://developer.android.com/reference/android/hardware/biometrics/BiometricManager#canAuthenticate(int) +--- + +## Overview + +This weakness occurs when an app enables sensitive functionality without verifying that the device has a secure lock screen (passcode, PIN, pattern, or biometric) configured. Without a secure lock screen, cryptographic material cannot be protected with the highest level of security, and sensitive data may be exposed to anyone with physical access to the device. + +Many of the platform's data-protection mechanisms assume a device credential exists: on iOS, file encryption classes tied to the passcode only protect data if a passcode is set, and on Android, keystore protections such as unlocked-device requirements are meaningless on a device with no lock. + +## Modes of Introduction + +- **No Secure-Lock Check**: Enabling sensitive features without verifying the device lock state, e.g., [`KeyguardManager.isDeviceSecure()`](https://developer.android.com/reference/android/app/KeyguardManager#isDeviceSecure()) on Android or [`LAContext.canEvaluatePolicy(_:error:)`](https://developer.apple.com/documentation/localauthentication/lacontext/canevaluatepolicy%28_%3Aerror%3A%29) on iOS. +- **Data Protection Not Tied to the Passcode**: Storing sensitive items on iOS without passcode-dependent protection classes (e.g. [`kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly`](https://developer.apple.com/documentation/security/ksecattraccessiblewhenpasscodesetthisdeviceonly)), so the data remains available even when no passcode is set. +- **Stale Device-Lock Assumption**: Checking the device-lock configuration only during onboarding or feature enrollment and continuing to enable the functionality after the device credential has been removed or the required authentication policy is no longer available. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can open the app and read its data on a device with no lock, resulting in unauthorized disclosure of user data whose protection assumed a device credential. +- **Authentication or Authorization Bypass**: Attackers can act within the app's active sessions on an unprotected device, resulting in unauthorized use of the victim's accounts. + +## Mitigations + +- **Verify the Device Lock State**: Use platform APIs (e.g. `isDeviceSecure()` on Android, `canEvaluatePolicy` on iOS) to determine whether the current user has configured a PIN, pattern, or password. +- **Re-check Before Enabling Protected Functionality**: Evaluate the current device-lock configuration before enabling or accessing any high-risk functionality. +- **Bind Sensitive Key Use to Platform Authentication**: Where a sensitive operation depends on local cryptographic material, enforce authentication at the key-access layer rather than relying only on application UI state. For example, use the [Android Keystore](https://developer.android.com/privacy-and-security/keystore) or the [iOS Keychain](https://developer.apple.com/documentation/localauthentication/accessing-keychain-items-with-face-id-or-touch-id) to force a biometric or passcode prompt before performing cryptographic operations. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0025.md b/weaknesses/MASVS-NETWORK/MASWE-0025.md new file mode 100644 index 00000000..0a59960e --- /dev/null +++ b/weaknesses/MASVS-NETWORK/MASWE-0025.md @@ -0,0 +1,69 @@ +--- +title: Network Traffic Not Encrypted +id: MASWE-0025 +alias: cleartext-traffic +requirement: "The app encrypts all network traffic." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0025 +attacks: [MAS-ATTACK-0012, MAS-ATTACK-0013, MAS-ATTACK-0014] +mappings: + masvs-v1: [MSTG-NETWORK-1, MSTG-NETWORK-2] + masvs-v2: [MASVS-NETWORK-1] + cwe: [319] + android-risks: + - cleartext-communications + - insecure-machine-to-machine + android-core-app-quality: [Network_Security_Traffic, Network_Security_Configuration] + maswe-beta: [MASWE-0050, MASWE-0037, MASWE-0048] +refs: +- https://developer.apple.com/documentation/security/preventing-insecure-network-connections +- https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity/nsexceptiondomains +- https://developer.apple.com/documentation/network +- https://developer.apple.com/documentation/foundation/urlsession +- https://developer.apple.com/forums/thread/67493 +- https://developer.apple.com/forums/thread/707320 +- https://developer.android.com/privacy-and-security/security-best-practices#secure-communication +- https://developer.android.com/privacy-and-security/security-tips#networking +- https://developer.android.com/privacy-and-security/security-config#CleartextTraffic +- https://developer.android.com/reference/javax/net/ssl/SSLSocket +- https://developer.android.com/reference/android/security/NetworkSecurityPolicy#isCleartextTrafficPermitted() +- https://developer.android.com/reference/java/net/Socket +- https://developer.android.com/reference/android/webkit/WebView +- https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection +--- + +## Overview + +This weakness occurs when an app transmits data over the network in cleartext, i.e. without encryption, making it accessible to anyone able to monitor the network channel. + +This is especially concerning when sensitive information is transmitted, putting user privacy and security at direct risk. However, even when no sensitive data is being transmitted, cleartext communication remains a weakness: attackers who can intercept or redirect traffic may disrupt app functionality or deceive users by redirecting them to malicious sites that impersonate legitimate services. + +Secure network protocols not only provide confidentiality but also ensure data integrity and authenticity through encryption and certificate validation. When connections are properly secured, interception and manipulation attacks become much harder to perform because the attacker would need to bypass encryption and certificate validation. + +## Modes of Introduction + +- **Cleartext Traffic Allowed in Platform-Provided Settings**: Configuring platform-provided settings (e.g. Network Security Configuration on Android or App Transport Security on iOS) to explicitly allow cleartext traffic (globally or per-domain), making it the default behavior for all network connections managed by those settings. +- **Usage of HTTP**: Using HTTP instead of HTTPS for communication, which does not encrypt data in transit. +- **Usage of Non-HTTP Insecure Protocols**: Using insecure protocols such as FTP, SMTP without TLS, TCP sockets, or custom protocols which do not encrypt data in transit. +- **Unencrypted Machine-to-Machine Channels**: Transferring data over local/proximity interfaces such as Bluetooth/BLE, NFC, USB, or Wi-Fi Direct without encryption, or relying solely on link-layer protection such as BLE "Just Works" pairing instead of application-layer encryption. +- **Usage of Low-Level Network APIs**: Using low-level network APIs that do not enforce encryption and do not honor the platform's network security settings, such as [`Socket`](https://developer.android.com/reference/java/net/Socket) on Android or [`NWConnection`](https://developer.apple.com/documentation/network/nwconnection) on iOS. +- **Cross-Platform Framework Misconfiguration**: Configuring cross-platform frameworks improperly so that cleartext traffic is allowed for both Android and iOS versions of an app. +- **Third-Party Libraries**: Using third-party libraries or SDKs that default to insecure communication methods or are improperly configured. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. +- **Authentication or Authorization Bypass**: Attackers can capture session tokens or credentials sent over cleartext channels, resulting in user impersonation and unauthorized access to accounts or backend systems. +- **Compromise of System Integrity and Business Operations**: Attackers can inject malicious content or redirect users to impersonated services, resulting in altered app behavior, phishing, and reputational damage for the app owner. +- **Legal and Regulatory Non-Compliance**: Attackers can capture personal data in transit, resulting in reportable breaches and regulatory penalties for the app owner under laws such as GDPR or HIPAA. + +## Mitigations + +- **Use Secure Protocols**: Always use secure protocols like HTTPS (which employs TLS for encryption), FTPS, SFTP, or SMTPS for all communication channels. Ensure these protocols are used consistently throughout the app. +- **Explicitly Disable Cleartext Traffic**: Never allow cleartext traffic globally in the app configuration. Ensure that cleartext traffic is explicitly disabled using security settings like the Network Security Configuration on Android and App Transport Security (ATS) on iOS. +- **Use Per-Domain Exceptions Sparingly**: If cleartext traffic is absolutely necessary for specific domains, ensure these domains are trusted and essential for the app's functionality, and conduct a thorough risk assessment before including them. +- **Prefer Server Fixes**: Whenever possible, work with the server team to enable secure communication. Instead of adding network security exceptions to the mobile app, such as allowing cleartext traffic or lowering the minimum TLS version, update server configurations to support HTTPS with valid certificates and modern TLS protocols. +- **Use High-Level Network APIs**: Use high-level network APIs that automatically handle encryption, certificate validation, and errors, such as [`HttpsURLConnection`](https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection) on Android or [`URLSession`](https://developer.apple.com/documentation/foundation/urlsession) on iOS. Avoid using low-level network APIs or custom network stacks that bypass the platform-provided network security features. +- **Use Secure Cross-Platform Frameworks**: Ensure that cross-platform frameworks are configured to enforce secure communication by default and do not allow cleartext traffic. Review the framework's documentation and adjust network security settings to align with best practices. +- **Use Secure Third-Party Components**: Verify that any third-party libraries and SDKs used in the app enforce secure communication protocols, especially if they handle sensitive data or use low-level networking APIs. Ensure that these components are regularly updated to address any vulnerabilities. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0026.md b/weaknesses/MASVS-NETWORK/MASWE-0026.md new file mode 100644 index 00000000..856cdc15 --- /dev/null +++ b/weaknesses/MASVS-NETWORK/MASWE-0026.md @@ -0,0 +1,59 @@ +--- +title: Insecure Certificate Validation +id: MASWE-0026 +alias: insecure-cert-validation +requirement: "The app validates certificates for all network traffic." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0026 +attacks: [MAS-ATTACK-0014, MAS-ATTACK-0015] +mappings: + masvs-v1: [MSTG-NETWORK-3] + masvs-v2: [MASVS-NETWORK-1] + cwe: [295, 297] + android-risks: + - unsafe-trustmanager + - unsafe-hostname + android-core-app-quality: [Network_Security_Configuration, Security_Provider_Initialization] + maswe-beta: [MASWE-0052] +refs: +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf#page=17 +- https://developer.android.com/privacy-and-security/security-ssl#tls-1.3-enabled-by-default +- https://support.google.com/faqs/answer/7071387?hl=en +- https://developer.android.com/reference/android/webkit/WebViewClient.html?sjid=15211564825735678155-EU#onReceivedSslError(android.webkit.WebView,%20android.webkit.SslErrorHandler,%20android.net.http.SslError) +- https://developer.android.com/privacy-and-security/security-ssl#WarningsSslSocket +- https://developer.apple.com/forums/thread/67493 +- https://developer.apple.com/forums/thread/707320 +- https://support.apple.com/en-us/102390 +- https://developer.apple.com/documentation/foundation/performing-manual-server-trust-authentication +--- + +## Overview + +This weakness occurs when an app does not properly validate TLS certificates during secure communication, accepting invalid, expired, self-signed, or untrusted certificates without appropriate verification. + +Certificate validation is the mechanism through which a TLS client establishes that it is talking to the intended server and not to an intermediary. When it is disabled, weakened, or implemented incorrectly, the confidentiality and integrity guarantees of TLS no longer hold, even though the connection itself is encrypted. + +## Modes of Introduction + +- **Disabling Certificate Validation**: Disabling or bypassing certificate validation checks to simplify development or troubleshoot connectivity issues, and shipping that configuration to production. +- **Accepting Self-Signed Certificates**: Accepting self-signed or untrusted certificates without proper validation against trusted Certificate Authorities (CAs). +- **Ignoring Hostname Verification**: Failing to verify that the certificate's hostname matches the server's hostname. +- **Using Insecure Custom Trust Managers**: Implementing custom certificate validation logic that is incomplete, incorrect, or insecure. +- **Incorrect Error Handling**: Proceeding with connections even when certificate validation errors occur, without alerting the user or terminating the connection. +- **Third-Party Libraries**: Using third-party libraries or SDKs that disable or weaken certificate validation internally, or that default to permissive trust settings. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. +- **Authentication or Authorization Bypass**: Attackers can capture credentials or session tokens in transit, resulting in user impersonation and unauthorized access to accounts or backend systems. +- **Compromise of System Integrity and Business Operations**: Attackers can impersonate legitimate servers and feed altered or malicious data to the app, resulting in unreliable or malicious app behavior and reputational damage for the app owner. +- **Legal and Regulatory Non-Compliance**: Attackers can capture personal data in transit, resulting in reportable breaches and regulatory penalties for the app owner under laws such as GDPR or HIPAA. + +## Mitigations + +- **Enforce Strict Certificate Validation**: Always validate TLS certificates against a trusted set of Certificate Authorities (CAs) provided by the operating system or a trusted third party. +- **Avoid Accepting Self-Signed Certificates**: Do not accept self-signed or untrusted certificates in production environments unless there is a secure mechanism to trust them explicitly. +- **Enable Hostname Verification**: Ensure that the application's network layer verifies the server's hostname against the certificate's Subject Alternative Name (SAN) or Common Name (CN). +- **Use Standard Trust Managers**: Utilize well-established libraries and platform-provided APIs for certificate validation instead of custom implementations. +- **Handle Validation Errors Properly**: Terminate the connection and alert the user whenever certificate validation fails due to issues like expiration, revocation, or mismatch. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0027.md b/weaknesses/MASVS-NETWORK/MASWE-0027.md new file mode 100644 index 00000000..3046a542 --- /dev/null +++ b/weaknesses/MASVS-NETWORK/MASWE-0027.md @@ -0,0 +1,51 @@ +--- +title: Insecure Identity Pinning +id: MASWE-0027 +alias: insecure-pinning +requirement: "The app correctly implements identity pinning." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0027 +attacks: [MAS-ATTACK-0014, MAS-ATTACK-0016, MAS-ATTACK-0017] +mappings: + masvs-v1: [MSTG-NETWORK-4] + masvs-v2: [MASVS-NETWORK-2] + cwe: [295] + android-core-app-quality: [Network_Security_Configuration] + maswe-beta: [MASWE-0047] +refs: +- https://developer.android.com/privacy-and-security/security-config#CertificatePinning +- https://developer.apple.com/news/?id=g9ejcf8y +- https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html +--- + +## Overview + +This weakness occurs when identity pinning (also known as certificate pinning, public key pinning, or TLS pinning) is not implemented, or is implemented incorrectly, so the app cannot guarantee that it only communicates with servers presenting a specific, pre-determined cryptographic identity. + +Identity pinning associates a mobile app with a specific certificate or public key, adding a layer of trust verification on top of standard certificate validation. This reduces the risk of unauthorized interception even if a trusted Certificate Authority (CA) is compromised. Compromise of a public CA is rare, but pinning narrows trust to identities the app operator controls, and raises the effort required to intercept, inspect, or replay the app's traffic. + +Pinning is not foolproof: attackers who can reverse-engineer the app may remove or modify the pre-defined pins or the pinning logic, and attackers using runtime hooking and dynamic instrumentation may bypass the pinning checks on a device they control. This highlights the importance of implementing pinning **alongside other security measures** to enhance the app's resistance to advanced threats. + +## Modes of Introduction + +- **Improper Configuration of Pinning Libraries**: Misconfiguring libraries like TrustKit or OkHttp's `CertificatePinner` leading to ineffective pinning. +- **Dynamic Pinning without Security**: Retrieving pins dynamically over insecure channels without proper validation. +- **Improper Validation Logic**: Implementing custom pinning logic that does not correctly validate the certificate chain or public key. For example, accepting any certificate that chains to a trusted root CA instead of a specific certificate or public key. +- **Lack of Backup Pins**: Not including backup pins, so the app cannot establish connections if the primary pin is no longer valid. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can capture, read, or alter sensitive information transmitted over the network, resulting in unauthorized disclosure or manipulation of user data. +- **Authentication or Authorization Bypass**: Attackers can capture credentials or session tokens in transit, resulting in user impersonation and unauthorized access to accounts or backend systems. +- **Compromise of System Integrity and Business Operations**: Attackers can inspect and reverse engineer the app's API traffic to abuse backend services, resulting in fraud, scraping, or service abuse against the app owner. + +## Mitigations + +- **Prefer Platform-Provided Solutions**: Use platform-provided mechanisms like Android's Network Security Configuration (NSC) or iOS's App Transport Security (ATS) to enforce pinning. +- **Use Trusted Pinning Libraries**: Refrain from writing custom pinning logic; instead, rely on established and well-maintained libraries and frameworks (e.g., TrustKit, OkHttp's `CertificatePinner`) and ensure they are correctly configured according to best practices. +- **Secure Dynamic Pinning**: If dynamic pinning is necessary, retrieve pins over secure channels and validate them thoroughly before use. +- **Pin to Public Keys Instead of Certificates**: Pin to the certificate's public key rather than the whole certificate to avoid issues regarding expiration and renewals. +- **Enforce Pinning Consistently**: Apply pinning uniformly for all connections to servers that you control. +- **Regularly Update Pins**: Keep the pinned certificates or public keys up to date with the server's current configuration and have a process for updating the app when changes occur. +- **Implement Backup Pins**: Include backup pins (hashes of additional trusted public keys) to prevent connectivity issues if the primary key changes. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0047.md b/weaknesses/MASVS-NETWORK/MASWE-0047.md deleted file mode 100644 index 453a5937..00000000 --- a/weaknesses/MASVS-NETWORK/MASWE-0047.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Insecure Identity Pinning -id: MASWE-0047 -alias: insecure-pinning -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-NETWORK-4] - masvs-v2: [MASVS-NETWORK-2] - cwe: [295] -status: new ---- - -## Overview - -[Identity pinning (aka. certificate pinning, public key pinning or TLS pinning)](../../Document/0x04f-Testing-Network-Communication.md/#restricting-trust-identity-pinning) refers to associating a mobile app with a specific cryptographic identity, such as a certificate or public key to ensure that the app only communicates with trusted servers. - -When a mobile app does not implement certificate pinning, or if it is implemented incorrectly, the app remains vulnerable to [Machine-in-the-Middle (MITM)](../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) attacks which enable attackers to intercept and modify the communication between the app and the intended server. This occurs because when the app is presented a fraudulent certificate that the app may unknowingly trust, thereby gaining access to sensitive data or injecting malicious content into the data stream. - -**Limitations**: Certificate pinning adds a layer of trust verification by ensuring that the app only accepts connections to servers with specific, pre-determined certificates or public keys. This reduces the risk of unauthorized interception, even if a trusted Certificate Authority (CA) is compromised. However, it is not foolproof: - -- Attackers who can reverse-engineer the app may analyze and remove or modify the pre-defined pins or the certificate pinning logic to permanently bypass the checks. -- Attackers who can perform @MASTG-TECH-0051 techniques to manipulate the app and bypass pinning checks. - -This highlights the importance of implementing certificate pinning **alongside other security measures** to enhance the app's resistance to advanced threats. - -## Impact - -- **Data Interception**: Attackers can capture and read sensitive information transmitted over the network. -- **Data Manipulation**: Attackers might alter data in transit, causing corruption or injecting malicious content. -- **Data Exposure**: Sensitive information can be compromised. -- **Denial of Service**: Incorrect pinning may cause legitimate connections to fail, leading to service disruptions for users. For example, if a pinned certificate expires and is not updated, the app may be unable to establish secure connections. - -## Modes of Introduction - -- **Improper Configuration of Pinning Libraries**: Misconfiguring libraries like TrustKit, OkHttp's `CertificatePinner`, Volley, or AFNetworking's `SSLPinningMode`, leading to ineffective pinning. -- **Dynamic Pinning without Security**: Retrieving pins dynamically over insecure channels without proper validation, making it easy for attackers to supply malicious pins. -- **Improper Validation Logic**: Custom pinning implementations that do not correctly validate the certificate chain or public key. For example, accepting any certificate that chains to a trusted root CA instead of a specific certificate or public key. -- **Lack of Backup Pins**: Not including backup pins to prevent connectivity issues if the primary pin is no longer valid. - -## Mitigations - -- **Prefer Platform-provided Solutions**: Use platform-provided mechanisms like Android's Network Security Configuration (NSC) or iOS's App Transport Security (ATS) to enforce pinning. -- **Use Trusted Pinning Libraries**: Refrain from writing custom pinning logic; instead, rely on established and well-maintained libraries and frameworks (e.g., TrustKit, OkHttp's `CertificatePinner`) and ensure they are correctly configured according to best practices. -- **Secure Dynamic Pinning**: If dynamic pinning is necessary, retrieve pins over secure channels and validate them thoroughly before use. -- **Pin to Public Keys Instead of Certificates**: Pin to the certificate's public key rather than the whole certificate to avoid issues regarding expiration and renewals. -- **Consistent Enforcement**: Apply pinning uniformly for all connections to servers that you control. -- **Regularly Update Pins**: Keep the pinned certificates or public keys up to date with the server's current configuration and have a process for updating the app when changes occur. -- **Implement Backup Pins**: Include backup pins (hashes of additional trusted public keys) to prevent connectivity issues if the primary key changes. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0048.md b/weaknesses/MASVS-NETWORK/MASWE-0048.md deleted file mode 100644 index 9c83e020..00000000 --- a/weaknesses/MASVS-NETWORK/MASWE-0048.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Insecure Machine-to-Machine Communication -id: MASWE-0048 -alias: insecure-m2m -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-NETWORK-1] - masvs-v2: [MASVS-NETWORK-1] - cwe: [311, 319] - android-risks: - - https://developer.android.com/privacy-and-security/risks/insecure-machine-to-machine -draft: - description: Android applications often use technologies like Bluetooth, NFC, and USB for data transfer and device interaction. Developers must use these APIs carefully to prevent data exposure and remote device takeover by attackers. - topics: - - Bluetooth - - BLE - - NFC - - USB - - Wi-Fi P2P -status: placeholder ---- diff --git a/weaknesses/MASVS-NETWORK/MASWE-0049.md b/weaknesses/MASVS-NETWORK/MASWE-0049.md deleted file mode 100644 index f14e4ad3..00000000 --- a/weaknesses/MASVS-NETWORK/MASWE-0049.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Proven Networking APIs Not used -id: MASWE-0049 -alias: no-proven-net-apis -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-NETWORK-6] - masvs-v2: [MASVS-NETWORK-1, MASVS-CODE-3] -status: new ---- - -## Overview - -Applications that do not utilize platform-provided networking APIs or well-established security libraries are susceptible to security vulnerabilities. When developers implement custom networking code or "roll-your-own" security mechanisms, they risk introducing flaws due to a lack of deep expertise in cryptography and network security. Platform-provided APIs and libraries, such as `NSURLSession` on iOS or `HttpsURLConnection` on Android, are designed and maintained by experts, incorporating security best practices and regular updates to address new threats and vulnerabilities. - -## Impact - -- **Security Vulnerabilities**: Custom networking implementations may contain flaws that attackers can exploit, leading to data breaches and unauthorized access. -- **Lack of Updates**: Custom code may not receive timely updates to address new vulnerabilities or comply with evolving security standards. -- **Inconsistent Security Measures**: Bypassing standard APIs can result in inconsistent application of security features like encryption, certificate validation, and error handling. -- **Increased Development Complexity**: Writing and maintaining custom networking code increases complexity, making it harder to audit and secure the application. -- **Non-Compliance with Standards**: Failing to use approved APIs may lead to non-compliance with industry regulations and security guidelines. - -## Modes of Introduction - -- **Custom Networking Stack Development**: Developers create their own networking code instead of using platform-provided APIs, possibly to add custom features or due to unfamiliarity with existing APIs. -- **Use of Insecure Third-Party Libraries**: Incorporating third-party networking libraries that are outdated or do not follow current security best practices. -- **Bypassing Security Mechanisms**: Deliberately avoiding standard APIs to circumvent security checks, such as certificate pinning or TLS enforcement. -- **Insufficient Security Knowledge**: Developers may lack adequate understanding of network security principles, leading to insecure implementations. -- **Performance Optimization Attempts**: Writing custom networking code to optimize performance without fully considering the security implications. - -## Mitigations - -- **Utilize Platform-Provided Networking APIs**: Always use the networking APIs provided by the platform, such as `NSURLSession` for iOS and `HttpsURLConnection` for Android, which handle many security concerns internally. -- **Adopt Established Security Libraries**: If additional functionality is required, use reputable, well-maintained libraries like `OkHttp` for Android or `Alamofire` on iOS that adhere to security best practices. -- **Avoid Custom Security Implementations**: Refrain from implementing custom cryptographic algorithms or security protocols; rely on standard, vetted solutions instead. -- **Keep Dependencies Updated**: Regularly update all libraries and dependencies to incorporate the latest security patches and improvements. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0050.md b/weaknesses/MASVS-NETWORK/MASWE-0050.md deleted file mode 100644 index 88ef2efc..00000000 --- a/weaknesses/MASVS-NETWORK/MASWE-0050.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: Cleartext Traffic -id: MASWE-0050 -alias: cleartext-traffic -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-NETWORK-2] - masvs-v2: [MASVS-NETWORK-1] - cwe: [319] - android-risks: - - https://developer.android.com/privacy-and-security/risks/cleartext-communications - android-core-app-quality: [SC-9, SC-N1, SC-N2] -refs: -- https://developer.apple.com/documentation/security/preventing-insecure-network-connections -- https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity/nsexceptiondomains -- https://developer.apple.com/documentation/network -- https://developer.apple.com/documentation/foundation/urlsession -- https://developer.apple.com/forums/thread/67493 -- https://developer.apple.com/forums/thread/707320 -- https://developer.android.com/privacy-and-security/security-best-practices#secure-communication -- https://developer.android.com/privacy-and-security/security-tips#networking -- https://developer.android.com/privacy-and-security/security-config#CleartextTrafficPermitted -- https://developer.android.com/reference/javax/net/ssl/SSLSocket -- https://developer.android.com/reference/android/security/NetworkSecurityPolicy#isCleartextTrafficPermitted() -- https://developer.android.com/reference/java/net/Socket -- https://developer.android.com/reference/android/webkit/WebView -- https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection -- https://github.com/MicrosoftDocs/xamarin-docs/blob/live/docs/android/app-fundamentals/http-stack.md -- https://github.com/MicrosoftDocs/xamarin-docs/blob/live/docs/ios/app-fundamentals/ats.md -status: new ---- - -## Overview - -When data is sent in cleartext (i.e. without encryption) it becomes accessible to attackers who can monitor network channels. Attackers can perform passive eavesdropping to intercept data or employ active [Machine-in-the-Middle (MITM)](../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) attacks to manipulate data, potentially altering app behavior or injecting malicious content. - -This weakness is especially concerning when sensitive information is transmitted without encryption, putting user privacy and security at direct risk. Even when sensitive data isn't being transmitted, using cleartext communication remains a vulnerability. Network attacks like ARP poisoning and DNS spoofing can allow attackers to intercept or redirect traffic, potentially disrupting app functionality or deceiving users by redirecting them to malicious sites that impersonate legitimate services. - -If the connections were secured using encryption and proper authentication mechanisms, these attacks would be much harder to perform because the attacker would need to bypass encryption and certificate validation. Secure network protocols not only provide confidentiality but also ensure data integrity and authenticity through encryption and certificate validation, preventing attackers from altering data. - -## Impact - -- **Data Interception**: Attackers can capture and read sensitive information transmitted over the network. -- **Data Manipulation**: Attackers might alter data in transit, causing corruption or injecting malicious content. -- **Unauthorized Access**: Attackers may intercept session tokens or credentials sent over cleartext channels, enabling them to impersonate users and gain unauthorized access to user accounts or systems. -- **Privacy Breach**: Personal and confidential user information could be exposed, violating privacy regulations. -- **Regulatory Compliance Violations**: Exposing sensitive data may lead to non-compliance with laws like GDPR or HIPAA, resulting in legal penalties. -- **Reputation Damage**: Security breaches can erode user trust and harm the organization's reputation. - -## Modes of Introduction - -- **Cleartext Traffic Allowed in Platform-provided Settings:** Configuring platform-provided settings (e.g. Network Security Configuration on Android or App Transport Security on iOS) to explicitly allow cleartext traffic (globally or per-domain), making it the default behavior for all network connections managed by those settings. -- **Usage of HTTP:** Using HTTP instead of HTTPS for communication, which does not encrypt data in transit. -- **Usage of Non-HTTP Insecure Protocols:** Using insecure protocols such as FTP, SMTP without TLS, TCP sockets or custom protocols which do not encrypt data in transit. -- **Usage of Low-Level Network APIs:** Use of low-level network APIs that do not enforce encryption and do not honor the platform's network security settings, such as `Socket` on Android or `NSURLConnection` on iOS. -- **Cross-Platform Framework Misconfiguration:** Improper settings in cross-platform frameworks may allow cleartext traffic for both Android and iOS versions of an app. -- **Third-Party Libraries**: Using third-party libraries or SDKs that default to insecure communication methods or are improperly configured. - -## Mitigations - -- **Use Secure Protocols:** Always use secure protocols like HTTPS (which employs TLS for encryption), FTPS, SFTP or SMTPS for all communication channels. Ensure these protocols are used consistently throughout the app. -- **Explicitly Disable Cleartext Traffic:** Never allow cleartext traffic globally in the app configuration. Ensure that cleartext traffic is explicitly disabled using security settings like the Network Security Configuration on Android and App Transport Security (ATS) on iOS. Prefer per-domain exceptions over global settings but use them carefully and only when there is no other option. -- **Use Per-Domain Exceptions Sparingly:** If cleartext traffic is absolutely necessary for specific domains, ensure these domains are trusted and essential for the app's functionality, and conduct a thorough risk assessment before including them. -- **Prefer Server Fixes**: Whenever possible, work with the server team to enable secure communication. Instead of adding network security exceptions to the mobile app, such as allowing cleartext traffic or lowering the minimum TLS version, update server configurations to support HTTPS with valid certificates and modern TLS protocols. -- **Use High-Level Network APIs:** Use high-level network APIs that automatically handle encryption, certificate validation, and errors, such as [`HttpsURLConnection`](https://developer.android.com/reference/javax/net/ssl/HttpsURLConnection) on Android or [`URLSession`](https://developer.apple.com/documentation/foundation/urlsession) on iOS. Avoid using low-level network APIs or custom network stacks that bypass the platform-provided network security features. -- **Use Secure Cross-Platform Frameworks:** Ensure that cross-platform frameworks—such as React Native, Flutter, or Xamarin—are configured to enforce secure communication by default and do not allow cleartext traffic. Review the framework's documentation and adjust network security settings to align with best practices. -- **Use Secure Third-Party Components**: Verify that any third-party libraries and SDKs used in the app enforce secure communication protocols, especially if they handle sensitive data or use low-level networking APIs. Ensure that these components are regularly updated to address any vulnerabilities. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0051.md b/weaknesses/MASVS-NETWORK/MASWE-0051.md deleted file mode 100644 index f2516973..00000000 --- a/weaknesses/MASVS-NETWORK/MASWE-0051.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Unprotected Open Ports -id: MASWE-0051 -alias: open-ports -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-NETWORK-2] - masvs-v2: [MASVS-NETWORK-1] - cwe: [923] -status: new ---- - -## Overview - -Applications that open network ports without proper protection are vulnerable to unauthorized access and potential exploitation. This weakness occurs when an application listens on a network port and accepts incoming connections without adequate security measures, allowing other applications or attackers to connect and interact with it. - -## Impact - -- **Unauthorized Access**: Attackers can connect to open ports and gain access to application functionalities or sensitive data. -- **Data Leakage**: Sensitive information may be exposed through unprotected ports if proper authentication and encryption are not enforced. -- **Remote Code Execution**: Exploitation of open ports can lead to the execution of arbitrary code on the device. -- **Denial of Service**: Attackers may overload the open port, causing the application or device to become unresponsive. -- **Privacy Breach**: User data and application state can be compromised, leading to privacy violations and non-compliance with regulations. - -## Modes of Introduction - -- **Binding to All Network Interfaces**: Configuring the application to bind to all available network interfaces (e.g., using wildcard addresses), making it accessible over untrusted networks. -- **Insecure Loopback Address Usage**: Misconfiguring the application to listen on loopback addresses without proper access restrictions. -- **Lack of Access Controls**: Failing to implement authentication and authorization mechanisms for services exposed via open ports. -- **Debug Services Left Enabled**: Leaving development or debugging network services active in production releases. -- **Misconfigured Firewall Settings**: Not setting up proper firewall rules, allowing unauthorized inbound connections to open ports. - -## Mitigations - -- **Restrict Network Bindings**: Configure the application to bind only to specific, necessary network interfaces, avoiding the use of wildcard addresses like `INADDR_ANY`. -- **Implement Strong Access Controls**: Enforce authentication and authorization for any services exposed through open ports to ensure only authorized entities can connect. -- **Disable Debugging Services in Production**: Ensure that all development and debugging network services are disabled or removed in production builds. -- **Configure Firewalls Appropriately**: Set up firewall rules to restrict access to open ports, allowing connections only from trusted sources. diff --git a/weaknesses/MASVS-NETWORK/MASWE-0052.md b/weaknesses/MASVS-NETWORK/MASWE-0052.md deleted file mode 100644 index c72745eb..00000000 --- a/weaknesses/MASVS-NETWORK/MASWE-0052.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Insecure Certificate Validation -id: MASWE-0052 -alias: insecure-cert-val -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-NETWORK-3] - masvs-v2: [MASVS-NETWORK-1] - cwe: [295, 297] - android-risks: - - https://developer.android.com/privacy-and-security/risks/unsafe-trustmanager - - https://developer.android.com/privacy-and-security/risks/unsafe-hostname -refs: - - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf#page=17 - - https://developer.android.com/privacy-and-security/security-ssl#tls-1.3-enabled-by-default - - https://support.google.com/faqs/answer/7071387?hl=en - - https://developer.android.com/reference/android/webkit/WebViewClient.html?sjid=15211564825735678155-EU#onReceivedSslError(android.webkit.WebView,%20android.webkit.SslErrorHandler,%20android.net.http.SslError) - - https://developer.android.com/privacy-and-security/security-ssl#WarningsSslSocket - - https://wiki.sei.cmu.edu/confluence/display/java/MSC00-J.+Use+SSLSocket+rather+than+Socket+for+secure+data+exchange - - https://developer.apple.com/forums/thread/67493 - - https://developer.apple.com/forums/thread/707320 - - https://support.apple.com/en-us/102390 - - https://developer.apple.com/documentation/foundation/performing-manual-server-trust-authentication -status: new ---- - -## Overview - -Apps that do not properly validate TLS certificates during secure communication are susceptible to [Machine-in-the-Middle (MITM)](../../Document/0x04f-Testing-Network-Communication.md#intercepting-network-traffic-through-mitm) attacks and other security threats. This weakness occurs when an app accepts invalid, expired, self-signed, or untrusted certificates without appropriate verification, compromising the integrity and confidentiality of data in transit. - -## Impact - -- **Data Interception**: Attackers can capture and read sensitive information transmitted over the network. -- **Data Manipulation**: Attackers might alter data in transit, causing corruption or injecting malicious content. -- **Data Exposure**: Sensitive information can be compromised. -- **Unauthorized Access**: Attackers may gain unauthorized access to user accounts or systems by intercepting authentication tokens or credentials. -- **Impersonation of Services**: Users may be deceived into interacting with malicious servers impersonating legitimate services. -- **Data Integrity Loss**: Altered or corrupted data may be accepted by the application, leading to unreliable or malicious outcomes. - -## Modes of Introduction - -- **Disabling Certificate Validation**: Developers disable or bypass certificate validation checks to simplify development or troubleshoot connectivity issues. -- **Accepting Self-Signed Certificates**: Applications accept self-signed or untrusted certificates without proper validation against trusted Certificate Authorities (CAs). -- **Ignoring Hostname Verification**: Failing to verify that the certificate's hostname matches the server's hostname allows attackers to present valid certificates for other domains. -- **Using Insecure Custom Trust Managers**: Implementing custom certificate validation logic that is incomplete, incorrect, or insecure. -- **Incorrect Error Handling**: Proceeding with connections even when certificate validation errors occur, without alerting the user or terminating the connection. -- **Trusting All Certificates**: Configuring the application to trust all certificates by default, without any validation. - -## Mitigations - -- **Enforce Strict Certificate Validation**: Always validate TLS certificates against a trusted set of Certificate Authorities (CAs) provided by the operating system or a trusted third party. -- **Avoid Accepting Self-Signed Certificates**: Do not accept self-signed or untrusted certificates in production environments unless there is a secure mechanism to trust them explicitly. -- **Enable Hostname Verification**: Ensure that the application's network layer verifies the server's hostname against the certificate's Subject Alternative Name (SAN) or Common Name (CN). -- **Use Standard Trust Managers**: Utilize well-established libraries and platform-provided APIs for certificate validation instead of custom implementations. -- **Handle Validation Errors Properly**: Terminate the connection and alert the user whenever certificate validation fails due to issues like expiration, revocation, or mismatch. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0028.md b/weaknesses/MASVS-PLATFORM/MASWE-0028.md new file mode 100644 index 00000000..0e693516 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0028.md @@ -0,0 +1,39 @@ +--- +title: Unnecessary Exposure of Sensitive Data via the User Interface +id: MASWE-0028 +alias: data-leak-ui +requirement: "The app does not unnecessarily expose sensitive data through its user interface." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0028 +attacks: [MAS-ATTACK-0005, MAS-ATTACK-0041, MAS-ATTACK-0043] +mappings: + masvs-v1: [MSTG-STORAGE-7] + masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] + cwe: [200, 359] + maswe-beta: [MASWE-0053] +refs: +- https://developer.android.com/develop/ui/views/touch-and-input/keyboard-input/style#Type +- https://developer.apple.com/documentation/uikit/uitextinputtraits/1624427-issecuretextentry +--- + +## Overview + +This weakness occurs when an app exposes sensitive data beyond what is required for the user's current task, or exposes required data without protections proportionate to its sensitivity through its user interface. + +The typical exposure path involves displaying secrets or sensitive information in cleartext when masking or a partial representation would suffice, (e.g., using unprotected input fields for passwords or PINs). + +## Modes of Introduction + +- **Non-Secure Text Entry**: Building password or PIN fields without inserting them in platform-specific fields that mask sensitive data (e.g. [`isSecureTextEntry`](https://developer.apple.com/documentation/uikit/uitextinputtraits/issecuretextentry) on iOS, [`textPassword`](https://developer.android.com/develop/ui/views/touch-and-input/keyboard-input/style#Type) input types on Android), so the input is shown in cleartext. +- **Unmasked Sensitive Values**: Displaying full values (e.g. complete card numbers or personal identifiers) where a masked or partial representation would suffice. + +## Impact + +- **Compromise of Sensitive Data**: Sensitive information may be observed from the screen and captured by other user. +- **Authentication or Authorization Bypass**: Attackers can capture credentials, PINs, or one-time codes exposed through the UI, resulting in unauthorized access to the user's accounts. + +## Mitigations + +- **Use Secure Text Entry for Secrets**: Configure passwords, PINs, and other secrets using the platform's secure text-entry controls, such as [`textPassword` on Android Views](https://developer.android.com/develop/ui/views/touch-and-input/keyboard-input/style), [`SecureTextField` in Jetpack Compose](https://developer.android.com/develop/ui/compose/text/user-input), or [`isSecureTextEntry` on iOS](https://developer.apple.com/documentation/uikit/uitextinputtraits/issecuretextentry). Do not rely solely on custom visual masking when a platform-provided secure text-entry control is available. +- **Minimize Visual Disclosure**: Display only the portion of a sensitive value required for the user's current task. When revealing the full value is necessary, reveal it only after an explicit user action (see @MASWE-0017) and for a limited duration. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0029.md b/weaknesses/MASVS-PLATFORM/MASWE-0029.md new file mode 100644 index 00000000..1827c125 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0029.md @@ -0,0 +1,38 @@ +--- +title: Unnecessary Exposure of Sensitive Data via Notifications +id: MASWE-0029 +alias: data-leak-notifications +requirement: "The app does not unnecessarily expose sensitive data through system notifications." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0029 +attacks: [MAS-ATTACK-0044, MAS-ATTACK-0045] +mappings: + masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] + cwe: [200, 359] + maswe-beta: [MASWE-0054] +refs: +- https://developer.android.com/develop/ui/views/notifications/build-notification#lockscreenNotification +- https://developer.apple.com/documentation/usernotifications +--- + +## Overview + +This weakness occurs when an app includes more sensitive data (such as one-time codes, message contents, or account details) than necessary in a system notification. + +Notifications can be rendered on the lock screen, and therefore, anyone holding the device can read them without unlocking it. They also can be read by other apps that hold notification access, if the platform allows it (e.g. an Android [`NotificationListenerService`](https://developer.android.com/reference/android/service/notification/NotificationListenerService)). Any sensitive value included in a notification therefore leaves the app's control the moment it is posted. + +## Modes of Introduction + +- **Sensitive Content in Notifications**: Including one-time codes, message contents, financial details, or other sensitive values directly in notification titles or bodies when a generic notification would suffice. +- **No Lock-Screen Redaction**: Not configuring notification visibility so that sensitive content is redacted or hidden on the lock screen. + +## Impact + +- **Compromise of Sensitive Data**: Unauthorized observers or, where applicable, apps with notification-listener access may obtain personal, financial, authentication, or account information contained in notifications. +- **Authentication or Authorization Bypass**: Attackers may use exposed credentials or still-valid one-time codes to access an account, perform unauthorized transactions, or carry out other sensitive actions. + +## Mitigations + +- **Minimize Notification Content**: Use notifications only to indicate that an event occurred, and retrieve sensitive details inside the app after appropriate authentication and authorization. For iOS remote notifications, follow Apple's [remote-notification payload guidance](https://developer.apple.com/documentation/usernotifications/generating-a-remote-notification) and keep user-visible alert content non-sensitive by default. +- **Configure Android Lock-Screen Visibility**: Use [`NotificationCompat.Builder.setVisibility()` and `setPublicVersion()`](https://developer.android.com/develop/ui/views/notifications/build-notification#lockscreenNotification) to modify the presentation of sensitive notifications. Use `VISIBILITY_PRIVATE` together with a generic public version when a redacted notification may be shown, and use `VISIBILITY_SECRET` when the notification should not appear on a secure lock screen. Do not place sensitive data in the title because private notifications may still display basic information including the title. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0030.md b/weaknesses/MASVS-PLATFORM/MASWE-0030.md new file mode 100644 index 00000000..8f520f8b --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0030.md @@ -0,0 +1,38 @@ +--- +title: Insufficient Protection of Sensitive Data from Screenshots or Screen Recordings +id: MASWE-0030 +alias: data-leak-screenshots +requirement: "The app removes or masks sensitive data from its views when moved to the background, when being recorded or when a screenshot is taken." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0030 +attacks: [MAS-ATTACK-0010, MAS-ATTACK-0071, MAS-ATTACK-0072] +mappings: + masvs-v1: [MSTG-STORAGE-9] + masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] + cwe: [200, 359] + maswe-beta: [MASWE-0055] +refs: +- https://developer.android.com/about/versions/14/features/screenshot-detection +--- + +## Overview + +This weakness occurs when sensitive data displayed by an app can be captured in screenshots or screen recordings, and the app does not prevent the capture or conceal or redact the data when such protection is warranted. + +Mobile platforms allow users, privileged apps, and external tools to capture screenshots or record the screen. In addition, when an app enters the background, the system may capture a snapshot of the app's current view for display in the app switcher. Sensitive content that remains visible without appropriate protection can be retained in these images or recordings. + +## Modes of Introduction + +- **Missing Platform Screenshot Protection**: Displaying sensitive fields without applying the related platform protections that can avoid the field information from appearing in screenshots or screen recordings (e.g., in Android, applying the [`FLAG_SECURE`](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_SECURE) flag). +- **Missing Capture-State Redaction**: Continuing to display sensitive information while the app or scene is being recorded, mirrored, or shared, despite the platform providing an API to detect the active capture state. +- **Excessive On-Screen Disclosure**: Displaying complete sensitive values when a masked, partial, temporary, or user-initiated representation would be sufficient for the current task. + +## Impact + +- **Compromise of Sensitive Data**: Sensitive information may be retained in an image or video after the app session ends and may later be viewed, shared, synchronized, backed up, or accessed by another person or service. + +## Mitigations + +- **Redact Sensitive On-Screen Content**: Display only the portion of a sensitive value required for the current task. Mask values by default and unmask the values only for the needed actions, masking them again once they have been used for the task. +- **Anti-Screenshot Platform Protections**: Apply platform protections that prevent elements containing sensitive content from appearing in screenshots or on non-secure displays (for example, in Android, applying the [`FLAG_SECURE`](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_SECURE) flag). diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0031.md b/weaknesses/MASVS-PLATFORM/MASWE-0031.md new file mode 100644 index 00000000..8fc26393 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0031.md @@ -0,0 +1,44 @@ +--- +title: App Vulnerable to Overlay Attacks +id: MASWE-0031 +alias: tapjacking-attacks +requirement: "The app protects its sensitive screens against overlay attacks." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0031 +attacks: [MAS-ATTACK-0036] +mappings: + masvs-v1: [MSTG-PLATFORM-9] + masvs-v2: [MASVS-PLATFORM-3, MASVS-CODE-1] + cwe: [1021] + android-risks: + - tapjacking + maswe-beta: [MASWE-0056] +refs: +- https://developer.android.com/topic/security/risks/tapjacking +--- + +## Overview + +This weakness occurs when an app does not defend its sensitive screens against being fully or partially obscured by attacker-controlled windows. + +In an overlay attack, a malicious app draws content on top of the target app to trick the user into interacting with it (tapjacking) or to capture their input. The user believes they are interacting with the visible overlay while their touches reach the app underneath, or vice versa. Sensitive confirmation screens, permission-like prompts, and input fields are the typical targets. + +## Modes of Introduction + +- **Touch Filtering Not Enabled**: Not enabling touch filtering on sensitive views (e.g. `setFilterTouchesWhenObscured(true)` or `android:filterTouchesWhenObscured="true"`) and not discarding touch events flagged as obscured (e.g. `FLAG_WINDOW_IS_PARTIALLY_OBSCURED`). +- **External Overlays Not Hidden**: Not using `setHideOverlayWindows(true)` to hide external overlays +- **Sensitive Screens Not Protected**: Presenting confirmation dialogs or security-relevant screens without any occlusion defense, so their content can be covered or mimicked by an overlay. + +## Impact + +- **Financial Loss**: Attackers can trick users into confirming payments or transfers they believe to be something else, resulting in direct financial harm to the user. +- **Authentication or Authorization Bypass**: Attackers can trick users into granting permissions or approving security prompts, resulting in unauthorized access to protected data or functionality. +- **Compromise of Sensitive Data**: Attackers can capture input entered into overlay-mimicked fields, resulting in the disclosure of credentials or other sensitive user input. + +## Mitigations + +- **Enable Touch Filtering on Sensitive Views**: Configure sensitive views to ignore touches delivered while the window is obscured, and discard motion events flagged as (partially) obscured. +- **Hide External Overlays**: Configure sensitive activities to hide all external overlays. +- **Protect Sensitive Screens**: Apply overlay defenses to confirmation and authentication screens specifically, and consider pausing or hiding sensitive content when the app detects it is being drawn over. +- **Use Trusted Confirmation Paths for Critical Actions**: For the most critical approvals, use hardware-protected confirmation mechanisms that overlays cannot forge (see @MASWE-0019). diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0032.md b/weaknesses/MASVS-PLATFORM/MASWE-0032.md new file mode 100644 index 00000000..b65cbb06 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0032.md @@ -0,0 +1,45 @@ +--- +title: Insecure Deep Links +id: MASWE-0032 +alias: insecure-deep-links +requirement: "The app securely handles deep links." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0032 +attacks: [MAS-ATTACK-0046, MAS-ATTACK-0047] +mappings: + masvs-v1: [MSTG-PLATFORM-3] + masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2, MASVS-CODE-4] + cwe: [939, 917] + android-risks: + - unsafe-use-of-deeplinks + maswe-beta: [MASWE-0058] +refs: +- https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links +- https://developer.android.com/training/app-links/verify-android-applinks +--- + +## Overview + +This weakness occurs when an app handles deep links insecurely, relying on unverified schemes or trusting the attacker-controllable data they carry. + +Deep links (Android App Links, iOS Universal Links and custom URL schemes) let other apps and websites launch the app, trigger an in-app action and pass parameters. They become insecure when the app relies on custom URL schemes that any app can claim, does not verify App Links or Universal Links through domain association, or fails to validate and sanitize the incoming URL and its parameters. Because deep link input is attacker-controllable, a malformed URI or parameter can trigger injection or logic abuse at various points in the app. + +## Modes of Introduction + +- **Unverified Custom URL Schemes**: Relying on custom URL schemes for sensitive flows even though any installed app can claim the same scheme. +- **Missing Domain Association**: Declaring App Links without `autoVerify` and Digital Asset Links, or Universal Links without a valid apple-app-site-association file, so links are not cryptographically tied to the app's domain. +- **Unvalidated Deep Link Input**: Passing the deep link URL and its parameters into navigation decisions, WebViews, or queries without validation and sanitization. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can intercept tokens or personal data carried in deep links, or exfiltrate data through injected parameters, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can capture authentication material delivered via hijacked links (e.g. login or password-reset links), resulting in account takeover. +- **Execution of Unauthorized Code**: Attackers can inject expressions or script through unsanitized deep link parameters that reach interpreters or WebViews, resulting in attacker-controlled behavior inside the app. + +## Mitigations + +- **Use Verified Link Mechanisms**: Handle sensitive flows only through verified Android App Links (with `autoVerify` and Digital Asset Links) and iOS Universal Links, not through claimable custom schemes. +- **Validate and Sanitize Deep Link Input**: Treat every deep link URL and parameter as untrusted input; validate against an allowlist of expected destinations and value formats before use. +- **Validate the Source Where Possible**: Verify the calling application or referrer for custom scheme invocations when the platform allows it. +- **Keep Secrets Out of Deep Links**: Avoid transporting session tokens or other secrets in links; where unavoidable, make them single-use and short-lived. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0033.md b/weaknesses/MASVS-PLATFORM/MASWE-0033.md new file mode 100644 index 00000000..bfd89276 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0033.md @@ -0,0 +1,47 @@ +--- +title: Improper Use of the Clipboard +id: MASWE-0033 +alias: improper-clipboard +requirement: "The app uses the clipboard securely and only with user consent." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0033 +attacks: [MAS-ATTACK-0041] +mappings: + masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] + cwe: [200, 668] + android-risks: + - secure-clipboard-handling + maswe-beta: [MASWE-0059] +refs: +- https://developer.android.com/develop/ui/views/touch-and-input/copy-paste#PreventingSensitiveData +- https://developer.apple.com/documentation/uikit/uipasteboard +--- + +## Overview + +This weakness occurs when an app places sensitive data on the system clipboard, or handles clipboard content insecurely, exposing that data beyond the app's control. + +The clipboard is a shared resource: other apps can read its contents, and on some platforms, clipboard content synchronizes to nearby devices via a universal clipboard. Copying sensitive data such as passwords, one-time codes, card numbers, or tokens to the clipboard, failing to mark it as sensitive, or leaving it there indefinitely can leak that data to other apps and devices. + +## Modes of Introduction + +- **Sensitive Data Copyable Without User Consent**: Copying sensitive values such as passwords, one-time codes, or card numbers to the clipboard without user consent. +- **Clipboard Content Not Marked Sensitive**: Not flagging copied sensitive content as sensitive where the platform supports it (e.g. `EXTRA_IS_SENSITIVE` on Android), so previews and clipboard history show it in cleartext. +- **Universal Clipboard Not Restricted**: Not restricting sensitive clipboard items to the local device or setting an expiration on iOS, letting them sync to other devices. +- **Clipboard Not Cleared**: Leaving sensitive content on the clipboard after it has served its purpose. +- **Untrusted Clipboard Input**: Processing pasted clipboard data without validation, even though any app can have written it. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can read personal or financial data from the clipboard, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can capture copied credentials or one-time codes, resulting in unauthorized access to the user's accounts. + +## Mitigations + +- **Avoid the Clipboard for Secrets**: Disable copying for sensitive fields and provide secure alternatives such as auto-fill (see @MASWE-0024) so users never need to copy secrets. +- **Only Copy with User Consent**: If copying is required, ask the user for consent before placing sensitive data on the clipboard, or only act as a result of a user-chosen action (e.g. a "Copy" button). +- **Mark Clipboard Content as Sensitive**: When sensitive content must be copied, flag it as sensitive so the platform masks previews and treats it accordingly. +- **Specify an appropriate expiration**: When sensitive content must be copied, set an expiration so it is removed from the clipboard after a short time. +- **Restrict Clipboard Exposure**: When copying, follow the platform's [secure clipboard handling guidance on Android](https://developer.android.com/privacy-and-security/risks/secure-clipboard-handling) and mark the content using [`ClipDescription.EXTRA_IS_SENSITIVE`](https://developer.android.com/reference/android/content/ClipDescription#EXTRA_IS_SENSITIVE) to obscure clipboard previews. On iOS, use pasteboard options such as [`localOnly`](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/localonly) and [`expirationDate`](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/expirationdate) to limit cross-device propagation and content lifetime. +- **Validate Pasted Data**: Treat clipboard content as untrusted input and validate it before use. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0034.md b/weaknesses/MASVS-PLATFORM/MASWE-0034.md new file mode 100644 index 00000000..e51e920b --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0034.md @@ -0,0 +1,41 @@ +--- +title: Allowing Untrusted App Extensions +id: MASWE-0034 +alias: insecure-app-extensions +requirement: "The app only permits trusted app extensions to interact with it." +platform: [ios] +profiles: [L1, L2] +threat: MAS-THREAT-0034 +attacks: [MAS-ATTACK-0048] +mappings: + masvs-v1: [MSTG-PLATFORM-11] + masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] + cwe: [829] + maswe-beta: [MASWE-0061] +refs: +- https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623122-application +- https://developer.apple.com/documentation/uikit/uiapplication/extensionpointidentifier/keyboard +--- + +## Overview + +This weakness occurs when an app allows untrusted app extensions, such as custom keyboards or share and action extensions, to interact with it and observe the data it handles. + +On iOS, app extensions run third-party code that can interact with the host app and observe or exfiltrate the data the app hands to them. A custom keyboard, for example, sees every keystroke typed while it is active. An app that handles sensitive data should restrict which extension point identifiers it allows, for example by implementing `application(_:shouldAllowExtensionPointIdentifier:)` to reject untrusted extension categories, and by disabling third-party keyboards for sensitive input. + +## Modes of Introduction + +- **All Extension Points Allowed**: Not implementing `application(_:shouldAllowExtensionPointIdentifier:)`, so every extension category, including custom keyboards, can interact with the app. +- **Third-Party Keyboards Allowed for Sensitive Input**: Allowing custom keyboards (the `keyboard` extension point) while users enter credentials, payment data, or other secrets. +- **Sensitive Data Handed to Extensions**: Passing more data than necessary to share or action extensions, which can process and transmit it outside the app's control. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can log keystrokes or read content handed to a malicious extension, resulting in unauthorized disclosure of personal data typed into or shared from the app. +- **Authentication or Authorization Bypass**: Attackers can capture credentials or one-time codes typed on a malicious keyboard, resulting in unauthorized access to the user's accounts. + +## Mitigations + +- **Restrict Extension Points**: Implement `application(_:shouldAllowExtensionPointIdentifier:)` and reject extension categories the app does not need to support. +- **Keep Sensitive Input on the System Keyboard**: Disable third-party keyboards for sensitive fields; secure text entry fields automatically use the system keyboard. +- **Minimize Data Shared with Extensions**: Hand share and action extensions only the specific items being shared, never broader app data. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0035.md b/weaknesses/MASVS-PLATFORM/MASWE-0035.md new file mode 100644 index 00000000..ab79c462 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0035.md @@ -0,0 +1,55 @@ +--- +title: Insecure Intents +id: MASWE-0035 +alias: insecure-intents +requirement: "The app securely handles intents." +platform: [android] +profiles: [L1, L2] +threat: MAS-THREAT-0035 +attacks: [MAS-ATTACK-0047, MAS-ATTACK-0049, MAS-ATTACK-0050] +mappings: + masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] + cwe: [927, 940] + android-risks: + - implicit-intent-hijacking + - intent-redirection + - pending-intent + - sender-of-pending-intents + - sticky-broadcast + android-core-app-quality: [Component_Permissions] + maswe-beta: [MASWE-0066] +refs: +- https://support.google.com/faqs/answer/9267555?hl=en +- https://developer.android.com/privacy-and-security/security-tips#intents +- https://developer.android.com/topic/security/risks/intent-redirection +- https://developer.android.com/topic/security/risks/implicit-intent-hijacking +- https://developer.android.com/topic/security/risks/pending-intent +- https://developer.android.com/topic/security/risks/sticky-broadcast +--- + +## Overview + +This weakness occurs when an app creates or handles Android intents insecurely, allowing other apps to intercept, redirect, or manipulate its communication. + +Intents are Android's primary inter- and intra-app messaging mechanism. Insecure handling includes sending sensitive data via implicit intents that any matching app can receive, acting on untrusted intents and their extended data (e.g. calling `startActivity`, `startService`, `sendBroadcast`, or `setResult` on intents received from other apps) without validation, creating PendingIntents that other apps can modify or replay, and using sticky broadcasts, which any app can read and replace. + +## Modes of Introduction + +- **Implicit Intents for Internal Communication**: Using implicit intents, which any matching app can receive, for internal app communication or for carrying sensitive extras. +- **Intent Redirection**: Extracting a nested intent from untrusted extras and forwarding it (e.g. via `startActivity`) without validating its destination, letting other apps reach the app's non-exported components. +- **Mutable PendingIntents**: Creating PendingIntents without `FLAG_IMMUTABLE`, allowing the receiving app to modify the underlying intent and execute it with the app's identity. +- **Replayable PendingIntents**: Creating one-off PendingIntents without `FLAG_ONE_SHOT`, allowing them to be reused. +- **Sticky Broadcasts**: Using [sticky broadcasts](https://developer.android.com/privacy-and-security/risks/sticky-broadcast), which remain accessible after delivery and can be read or replaced by any app. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can receive sensitive extras carried in implicit intents or broadcasts, resulting in unauthorized disclosure of user or app data to other apps. +- **Authentication or Authorization Bypass**: Attackers can reach non-exported components through intent redirection or execute actions with the app's identity through manipulated PendingIntents, resulting in privileged operations performed on the attacker's behalf. + +## Mitigations + +- **Use Explicit Intents Internally**: Address internal communication to explicit component targets so no other app can receive it, and never place sensitive data in implicit intents. +- **Validate Redirected Intents**: Before forwarding a nested intent from untrusted input, validate its destination against an allowlist and strip unexpected flags. +- **Create Immutable, Explicit PendingIntents**: Build PendingIntents with `FLAG_IMMUTABLE` over explicit base intents, and add `FLAG_ONE_SHOT` where a single use is intended. +- **Avoid Sticky Broadcasts**: Use regular broadcasts protected with permissions, or more targeted mechanisms, instead of deprecated sticky broadcasts. +-**Validate Incoming Intent Data**: Treat all extended intent data entering the app through exported components as untrusted. Validate it before further processing (@MASWE-0048). diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0036.md b/weaknesses/MASVS-PLATFORM/MASWE-0036.md new file mode 100644 index 00000000..fcecdb51 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0036.md @@ -0,0 +1,51 @@ +--- +title: Sensitive Native Functionality Exposed in WebViews +id: MASWE-0036 +alias: js-bridges-webviews +requirement: "The app does not expose sensitive native functionality to WebView content." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0036 +attacks: [MAS-ATTACK-0047, MAS-ATTACK-0051] +mappings: + masvs-v1: [MSTG-PLATFORM-7] + masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2] + cwe: [749, 94] + android-risks: + - insecure-webview-native-bridges + android-core-app-quality: [WebView_JavaScript] + maswe-beta: [MASWE-0068] +refs: +- https://support.google.com/faqs/answer/9095419 +- https://developer.android.com/develop/ui/views/layout/webapps/native-api-access-jsbridge +- https://developer.android.com/reference/androidx/webkit/WebViewCompat#addWebMessageListener(android.webkit.WebView,java.lang.String,java.util.Set%3Cjava.lang.String%3E,androidx.webkit.WebViewCompat.WebMessageListener) +- https://developer.apple.com/documentation/webkit/wkscriptmessagehandler +--- + +## Overview + +This weakness occurs when an app exposes sensitive native functionality to content loaded in its WebViews, most commonly through JavaScript bridges. + +Bridges such as [`addWebMessageListener`](https://developer.android.com/reference/androidx/webkit/WebViewCompat#addWebMessageListener%28android.webkit.WebView,java.lang.String,java.util.Set%3Cjava.lang.String%3E,androidx.webkit.WebViewCompat.WebMessageListener%29) on Android and [`WKScriptMessageHandler`](https://developer.apple.com/documentation/webkit/wkscriptmessagehandler) on iOS allow web content to send messages to native code. When these bridges expose more capability than necessary, or are reachable by untrusted content, malicious JavaScript can invoke native functionality, access sensitive data, or perform privileged actions using the app's permissions and privileges. + +## Modes of Introduction + +- **Bridges Reachable by Untrusted Content**: Making bridge interfaces available to any page, origin, or frame the WebView loads instead of restricting them to trusted origins. +- **Unvalidated Bridge Messages**: Accepting message names, arguments, or payloads without validating their structure, types, values, authorization, and expected application state. +- **Globally Exposed Bridge Mechanisms**: Using bridge mechanisms that expose native interfaces broadly across the WebView, such as Android `addJavascriptInterface`, when origin-scoped messaging APIs are available. +- **App-Owned Bridge Scripts in the Page World**: Running injected bridge scripts in the same JavaScript execution world as page content, allowing page scripts, including third-party scripts, to access or interfere with the bridge. +- **Sensitive Data in Bridge Replies**: Returning sensitive data into the WebView JavaScript context in a way that any untrusted scripts can read, regardless of user authentication state. +- **Over-Exposed Bridges**: Exposing more native functionality through the bridge than the web content actually needs. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can call bridge methods that return user or app data, resulting in exfiltration of sensitive information to attacker-controlled servers. +- **Execution of Unauthorized Code**: Attackers can drive native functionality exposed through the bridge, resulting in privileged actions performed within the app's context. + +## Mitigations + +- **Minimize the Bridge Surface**: Expose only the specific methods the web content needs, and strip bridges entirely from WebViews that do not need them. +- **Restrict Bridges to Trusted Origins**: Attach bridges only when loading trusted content and prefer origin-scoped messaging mechanisms over global bridges. +- **Validate Bridge Messages**: Treat every message arriving over the bridge as untrusted input and validate it before acting on it. +- **Prefer Modern Messaging APIs**: On Android, prefer [`WebViewCompat.addWebMessageListener`](https://developer.android.com/reference/androidx/webkit/WebViewCompat#addWebMessageListener%28android.webkit.WebView,java.lang.String,java.util.Set,androidx.webkit.JavaScriptExecutionWorld,androidx.webkit.WebViewCompat.WebMessageListener%29) over the legacy [`WebView.addJavascriptInterface`](https://developer.android.com/reference/android/webkit/WebView#addJavascriptInterface%28java.lang.Object,java.lang.String%29). On iOS, use [`WKScriptMessageHandlerWithReply`](https://developer.apple.com/documentation/webkit/wkscriptmessagehandlerwithreply) when JavaScript requires a native response, and use [`WKScriptMessageHandler`](https://developer.apple.com/documentation/webkit/wkscriptmessagehandler) for one way messages. +- **Isolate App-Owned Bridge Scripts**: When the bridge is intended only for app-injected JavaScript, register the handler and injected script in a named execution world. Use [`JavaScriptExecutionWorld`](https://developer.android.com/reference/androidx/webkit/JavaScriptExecutionWorld) on Android and [`WKContentWorld`](https://developer.apple.com/documentation/webkit/wkcontentworld) on iOS, where supported. Keep origin restrictions, frame checks, and message validation in place, because execution world isolation is not origin authorization. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0037.md b/weaknesses/MASVS-PLATFORM/MASWE-0037.md new file mode 100644 index 00000000..2c76afba --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0037.md @@ -0,0 +1,45 @@ +--- +title: WebViews Allow Access to Local Resources with Untrusted Content +id: MASWE-0037 +alias: webviews-local-resources +requirement: "The app only allows trusted WebView content to access local resources." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0037 +attacks: [MAS-ATTACK-0047, MAS-ATTACK-0051] +mappings: + masvs-v1: [MSTG-PLATFORM-6] + masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2, MASVS-CODE-4] + cwe: [22, 79, 200, 669] + android-risks: + - webview-unsafe-file-inclusion + android-core-app-quality: [WebView_Asset_Loader] + maswe-beta: [MASWE-0069, MASWE-0073] +refs: +- https://blog.oversecured.com/Android-Exploring-vulnerabilities-in-WebResourceResponse/ +--- + +## Overview + +This weakness occurs when a WebView is configured to access local resources while also rendering untrusted content, allowing that content to reach files and data outside the web sandbox. + +Settings that enable file or content access (e.g. `setAllowFileAccess`, `setAllowFileAccessFromFileURLs`, `setAllowUniversalAccessFromFileURLs`, `setAllowContentAccess` on Android, or overly broad file read access grants on iOS) let JavaScript running in the WebView read app-private files, traverse the filesystem, or exfiltrate data. Insecure custom resource loading, such as serving internal files through a hand-rolled `WebResourceResponse` instead of a safe asset loader, can likewise expose protected files to the less-trusted WebView JavaScript context or serve attacker-controllable content from the app's own origin. + +## Modes of Introduction + +- **File Access Enabled with Untrusted Content**: Enabling file or content access settings on WebViews that also render untrusted or externally influenced content. +- **Universal Access from File URLs**: Allowing universal or file-URL cross-origin access, so a local HTML file can read other local files and send them to remote origins. +- **Insecure Custom Resource Loading**: Serving internal files through custom response handlers without path validation, instead of a dedicated asset-loading mechanism with a restricted scope. +- **Overly Broad File Read Grants**: Granting the WebView read access to broader directories than the specific content it needs to display. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can read and exfiltrate app-private files, such as databases, preferences, or cached tokens, resulting in unauthorized disclosure of user and app data. +- **Authentication or Authorization Bypass**: Attackers can steal session material stored in reachable files or WebView storage, resulting in account takeover. + +## Mitigations + +- **Disable File and Content Access**: Keep file, file-URL, and content access settings disabled unless strictly required, and never combine them with untrusted content. +- **Use a Safe Asset Loader**: Serve local app resources through a dedicated asset-loading mechanism with a fixed, validated scope instead of custom response handlers over arbitrary paths. +- **Scope File Read Access Narrowly**: When loading local files, grant read access only to the specific file or directory being displayed. +- **Separate Trusted and Untrusted Content**: Render untrusted content only in WebViews with no local resource access and no privileged configuration. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0038.md b/weaknesses/MASVS-PLATFORM/MASWE-0038.md new file mode 100644 index 00000000..0bc1b90b --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0038.md @@ -0,0 +1,48 @@ +--- +title: WebViews Loading Untrusted Content +id: MASWE-0038 +alias: webviews-untrusted-content +requirement: "The app only allows trusted content in WebViews." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0038 +attacks: [MAS-ATTACK-0047, MAS-ATTACK-0051] +mappings: + masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] + cwe: [79, 601, 829] + android-risks: + - cross-app-scripting + - unsafe-uri-loading + maswe-beta: [MASWE-0071, MASWE-0070, MASWE-0072] +refs: +- https://blog.oversecured.com/Evernote-Universal-XSS-theft-of-all-cookies-from-all-sites-and-more/ +--- + +## Overview + +This weakness occurs when a WebView loads URLs, HTML, or JavaScript from untrusted sources, or lets users navigate to arbitrary sites outside the developer's control. + +WebViews run with app-specific privileges and often use JavaScript bridges (see @MASWE-0036) to communicate between the web sandbox and the app to access contacts, local files, the device location, or its camera. Loading untrusted content into WebViews is therefore more dangerous than opening it in an external browser. + +A URL received via an intent or deep link, or JavaScript fetched from an unverified source, can lead to cross-site scripting, including Universal XSS, allowing an attacker to steal cookies and tokens from any site, perform phishing attacks, or trigger drive-by downloads. Actors can also access functionality outside the web sandbox using JavaScript bridges declared by the developers. + +## Modes of Introduction + +- **Unrestricted Navigation**: Not restricting which origins the WebView may load (e.g. via `WebViewClient.shouldOverrideUrlLoading` or navigation delegates), letting users or content navigate anywhere directly, or loading domains that can be used to navigate to attacker-controlled domains. +- **Untrusted URLs from External Input**: Loading URLs received through intents, deep links, or other external input without validating them against an allowlist. +- **Untrusted Script Inclusion**: Loading JavaScript from unverified sources into pages rendered by the WebView. +- **Safe Browsing Disabled**: Disabling platform protections such as Safe Browsing that warn about known-malicious sites. +- **Deprecated WebView Components**: Using deprecated WebView implementations that lack modern process isolation and security protections. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can steal cookies, tokens, or displayed data from any origin via cross-site scripting in the privileged WebView, resulting in unauthorized disclosure of session material and user data. +- **Authentication or Authorization Bypass**: Attackers can reuse stolen session cookies or tokens, resulting in account takeover across the sites the WebView had sessions with. +- **Loss of User Trust**: Attackers can render phishing pages or trigger unwanted downloads inside the app's own UI, resulting in users being deceived under the app's identity and reputational damage for the app owner. + +## Mitigations + +- **Allowlist Navigation**: Restrict the WebView to an allowlist of trusted origins and open everything else in the system browser. +- **Validate Externally Supplied URLs**: Treat URLs arriving via intents or deep links as untrusted input and validate them before loading (see @MASWE-0038). +- **Load Scripts Only from Trusted Sources**: Never inject or include JavaScript fetched from unverified sources. +- **Keep Platform Protections Enabled**: Leave Safe Browsing and equivalent protections enabled and use current, supported WebView components. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0039.md b/weaknesses/MASVS-PLATFORM/MASWE-0039.md new file mode 100644 index 00000000..99088bf9 --- /dev/null +++ b/weaknesses/MASVS-PLATFORM/MASWE-0039.md @@ -0,0 +1,45 @@ +--- +title: Sensitive Data Leaked via Accessibility Services +id: MASWE-0039 +alias: data-leak-accessibility +requirement: "The app prevents sensitive data from being exposed to, or captured by, accessibility services." +platform: [android, ios] +profiles: [L2] +threat: MAS-THREAT-0039 +attacks: [MAS-ATTACK-0052] +mappings: + masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] + cwe: [200, 359] +refs: +- https://developer.android.com/guide/topics/ui/accessibility/service +- https://support.google.com/googleplay/android-developer/answer/10964491 +- https://developer.apple.com/documentation/uikit/uiaccessibility +--- + +## Overview + +This weakness occurs when an app exposes sensitive data to accessibility APIs beyond what is necessary, making it harvestable by malicious or overly privileged accessibility services. + +Accessibility services (e.g. Android's `AccessibilityService`) can observe screen content, read the text of on-screen nodes, and receive UI events across apps. This power is essential for assistive technology, but it also makes accessibility a common exfiltration and automation vector for malware: a malicious service that the user was tricked into enabling can harvest passwords, one-time codes, messages, and other personal data, and even drive the UI. Apps handling sensitive data should minimize what is exposed through accessibility metadata without degrading accessibility for legitimate users. + +## Modes of Introduction + +- **Secrets in Accessibility Metadata**: Exposing sensitive values through accessibility node text, labels, or hints beyond what assistive technology needs. +- **Sensitive Fields Not Using Secure Input**: Presenting secret input in fields that are not marked as password/secure entry, so their content is readable through accessibility APIs. +- **High-Risk Flows Fully Automatable**: Designing sensitive flows (e.g. payments) so that they can be completed entirely through programmatic UI interaction without any additional verification. +- **System Keyboards Exposing Sensitive Input**: Relying on standard system keyboards for passcode or PIN entry, which allows keyboard events and typed credentials to be captured by accessibility services. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can read messages, personal data, and financial details from on-screen content, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can harvest credentials and one-time codes as they are displayed or entered, resulting in account takeover. +- **Financial Loss**: Attackers can combine harvested data with accessibility-driven UI automation to initiate fraudulent transactions, resulting in direct financial harm to the user. + +## Mitigations + +- **Keep Secrets Out of Accessibility Metadata**: Do not place sensitive values in accessibility labels, hints, or node text beyond what assistive technology requires. +- **Use Secure Input Fields**: Mark secret fields as password/secure entry so platforms mask their content from accessibility reading. +- **Add Friction to High-Risk Flows**: Require verification that UI automation cannot satisfy (e.g. biometric-bound confirmation, see @MASWE-0021) for the most sensitive actions. +- **Preserve Legitimate Accessibility**: Minimize only the sensitive values exposed; never degrade the app's overall accessibility for assistive-technology users. +- **Use Custom Passcode Inputs**: Replace standard system keyboards with an in-app custom keypad for sensitive entry fields, preventing accessibility services from capturing or announcing typed credentials. +- **Use Custom Passcode Inputs**: Replace standard system keyboards with an in-app custom keypad for sensitive entry fields, preventing accessibility services from capturing or announcing typed credentials. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0053.md b/weaknesses/MASVS-PLATFORM/MASWE-0053.md deleted file mode 100644 index b0a068ea..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0053.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Sensitive Data Leaked via the User Interface -id: MASWE-0053 -alias: data-leak-ui -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-STORAGE-7] - masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] - cwe: [200, 359] - -draft: - description: e.g. leaking passwords, PINs via the UI - topics: - - secureText - - copy/paste disabled - - auto-correct - - etc. -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0054.md b/weaknesses/MASVS-PLATFORM/MASWE-0054.md deleted file mode 100644 index a22019aa..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0054.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Sensitive Data Leaked via Notifications -id: MASWE-0054 -alias: data-leak-notifications -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] - cwe: [200, 359] - -draft: - description: e.g. stealing pending intents from notifications via notificationlistenerservice - or tapjacking wire transfer UI. - topics: - - NotificationListenerService -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0055.md b/weaknesses/MASVS-PLATFORM/MASWE-0055.md deleted file mode 100644 index b11baac2..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0055.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: Sensitive Data Leaked via Screenshots or Screen Recordings -id: MASWE-0055 -alias: data-leak-screenshots -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-STORAGE-9] - masvs-v2: [MASVS-PLATFORM-3, MASVS-STORAGE-2] - cwe: [200, 359] - -refs: -- https://developer.android.com/about/versions/14/features/screenshot-detection -status: new - ---- - -## Overview - -Mobile platforms allow users and third-party tools to capture screenshots or record screens. This can expose sensitive data and increase the risk of data leakage. - -There are several ways an attacker may obtain this sensitive data: - -- **Third-party apps with permission to capture or record the screen**: Third-party apps may record the screen while sensitive content is displayed. -- **Third-party apps with permission to access the screenshot and recording files**: Third-party apps may access screenshots or recordings saved in storage after they are taken by the user or a tool. -- **External tools may record the screen**: Tools such as @MASTG-TOOL-0024 and @MASTG-TOOL-0126 can record the device's screen via a USB connection. -- **Automatic Screenshots when Backgrounding**: When an app enters the background state, the system may capture a screenshot of the app's current view to display in the app switcher. These screenshots are stored on the file system and could potentially be accessed or stolen by malicious actors. - -## Impact - -- **Loss of Confidentiality**: Under certain conditions, an attacker could access sensitive data previously displayed on the screen, potentially compromising confidentiality and enabling further attacks, such as identity theft or account takeover. - -## Modes of Introduction - -This can typically occur in two ways: - -- **Screenshots and Screen Recordings Not Prevented:** The app does not implement measures (such as setting secure window flags) to prevent the operating system or other apps from capturing screenshots or screen recordings. -- **Unredacted Sensitive On-Screen Content:** The app displays sensitive information directly on the screen without masking or redacting it, allowing confidential data to be visible if a screenshot or screen recording is taken. - -## Mitigations - -- Prevent screenshots and screen recording. -- Redact sensitive on-screen content so that, if a screenshot is taken, no confidential data is visible. diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0056.md b/weaknesses/MASVS-PLATFORM/MASWE-0056.md deleted file mode 100644 index d2f97029..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0056.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Tapjacking Attacks -id: MASWE-0056 -alias: tapjacking-attacks -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-PLATFORM-9] - masvs-v2: [MASVS-PLATFORM-3, MASVS-CODE-1] - cwe: [1021] - -refs: -- https://developer.android.com/topic/security/risks/tapjacking -draft: - description: not using View.setFilterTouchesWhenObscured(true) or android:filterTouchesWhenObscured="true" - in the AndroidManifest.xml or not ignoring touch events that have FLAG_WINDOW_IS_PARTIALLY_OBSCURED - flag - topics: - - Full occlusion - - Partial occlusion -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0057.md b/weaknesses/MASVS-PLATFORM/MASWE-0057.md deleted file mode 100644 index bc36fc3d..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0057.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: StrandHogg Attack / Task Affinity Vulnerability -id: MASWE-0057 -alias: strandhogg-attack -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-3] - cwe: [451, 1104] - -refs: -- https://developer.android.com/topic/security/risks/strandhogg -draft: - description: This vulnerability is exploited by manipulating the allowTaskReparenting - and taskAffinity settings. - topics: - - StrandHogg Attack v1 - - StrandHogg Attack v2 -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0058.md b/weaknesses/MASVS-PLATFORM/MASWE-0058.md deleted file mode 100644 index a917e8b5..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0058.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Insecure Deep Links -id: MASWE-0058 -alias: insecure-deep-links -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-3] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2, MASVS-CODE-4] - cwe: [939, 917] - -draft: - description: e.g. use of URL Custom Schemes, unverified AppLinks/Universal Links, - not validating URLs. Deep Link parameters offers a wide range of possibilities. A malformed URI or parameter value, if not sanitized, may trigger an injection in different points of the application. For example, CWE-939 prevents the exploit of the URI checking the source and CWE-917 prevents the exploit of the URI checking the content. - topics: - - URL Custom Schemes - - AppLinks - - Universal Links - - URL validation - - Check for OS version. e.g. deep link are more secure after Android XX -refs: -- https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0059.md b/weaknesses/MASVS-PLATFORM/MASWE-0059.md deleted file mode 100644 index 860924a5..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0059.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Use Of Unauthenticated Platform IPC -id: MASWE-0059 -alias: unauthenticated-ipc -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [287, 668, 200] - -draft: - description: e.g. (ab)using the clipboard or using localhost server for IPC - topics: - - (ab)using the clipboard - - using localhost server -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0060.md b/weaknesses/MASVS-PLATFORM/MASWE-0060.md deleted file mode 100644 index 4d03249f..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0060.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Insecure Use of UIActivity -id: MASWE-0060 -alias: insecure-uiactivity -platform: [ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [200, 285, 358] - -draft: - description: e.g. data (items) being shared, custom activities, excluded activity - types. More examples include CWE-285 and CWE-200 for exposing UIActivity information to untrusted apps or actors. CWE-358 for possible bad activityViewController implemented in the UIActivity. - topics: - - data (items) being shared - - custom activities - - excluded activity types -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0061.md b/weaknesses/MASVS-PLATFORM/MASWE-0061.md deleted file mode 100644 index 8a5e7de0..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0061.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Insecure Use of App Extensions -id: MASWE-0061 -alias: insecure-app-extensions -platform: [ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-11] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [200] - -draft: - description: restricting use of certain extensions - topics: - - restricting use of certain extensions via `application:shouldAllowExtensionPointIdentifier:` - - Third-Party Keyboards Not Disabled via UIApplicationKeyboardExtensionPointIdentifier -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0062.md b/weaknesses/MASVS-PLATFORM/MASWE-0062.md deleted file mode 100644 index 445e972a..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0062.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Insecure Services -id: MASWE-0062 -alias: insecure-services -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-4] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [926] - -refs: -- https://developer.android.com/privacy-and-security/security-tips#Services -- https://developer.android.com/guide/topics/manifest/service-element -- https://developer.android.com/reference/android/app/Service -- https://developer.android.com/privacy-and-security/security-tips#binder-and-messenger-interfaces -draft: - description: Unintentionally exported services, unrestricted permissions. Exposed - binders e.g not using checkCallingPermission() to verify whether the caller has - a required permission. - topics: - - Services - - Exposed Binders via Exported Services -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0063.md b/weaknesses/MASVS-PLATFORM/MASWE-0063.md deleted file mode 100644 index aa350d47..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0063.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Insecure Broadcast Receivers -id: MASWE-0063 -alias: insecure-broadcast-receivers -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-4] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [925, 926] - -refs: -- https://developer.android.com/guide/components/broadcasts#security-and-best-practices -- https://developer.android.com/topic/security/risks/sticky-broadcast -- https://developer.android.com/privacy-and-security/security-tips#BroadcastReceivers -draft: - description: Unintentionally exported broadcast receivers, unrestricted permissions, - sticky broadcasts. - topics: - - Unintentionally exported broadcast receivers - - Unrestricted permissions - - Sticky broadcasts -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0064.md b/weaknesses/MASVS-PLATFORM/MASWE-0064.md deleted file mode 100644 index 9731a5b4..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0064.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Insecure Content Providers -id: MASWE-0064 -alias: insecure-content-providers -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-STORAGE-6] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-1] - cwe: [926] - -refs: -- https://developer.android.com/topic/security/risks/content-resolver -- https://developer.android.com/reference/androidx/core/content/FileProvider -- https://developer.android.com/topic/security/risks/file-providers -- https://developer.android.com/privacy-and-security/security-tips#ContentProviders -draft: - description: Unintentionally exported content providers, unprotected content providers, - permission tags, protection level - topics: - - file-system based - - FileProvider (Android) - - database based - - exposed - - permission tags - - protection level -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0065.md b/weaknesses/MASVS-PLATFORM/MASWE-0065.md deleted file mode 100644 index 5f0b2c27..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0065.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Sensitive Data Permanently Shared with Other Apps -id: MASWE-0065 -alias: sensitive-data-shared-other-apps -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-STORAGE-6] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-1] - cwe: [200, 276, 732] - -refs: -- https://developer.android.com/topic/security/risks/content-resolver -- https://developer.android.com/reference/androidx/core/content/FileProvider -- https://developer.android.com/topic/security/risks/file-providers -- https://developer.android.com/privacy-and-security/security-tips#ContentProviders -draft: - description: Provide clients one-time access to data. For example using URI permission - grant flags and content provider permissions to display an app's PDF file in a - separate PDF Viewer app. - topics: - - content providers - - FLAG_GRANT_READ_URI_PERMISSION - - FLAG_GRANT_WRITE_URI_PERMISSION - - FLAG_GRANT_PERSISTABLE - - content URIs - - file URIs -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0066.md b/weaknesses/MASVS-PLATFORM/MASWE-0066.md deleted file mode 100644 index 026a7ce0..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0066.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Insecure Intents -id: MASWE-0066 -alias: insecure-intents -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [927, 940] - -refs: -- https://support.google.com/faqs/answer/9267555?hl=en -- https://developer.android.com/privacy-and-security/security-tips#intents -- https://developer.android.com/topic/security/risks/intent-redirection -- https://developer.android.com/topic/security/risks/implicit-intent-hijacking -- https://developer.android.com/topic/security/risks/pending-intent -draft: - description: e.g. calling startActivity, startService, sendBroadcast, or setResult - on untrusted Intents without validating or sanitizing these Intents. Using an - implicit intent to start a service is a security hazard, because you can't be - certain what service will respond to the intent and the user can't see which service - starts. e.g. mutable pending intents (not using FLAG_IMMUTABLE), replaying pending - intents (not using FLAG_ONE_SHOT) - topics: - - Insecure Intent Redirection - - Insecure Implicit Intents - - Insecure Pending Intents (Mutable, Replaying) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0068.md b/weaknesses/MASVS-PLATFORM/MASWE-0068.md deleted file mode 100644 index a5339ffb..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0068.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: JavaScript Bridges in WebViews -id: MASWE-0068 -alias: js-bridges-webviews -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-7] - masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2] - cwe: [749, 94] - -refs: -- https://support.google.com/faqs/answer/9095419 -draft: - description: via addJavascriptInterface - topics: - - addJavascriptInterface -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0069.md b/weaknesses/MASVS-PLATFORM/MASWE-0069.md deleted file mode 100644 index 444c79c0..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0069.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: WebViews Allows Access to Local Resources -id: MASWE-0069 -alias: webviews-local-resources -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-6] - masvs-v2: [MASVS-PLATFORM-2, MASVS-STORAGE-2] - cwe: [200, 22] - android-risks: - - https://developer.android.com/privacy-and-security/risks/webview-unsafe-file-inclusion - -draft: - description: use of setAllowFileAccessFromFileURLs. Mitigations include setAllowFileAccess(false), - setAllowContentAccess(false) - topics: - - universal file access - - restrict content access - - handlers e.g. file:// vs content:// -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0070.md b/weaknesses/MASVS-PLATFORM/MASWE-0070.md deleted file mode 100644 index f27415d5..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0070.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: JavaScript Loaded from Untrusted Sources -id: MASWE-0070 -alias: js-untrusted-sources -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] - cwe: [79, 829] - -draft: - description: e.g. not validating the source of the JavaScript code - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0071.md b/weaknesses/MASVS-PLATFORM/MASWE-0071.md deleted file mode 100644 index c660260e..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0071.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: WebViews Loading Content from Untrusted Sources -id: MASWE-0071 -alias: webviews-untrusted-content -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] - cwe: [601] - -draft: - description: WebView objects shouldn't load URLs from untrusted sources. Also, your - app shouldn't let users navigate to sites that are outside of your control. Whenever - possible, use an allowlist to restrict the content loaded by your app's WebView - objects e.g. via WebViewClient.shouldOverrideUrlLoading - topics: - - not restricting navigation - - not using SafeBrowsing - - loading URL from untrusted sources e.g. intents or deep links -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0072.md b/weaknesses/MASVS-PLATFORM/MASWE-0072.md deleted file mode 100644 index 9ca01796..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0072.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Universal XSS -id: MASWE-0072 -alias: universal-xss -platform: [android, ios] -profiles: [L1, L2] -mappings: - masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] - cwe: [79] - -refs: -- https://hackerone.com/reports/532836 -- https://www.cybersecurity-help.cz/vdb/SB2021110227 -- https://cwe.mitre.org/data/definitions/79.html -- https://blog.oversecured.com/Evernote-Universal-XSS-theft-of-all-cookies-from-all-sites-and-more/ -draft: - description: Successful exploitation of this vulnerability may allow a remote attacker - to steal potentially sensitive information, change appearance of a web page, perform - phishing and drive-by-download attacks. - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0073.md b/weaknesses/MASVS-PLATFORM/MASWE-0073.md deleted file mode 100644 index 33a94683..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0073.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Insecure WebResourceResponse Implementations -id: MASWE-0073 -alias: insecure-webresourceresponse -platform: [android] -profiles: [L2] -mappings: - masvs-v2: [MASVS-PLATFORM-2, MASVS-CODE-4] - cwe: [79, 200, 669] - -refs: -- https://blog.oversecured.com/Android-Exploring-vulnerabilities-in-WebResourceResponse/ -draft: - description: Using WebResourceResponse instead of WebViewAssetLoader - topics: - - Since WebResourceResponse may serve attacker‑controlled HTML/JS, it enables XSS when content isn’t properly sanitized (CWE-79). - - If an app exposes arbitrary files via XHR in the WebView context, it may be leaking private data (CWE-200). - - Data or files from a protected internal sphere (such as app-private storage) are exposed to a less trusted sphere, like WebView's JavaScript context or external websites (CWE-669). -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0074.md b/weaknesses/MASVS-PLATFORM/MASWE-0074.md deleted file mode 100644 index c3a78f20..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0074.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Web Content Debugging Enabled -id: MASWE-0074 -alias: web-content-debugging -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v2: [MASVS-PLATFORM-2, MASVS-RESILIENCE-4] - cwe: [489] - -refs: -- https://developer.android.com/reference/android/webkit/WebView#setWebContentsDebuggingEnabled(boolean) -- https://developer.apple.com/documentation/webkit/wkwebview/4111163-isinspectable -draft: - description: using setWebContentsDebuggingEnabled in Android or WKWebView.isInspectable - on iOS - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0118.md b/weaknesses/MASVS-PLATFORM/MASWE-0118.md deleted file mode 100644 index f6658416..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0118.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Sensitive Data Not Removed After Use -id: MASWE-0118 -alias: data-minimisation -platform: [android, ios] -profiles: [P] -mappings: - masvs-v2: [MASVS-PRIVACY-1] - -refs: - - https://mas.owasp.org/MASTG/knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0018/#webviews-cleanup - - https://developer.android.com/privacy-and-security/security-tips?hl=en#WebView - - https://developer.apple.com/documentation/webkit/wkwebsitedatastore -draft: - description: | - Applying data minimisation, including appropriate cleanup in the end of the lifecycle is important. - - 1. Clear web state or prefer non-persistent web stores - - - Android: - - `CookieManager.getInstance().removeAllCookies(ValueCallback)` - - `WebStorage.getInstance().deleteAllData()` - - `WebViewDatabase.getInstance(context).clearHttpAuthUsernamePassword()` - - - iOS: - - `WKWebsiteDataStore.default().removeData(ofTypes: WKWebsiteDataStore.allWebsiteDataTypes(), modifiedSince: Date.distantPast)` - - Use `WKWebsiteDataStore.nonPersistent()` for private sessions - - `HTTPCookieStorage.shared.removeCookies(since: .distantPast)` - - Use `WKHTTPCookieStore` for targeted cookie deletion - - 2. Clear app cache and files - - - Android: - - `context.cacheDir.deleteRecursively()` - - `context.filesDir.deleteRecursively()` - - `context.deleteDatabase(name)` for temporary databases - - `SharedPreferences.edit().clear().apply()` to remove tokens or user data - - - iOS: - - Remove items in `NSTemporaryDirectory()` and the Caches folder using `FileManager.default.removeItem(at:)` - - For Core Data, call `NSPersistentStoreCoordinator.destroyPersistentStore(at:ofType:options:)` for a full wipe - - Reset `UserDefaults` with `removePersistentDomain(forName:)` - - 3. Avoid network caches - - - Android: - - `HttpResponseCache.getInstalled()?.delete()` for legacy stack - - For OkHttp: `okHttpClient.cache?.evictAll()` or disable caching with `CacheControl.FORCE_NETWORK` - - - iOS: - - `URLCache.shared.removeAllCachedResponses()` - - Disable caching via `URLSessionConfiguration.urlCache = nil` or set `requestCachePolicy = .reloadIgnoringLocalCacheData` - - `URLSession.invalidateAndCancel()` to clear in-memory session state - - topics: - - webview - - webview-cleanup - - caches - - data-minimisation - - cleanup -status: placeholder - ---- diff --git a/weaknesses/MASVS-PLATFORM/MASWE-0119.md b/weaknesses/MASVS-PLATFORM/MASWE-0119.md deleted file mode 100644 index 7a8b17c8..00000000 --- a/weaknesses/MASVS-PLATFORM/MASWE-0119.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Insecure Activities -id: MASWE-0119 -alias: insecure-activities -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-PLATFORM-4] - masvs-v2: [MASVS-PLATFORM-1, MASVS-STORAGE-2] - cwe: [926] - -refs: -- https://developer.android.com/privacy-and-security/security-tips#intents -- https://developer.android.com/guide/topics/manifest/activity-element -- https://developer.android.com/reference/android/app/Activity -draft: - description: Unintentionally exported ativities, unrestricted permissions. - topics: - - Activities -status: placeholder - ---- - diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0065.md b/weaknesses/MASVS-PRIVACY/MASWE-0065.md new file mode 100644 index 00000000..93a8af29 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0065.md @@ -0,0 +1,46 @@ +--- +title: Lack of Anonymization or Pseudonymisation Measures +id: MASWE-0065 +alias: anonymization-pseudonymization-measures +requirement: "The app uses anonymization or pseudonymisation measures." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0065 +attacks: [MAS-ATTACK-0074, MAS-ATTACK-0078] +mappings: + masvs-v2: [MASVS-PRIVACY-2] + cwe: [359] + maswe-beta: [MASWE-0109] +refs: +- https://cloud.google.com/sensitive-data-protection/docs/classification-redaction +- https://gdpr-info.eu/recitals/no-26/ +- https://gdpr-info.eu/recitals/no-28/ +- https://gdpr-info.eu/art-4-gdpr/ +- https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en +- https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf +- https://www.statista.com/topics/9460/app-tracking-and-mobile-privacy/ +--- + +## Overview + +This weakness occurs when an app processes or shares user data without applying anonymization, or pseudonymization measures allowing individuals to be identified and potentially tracked across different services and over time. + +Anonymization uses techniques such as randomization or generalization to irreversibly prevent identification. Pseudonymization replaces identifiable data with tokens or hashed values, but may remain reversible when additional information is available. + +## Modes of Introduction + +- **Identifiers Not Removed**: Failing to remove or transform identifiers, such as user ID or name, before server-side collection. +- **Pseudonymization Implemented Insecurely**: Using predictable or stable hashes, reusing pseudonyms across unrelated contexts, or storing keys or mapping data together with the pseudonymized data. +- **Sensitive Metadata Not Removed**: Failing to remove private or sensitive metadata, such as geolocation from Exif data, before server-side collection. +- **Sensitive Data Not Redacted Before Sending to AI Services**: Sending unredacted sensitive or personal data to AI services. + +## Impact + +- **Violation of User Privacy**: Third parties can profile users and target them with advertising without consent, resulting in the loss of users' control over their personal information, retention and its unforeseen use, e.g. to train AI models. +- **Legal and Regulatory Non-Compliance**: Processing personal data without de-identification safeguards can violate data protection laws and regulations (like GDPR), resulting in legal consequences and fines for the app owner. +- **Loss of User Trust**: Unexpected identification, tracking, or secondary use of personal data can reduce user confidence in the app. + +## Mitigations + +- **Use Anonymisation and Pseudonymisation**: Ensure techniques like anonymisation and pseudonymisation are implemented to prevent user identification. +- **Redact Sensitive Data Before Sending to AI Services**: Before sending data to AI services, redact or mask sensitive fields and identifiers so that personal data is not exposed to (or used to train) third-party models. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0110.md b/weaknesses/MASVS-PRIVACY/MASWE-0066.md similarity index 54% rename from weaknesses/MASVS-PRIVACY/MASWE-0110.md rename to weaknesses/MASVS-PRIVACY/MASWE-0066.md index 0dffb1cc..5952b775 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0110.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0066.md @@ -1,13 +1,17 @@ --- -title: Use of Unique Identifiers for User Tracking -id: MASWE-0110 +title: Incorrect Use of Identifiers for User Tracking +id: MASWE-0066 alias: unique-identifiers-user-tracking -platform: ["android", "ios"] -profiles: ["P"] +requirement: "The app does not use persistent or unique identifiers in a way that enables user tracking." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0066 +attacks: [MAS-ATTACK-0074, MAS-ATTACK-0077] mappings: - masvs-v1: [] masvs-v2: [MASVS-PRIVACY-2] cwe: [359] + android-core-app-quality: [Hardware_IDs] + maswe-beta: [MASWE-0110] refs: - https://developer.android.com/reference/android/provider/Settings.Secure#ANDROID_ID - https://developer.android.com/privacy-and-security/about#resettable-identifiers @@ -23,36 +27,34 @@ refs: - https://developer.apple.com/app-store/ad-attribution/ - https://developer.apple.com/documentation/adattributionkit - https://gdpr-info.eu/recitals/no-30/ - -status: new --- ## Overview -User tracking in mobile applications involves collecting and analyzing data to monitor user behavior, preferences, and movements. This enables companies to recognize and follow users over time and across different apps, devices, and services. Such tracking often occurs without the user's explicit knowledge or consent, leading to significant privacy concerns. +This weakness occurs when an app uses persistent or unique identifiers in a way that enables users to be recognized and followed over time and across different apps, devices, and services, often without their knowledge or consent. -Mobile apps commonly include embedded utilities or third-party SDKs from companies like Google, Meta (formerly Facebook), X (formerly Twitter), and others. Examples of these utilities include analytics tools, ad networks, and social media integration components. These components can collect data not directly related to the app's functionality, potentially accessing sensitive information like contact lists or location history, depending on the permissions granted. Pre-installed apps by device manufacturers can further complicate the issue, as they may engage in invasive data collection without users' knowledge. +Mobile apps commonly include embedded utilities or third-party SDKs, such as analytics tools, ad networks, and social media integration components, from companies like Google or Meta. These components can collect data not directly related to the app's functionality, potentially accessing sensitive information like contact lists or location history, depending on the permissions granted. Pre-installed apps by device manufacturers can further complicate the issue, as they may engage in invasive data collection without users' knowledge. -One common method of tracking is through the use of unique identifiers, especially those that cannot be reset. When combined with data from multiple apps, these identifiers can be used to create detailed profiles of individuals—estimating interests, health status, sexual orientation, and other personal attributes. This information can be utilized for targeted advertising, personalized content delivery, or even to influence political opinions. +Unique identifiers, especially those that cannot be reset, are a key enabler of this tracking. When combined with data from multiple apps, they can be used to create detailed profiles of individuals, estimating interests, health status, sexual orientation, and other personal attributes, which can then be used for targeted advertising, personalized content delivery, or even to influence political opinions. ## Modes of Introduction -- **Use of Non-Resettable Identifiers**: Utilizing identifiers that cannot be reset by the user, such as device IDs, hardware serial numbers, or MAC addresses, can lead to persistent tracking without user consent. For example, the [ANDROID_ID](https://developer.android.com/reference/android/provider/Settings.Secure#ANDROID_ID) before Android 8.0 (API level 26) was a non-resettable identifier randomly generated at first boot, while in recent versions it's unique to each combination of app-signing key, user, and device. -- **Misuse of Resettable Identifiers**: Using [resettable identifiers](https://developer.android.com/privacy-and-security/about#resettable-identifiers) like the [Advertising ID](https://developer.android.com/identity/user-data-ids#advertising-ids) on Android or [Advertising Identifier (aka. Identifier for Advertiseers or IDFA)](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) on iOS without respecting user preferences or obtaining proper consent can lead to unauthorized tracking. -- **Linking Identifiers Across Services**: Linking identifiers across different services or apps to create a unified profile of a user, even after a reset or reinstall. This can be done by combining identifiers from different sources, such as device IDs, advertising IDs, or other unique identifiers as well as behavioral data. +- **Use of Non-Resettable Identifiers**: Utilizing identifiers that cannot be reset by the user, such as device IDs, hardware serial numbers, or MAC addresses. For example, the [`ANDROID_ID`](https://developer.android.com/reference/android/provider/Settings.Secure#ANDROID_ID) before Android 8.0 (API level 26) was a non-resettable identifier randomly generated at first boot, while in recent versions it's unique to each combination of app-signing key, user, and device. +- **Misuse of Resettable Identifiers**: Using [resettable identifiers](https://developer.android.com/privacy-and-security/about#resettable-identifiers) like the [Advertising ID](https://developer.android.com/identity/user-data-ids#advertising-ids) on Android or the [Advertising Identifier (aka. Identifier for Advertisers or IDFA)](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) on iOS without respecting user preferences or obtaining proper consent. +- **Linking Identifiers Across Services**: Combining identifiers from different sources, such as device IDs, advertising IDs, or other unique identifiers as well as behavioral data, to create a unified profile of a user, even after a reset or reinstall. - **Tracking Without User Consent**: Tracking users across services or apps without their explicit consent or without providing the ability to opt out or reset identifiers. For instance, on iOS, access to the IDFA requires explicit user consent under the [App Tracking Transparency (ATT) framework](https://developer.apple.com/documentation/AppTrackingTransparency). The IDFV can track users across apps by the same vendor without explicit consent but resets when all of the vendor's apps are removed from the device. ## Impact -- **Loss of User Trust**: Users are likely to lose trust in an app that lacks transparency in how unique identifiers are used for tracking, which may lead to negative reviews, decreased engagement, and reduced retention rates. -- **Violation of User Privacy**: Users may not be fully aware of the implications when accepting tracking, such as the collection of unique identifiers or usage patterns. In some cases, tracking may be mandatory to use an app, leaving users without a real choice. This can lead to privacy violations, unauthorized use of their information, and an erosion of user control over their data. -- **Compliance and Legal Risks**: Violation of data protection laws and regulations (like GDPR), resulting in legal consequences, fines, and potential non-compliance with platform guidelines, which may lead to app store removal. +- **Violation of User Privacy**: Third parties can build detailed profiles of individuals, estimating interests, health status, sexual orientation, and other personal attributes, resulting in users losing control over their personal information and being subject to unwanted targeting or profiling. +- **Loss of User Trust**: Users can discover undisclosed tracking, resulting in negative reviews, decreased engagement, and reduced retention for the app owner. +- **Legal and Regulatory Non-Compliance**: Tracking users without valid consent can violate data protection laws (like GDPR) and platform guidelines, resulting in fines, legal action, or app store removal for the app owner. ## Mitigations -- **Use Resettable Identifiers**: Prefer [resettable identifiers](https://developer.android.com/privacy-and-security/about#resettable-identifiers) like the [Advertising ID](https://developer.android.com/identity/user-data-ids#advertising-ids) on Android or [Advertising Identifier (aka. Identifier for Advertiseers or IDFA)](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) on iOS, for purposes like analytics or personalized advertising. Always respect user preferences and consent regarding tracking and data collection. Avoid using hardware-based identifiers like device IDs or MAC addresses. -- **Use App-Scoped Identifiers**: Use app-scoped identifiers to maintain user privacy and prevent cross-service tracking. Examples include [**ANDROID_ID** (on Android 8.0 (API level 26) and higher)](https://developer.android.com/about/versions/oreo/android-8.0-changes#privacy-all), **Firebase Installation IDs (FIDs)**, or privately stored Globally Unique IDs (GUIDs). On iOS, consider using **Identifier for Vendors (IDFV)** to track users across apps by the same vendor and resets when all the vendor's apps are uninstalled. +- **Use Resettable Identifiers**: Prefer [resettable identifiers](https://developer.android.com/privacy-and-security/about#resettable-identifiers) like the [Advertising ID](https://developer.android.com/identity/user-data-ids#advertising-ids) on Android or the [Advertising Identifier (aka. Identifier for Advertisers or IDFA)](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) on iOS, for purposes like analytics or personalized advertising. Always respect user preferences and consent regarding tracking and data collection. Avoid using hardware-based identifiers like device IDs or MAC addresses. +- **Use App-Scoped Identifiers**: Use app-scoped identifiers to maintain user privacy and prevent cross-service tracking. Examples include [**ANDROID_ID** (on Android 8.0 (API level 26) and higher)](https://developer.android.com/about/versions/oreo/android-8.0-changes#privacy-all), **Firebase Installation IDs (FIDs)**, or privately stored Globally Unique IDs (GUIDs). On iOS, consider using the **Identifier for Vendors (IDFV)**, which tracks users only across apps by the same vendor and resets when all the vendor's apps are uninstalled. - **Use Advertising ID Appropriately**: Restrict advertising ID usage to ad-serving and user profiling contexts, respecting user preferences on ad tracking. Avoid linking identifiers after a reset without explicit user consent, ensuring a fresh start. On Android, [use the **Advertising ID** appropriately](https://support.google.com/googleplay/android-developer/answer/9857753#ad-id), and on iOS, comply with **App Tracking Transparency (ATT)** by [requesting user permission](https://developer.apple.com/documentation/apptrackingtransparency/attrackingmanager/requesttrackingauthorization(completionhandler:)) before accessing the **Identifier for Advertisers (IDFA)** and avoid storing it; access [`advertisingIdentifier`](https://developer.apple.com/documentation/adsupport/asidentifiermanager/advertisingidentifier) instead. -- **Use Appropriate APIs**: Use privacy-preserving APIs instead of relying on identifiers. For example, for device verification on Android use **Play Integrity**, and on iOS use **DeviceCheck** (e.g., to identify devices that have taken advantage of a promotional offer or to flag fraudulent devices). For privacy-friendly ad attribution, use [Attribution Reporting API](https://developers.google.com/privacy-sandbox/private-advertising/attribution-reporting/android) on Android, and consider using **AdAttributionKit** or **SKAdNetwork** on iOS. +- **Use Appropriate APIs**: Use privacy-preserving APIs instead of relying on identifiers. For example, for device verification on Android use **Play Integrity**, and on iOS use **DeviceCheck** (e.g., to identify devices that have taken advantage of a promotional offer or to flag fraudulent devices). For privacy-friendly ad attribution, use the [Attribution Reporting API](https://developers.google.com/privacy-sandbox/private-advertising/attribution-reporting/android) on Android, and consider using **AdAttributionKit** or **SKAdNetwork** on iOS. - **Treat Third-Party SDKs as Your Own Code**: Be aware of any privacy or security policies associated with third-party SDKs integrated into your app, particularly those related to the use of unique identifiers. Ensure third-party SDKs comply with platform guidelines for data collection and user consent, such as Apple's App Tracking Transparency (ATT) and Google's Play Data Safety policies, to avoid misuse of identifiers and ensure transparency. - **Provide Clear Privacy Information**: Inform users about the collection and use of unique identifiers in your privacy policy, app store listing, and within the app itself. Clearly explain the purpose of tracking and how it benefits the user experience. Provide users with the ability to opt out of tracking or reset identifiers if possible. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0067.md b/weaknesses/MASVS-PRIVACY/MASWE-0067.md new file mode 100644 index 00000000..da26cef5 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0067.md @@ -0,0 +1,41 @@ +--- +title: Inadequate Privacy Policy +id: MASWE-0067 +alias: privacy-policy +requirement: "The app provides an adequate privacy policy." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0067 +attacks: [MAS-ATTACK-0079, MAS-ATTACK-0080] +mappings: + masvs-v1: [MSTG-STORAGE-12] + masvs-v2: [MASVS-PRIVACY-3] + cwe: [359] + maswe-beta: [MASWE-0111] +refs: +- https://support.google.com/googleplay/android-developer/answer/9859455#privacy_policy +- https://developer.apple.com/app-store/app-privacy-details/#privacy-links +- https://developer.apple.com/app-store/review/guidelines/#5.1.1 +--- + +## Overview + +This weakness occurs when an app does not provide users with a clear, accessible, and accurate statement of how their data is collected, processed, shared, and protected. + +Privacy policies should be easily accessible, tailored specifically to the app in question, and written in a way that users can easily understand. Without a robust privacy policy, users are unable to make informed decisions about their data, and may be unaware of how their information is being used or shared. A privacy policy that is incomplete, vague, or does not match the app's behavior can mislead users and undermine transparency. + +## Modes of Introduction + +- **Unclear or Absent Privacy Policy**: Not providing a privacy policy, or having one that is not easily accessible or clear to the user, or that doesn't specifically address the data practices of that particular app, instead being a generic document that covers multiple services. +- **Discrepancies in Policy vs Behavior**: Collecting, processing, or sharing data in ways that differ from what the privacy policy states. + +## Impact + +- **Violation of User Privacy**: Users can unknowingly provide data that is shared with third parties, used for profiling, or used for targeted advertising without explicit consent, resulting in the loss of control over their personal information. +- **Loss of User Trust**: Users can perceive the app as non-transparent, resulting in negative reviews, decreased user engagement, and reduced retention for the app owner. +- **Legal and Regulatory Non-Compliance**: Failing to provide an adequate privacy policy can violate privacy laws and regulations, such as GDPR or CCPA, resulting in fines, legal action, or removal from app stores for the app owner. + +## Mitigations + +- **Provide a Clear Privacy Policy**: Make sure a comprehensive and understandable privacy policy is readily accessible to users. Tailor it to the specific data practices of your app and write it in clear, understandable language as stated in Article 12 of the GDPR. +- **Ensure Consistency in Policy vs Behavior**: Keep your data collection practices documented and up to date in privacy policies, privacy labels, and app store listings. Ensure that these documents match the app's actual behavior to avoid discrepancies that could mislead users or violate platform policies. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0068.md b/weaknesses/MASVS-PRIVACY/MASWE-0068.md new file mode 100644 index 00000000..4bac74f3 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0068.md @@ -0,0 +1,48 @@ +--- +title: Inadequate Data Collection Declarations +id: MASWE-0068 +alias: data-collection-declarations +requirement: "The app adequately declares all user collected data." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0068 +attacks: [MAS-ATTACK-0081, MAS-ATTACK-0082] +mappings: + masvs-v1: [MSTG-STORAGE-12, MSTG-NETWORK-1] + masvs-v2: [MASVS-PRIVACY-3, MASVS-PRIVACY-1] + cwe: [359] + maswe-beta: [MASWE-0112, MASWE-0108] +refs: +- https://support.apple.com/en-us/102188 +- https://support.apple.com/kb/HT211970 +- https://developer.apple.com/app-store/review/guidelines/#5.1.2 +- https://developer.apple.com/app-store/app-privacy-details/#data-collection +- https://support.google.com/googleplay/android-developer/answer/10787469 +- https://developer.apple.com/videos/play/wwdc2023/10060 +- https://support.google.com/googleplay/answer/11416267 +- https://www.youtube.com/watch?v=J7TM0Yy0aTQ +- https://www.youtube.com/watch?v=4rfF3y4xchU +--- + +## Overview + +This weakness occurs when an app's stated data collection practices, such as those documented in Apple's [App Privacy Report](https://support.apple.com/en-us/102188) and [Privacy Nutrition Labels](https://support.apple.com/kb/HT211970), or Google's [Data Safety section](https://support.google.com/googleplay/android-developer/answer/10787469?hl=en), are incomplete or inconsistent with the app's actual behavior. + +These declarations must clearly outline what data is collected, how it is used, whether it is linked to the user's identity, and whether it is shared with third parties in accordance with the platform's policies. When they are inaccurate, users are prevented from making informed decisions about their privacy, including understanding whether data will be linked to their identity, used for tracking, or shared with third parties. + +**Note about third-party libraries (SDKs)**: Developers, as data controllers, are legally responsible for ensuring that third-party components process sensitive data lawfully, fairly, and transparently, as highlighted in the [ENISA study on GDPR compliance](https://www.enisa.europa.eu/sites/default/files/publications/WP2017%20O-2-2-4%20GDPR%20Mobile.pdf) (Section 2.2.7, _"Data transfers and processing by third parties"_). However, in some cases, it may be challenging for mobile app developers to be fully aware of what data these third-party SDKs actually collect. + +## Modes of Introduction + +- **Undeclared Data Collection and Purpose**: Failing to declare what data is being collected (e.g., location, contacts, identifiers) and for what purposes (e.g., analytics, personalization). +- **Discrepancies in Declarations vs Behavior**: Publishing declarations that differ from the app's actual behavior by using data for purposes other than those disclosed. + +## Impact + +- **Violation of User Privacy**: Users can unknowingly share data whose purpose they do not understand, resulting in unauthorized sharing, profiling, or targeted advertising. +- **Loss of User Trust**: Users can discover the inconsistent declarations, resulting in negative reviews, lower user engagement, and reduced retention for the app owner. +- **Legal and Regulatory Non-Compliance**: Inaccurate or inconsistent data declarations can violate regulations like GDPR or CCPA and platform policies, resulting in fines, legal action, or removal from app stores for the app owner. + +## Mitigations + +- **Maintain Accurate Privacy Labels**: Comply with Apple's Privacy Nutrition Labels and Google's Data Safety Section requirements by providing accurate, up to date and transparent information about your data practices, including data collection and sharing with third parties. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0069.md b/weaknesses/MASVS-PRIVACY/MASWE-0069.md new file mode 100644 index 00000000..c7324885 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0069.md @@ -0,0 +1,38 @@ +--- +title: Lack of Proper Data Management Controls +id: MASWE-0069 +alias: data-management-controls +requirement: "The app provides adequate controls to manage user data." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0069 +attacks: [MAS-ATTACK-0083] +mappings: + masvs-v2: [MASVS-PRIVACY-4] + cwe: [359] + maswe-beta: [MASWE-0113] +refs: +- https://developer.apple.com/app-store/app-privacy-details/#privacy-links +--- + +## Overview + +This weakness occurs when an app does not provide users with mechanisms specifically designed to manage their personal data, leaving them without adequate options to exercise their rights over their own information. + +These mechanisms typically include the ability for users to delete, export, modify, or opt out of data collection directly within the app interface. For example, some apps provide data management features within the settings menu, while others provide a link to an external website where users can manage their data. + +## Modes of Introduction + +- **Lack of Proper Data Management Settings**: Failing to provide users with the ability to delete, export, modify, or opt out of data collection. + +## Impact + +- **Violation of User Privacy**: Users cannot exercise their rights to manage their personal data, such as deleting or exporting their information, resulting in the loss of control over their data and an increased amount of exposed data if a breach occurs. +- **Loss of User Trust**: Users can perceive that they have no control over their personal data, resulting in negative reviews, decreased user engagement, and reduced retention for the app owner. +- **Legal and Regulatory Non-Compliance**: Failing to provide data management capabilities can violate regulations like GDPR and CCPA, resulting in fines, legal action, and other consequences for the app owner. + +## Mitigations + +- **Implement Data Management Mechanisms**: Ensure that mechanisms are in place for users to delete, export, or modify their data. Provide granular controls for specific aspects of data collection and sharing (e.g., location services, contacts, media access). +- **Regularly Update Data Management Features**: Regularly review and update data management features to ensure compliance with evolving regulations and user expectations. This helps maintain transparency and user trust. +- **Provide a User-Friendly Data Management Interface**: Create a user-friendly interface for data management controls, ensuring that users can easily navigate and exercise their rights over their personal data without friction. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0070.md b/weaknesses/MASVS-PRIVACY/MASWE-0070.md new file mode 100644 index 00000000..402ce149 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0070.md @@ -0,0 +1,37 @@ +--- +title: Inadequate Data Visibility Controls +id: MASWE-0070 +alias: data-visibility-control +requirement: "The app provides adequate controls over the visibility of user data." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0070 +attacks: [MAS-ATTACK-0084, MAS-ATTACK-0087] +mappings: + masvs-v2: [MASVS-PRIVACY-4] + cwe: [359] + maswe-beta: [MASWE-0114] +refs: +- https://firebase.google.com/support/privacy/storing-privacy-settings +- https://www.researchgate.net/publication/335863205_Demystifying_Hidden_Privacy_Settings_in_Mobile_Apps +--- + +## Overview + +This weakness occurs when an app does not give users sufficient control over how their personal information is shared with other users or the broader environment. + +Examples of such information include last connection status, read receipts, date of birth, email address, or discoverability settings. Ensuring that users have clear and granular options, typically in the form of app settings, to control data visibility is critical to maintaining their privacy and building trust in the app. + +## Modes of Introduction + +- **Lack of Granular Privacy Settings**: Failing to provide privacy settings with sufficient granularity to allow users to control specific aspects of data collection and sharing, such as differentiating between location services, contacts, or media access, or to decide which types of information are shared and with whom. +## Impact + +- **Violation of User Privacy**: Users can unintentionally expose personal information, such as their email address, birthday, or online status, to others without their consent, resulting in an increased risk of harassment, stalking, or identity theft. +- **Loss of User Trust**: Users can feel they have inadequate control over what information is shared and with whom, resulting in negative reviews and decreased app engagement for the app owner. +- **Legal and Regulatory Non-Compliance**: Failing to offer sufficient privacy controls can violate regulations like GDPR or CCPA, which require user control over data visibility and sharing, resulting in fines or legal action for the app owner. + +## Mitigations + +- **Offer Granular Privacy Settings**: Provide privacy settings with sufficient granularity, allowing users to control individual data collection categories (e.g., location, contacts) and manage their sharing preferences. Allow users to choose what information is visible to others, such as connection status or discoverability. +- **Educate Users on Privacy Options**: Clearly inform users about available privacy settings and how to use them effectively to manage data visibility. This can be done through tutorials, help sections, or contextual tips within the app. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0115.md b/weaknesses/MASVS-PRIVACY/MASWE-0071.md similarity index 60% rename from weaknesses/MASVS-PRIVACY/MASWE-0115.md rename to weaknesses/MASVS-PRIVACY/MASWE-0071.md index 1eb007cd..174d20e0 100644 --- a/weaknesses/MASVS-PRIVACY/MASWE-0115.md +++ b/weaknesses/MASVS-PRIVACY/MASWE-0071.md @@ -1,38 +1,40 @@ --- title: Inadequate or Ambiguous User Consent Mechanisms -id: MASWE-0115 +id: MASWE-0071 alias: ambiguous-consent-mechanisms -platform: ["android", "ios"] -profiles: ["P"] +requirement: "The app requests user consent prior to any data processing." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0071 +attacks: [MAS-ATTACK-0085, MAS-ATTACK-0086] mappings: - masvs-v1: [] masvs-v2: [MASVS-PRIVACY-4] - cwe: [359] + cwe: [200, 285, 358, 359] + maswe-beta: [MASWE-0115, MASWE-0060] refs: - https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission - https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources - https://developer.android.com/training/permissions/requesting#explain -status: new --- ## Overview -According to various international privacy regulations, such as the [EU's GDPR](https://gdpr-info.eu/art-7-gdpr/), [California's CCPA](https://cppa.ca.gov/regulations/pdf/cppa_act.pdf), [Brazil's LGPD](https://lgpd-brazil.info/chapter_02/article_08), and [Canada's PIPEDA](https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/p_principle/principles/p_consent/), user consent must be explicit, informed, and obtained prior to any data processing. Users must be made fully aware of the purposes of the data collection, as well as the potential consequences of providing consent. In addition, consent should be an active choice, specific to the data being processed, and not bundled with other service agreements or presented in a vague or coercive manner. +This weakness occurs when an app processes personal data without obtaining consent that is explicit, informed, and given prior to the processing, or when the consent request is vague, bundled, or coercive. -Mobile apps that fail to follow these principles often result in users unknowingly consenting to data collection or processing that could pose significant risks to their fundamental rights and freedoms. For example, apps may use vague or non-negotiable consent requests, pressuring users to provide consent without fully understanding the implications. +According to various international privacy regulations, such as the [EU's GDPR](https://gdpr-info.eu/art-7-gdpr/), [California's CCPA](https://cppa.ca.gov/regulations/pdf/cppa_act.pdf), [Brazil's LGPD](https://lgpd-brazil.info/chapter_02/article_08), and [Canada's PIPEDA](https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/p_principle/principles/p_consent/), users must be made fully aware of the purposes of the data collection, as well as the potential consequences of providing consent. Consent should be an active choice, specific to the data being processed, and not bundled with other service agreements or presented in a vague or coercive manner. In addition, users must be able to easily withdraw their consent at any time and should be clearly informed of how to do so, including the potential impact on the functionality of the app. Developers must maintain a record of user consent and ensure that consent requests are clear, separate from other terms, and legally valid, and avoid practices that obscure the full scope of data processing. ## Modes of Introduction - **Failure to Prompt for Consent Changes**: Failing to prompt the user for consent when data collection practices change or when additional data is collected beyond what was originally specified. -- **Ambiguous Consent Mechanisms**: Consent is bundled with terms of service, often covering future use cases without notifying the user again. In some cases, consent is implied if the user doesn't explicitly deny access, leading to data collection without clear approval. +- **Ambiguous Consent Mechanisms**: Bundling consent with terms of service, often covering future use cases without notifying the user again, or implying consent when the user doesn't explicitly deny access. ## Impact -- **Violation of User Privacy**: When ambiguous consent mechanisms are used, user privacy is severely compromised as users may unknowingly give up control over their data. This exposes them to the risk of their information being used without clear or informed consent for purposes they may find objectionable or harmful, such as targeted advertising, profiling, discrimination or even identity theft. -- **Loss of User Trust**: Users may lose trust in the app and abandon it, share negative reviews, or discourage others from using it, leading to reputational damage and potential loss of business. -- **Legal and Compliance Issues**: Non-compliance with laws and platform requirements can result in legal consequences, fines, or removal from app stores. +- **Violation of User Privacy**: Users can unknowingly give up control over their data, resulting in its use for purposes they may find objectionable or harmful, such as targeted advertising, profiling, discrimination, or even identity theft. +- **Loss of User Trust**: Users can lose trust in the app and abandon it, share negative reviews, or discourage others from using it, resulting in reputational damage and potential loss of business for the app owner. +- **Legal and Regulatory Non-Compliance**: Processing data without valid consent can violate laws and platform requirements, resulting in legal consequences, fines, or removal from app stores for the app owner. ## Mitigations diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0072.md b/weaknesses/MASVS-PRIVACY/MASWE-0072.md new file mode 100644 index 00000000..b45ac227 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0072.md @@ -0,0 +1,65 @@ +--- +title: Inadequate Permission Management +id: MASWE-0072 +alias: inadequate-permission-management +requirement: "The app adequately manages permissions." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0072 +attacks: [MAS-ATTACK-0088, MAS-ATTACK-0089] +mappings: + masvs-v2: [MASVS-PRIVACY-1] + cwe: [250] + android-core-app-quality: [Minimize_Permissions, Sensitive_Permissions, Runtime_Permissions, Permission_Rationale, Graceful_Degradation] + maswe-beta: [MASWE-0117] +refs: +- https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission +- https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources +- https://developer.android.com/training/permissions/requesting +- https://support.google.com/googleplay/android-developer/answer/9888170?hl=en +- https://developer.android.com/privacy-and-security/minimize-permission-requests +- https://developer.android.com/training/permissions/usage-notes +- https://arxiv.org/pdf/1905.02713 +- https://arxiv.org/pdf/2203.10583 +- https://ieeexplore.ieee.org/document/9001128 +- https://www.enisa.europa.eu/sites/default/files/publications/WP2017%20O-2-2-4%20GDPR%20Mobile.pdf +- https://developer.android.com/privacy-and-security/risks/ai-risks/excessive-agency +- https://developer.android.com/privacy-and-security/risks/ai-risks/sensitive-information-disclosure +- https://developer.apple.com/documentation/bundleresources/information_property_list/nsextension/nsextensionattributes/requestsopenaccess +--- + +## Overview + +This weakness occurs when an app requests more permissions than it needs, keeps permissions it no longer needs, or fails to explain why permissions are required. + +Permissions control access to sensitive device features such as the camera, microphone, location, and storage, making them a crucial aspect of mobile app privacy. They serve as the gateway for data collection and processing, so proper permission management is essential to protect user privacy and comply with regulations. + +Developers face the challenge of balancing functionality with privacy: while some permissions are essential for core features (e.g., a camera app requiring camera access), excessive permissions enable unnecessary data collection. From the user's perspective, privacy concerns may lead to reluctance in granting permissions, forcing them to choose between privacy and app functionality, while other users may grant permissions without fully understanding the implications. Pre-installed apps aggravate the problem, as they frequently come with excessive permissions that are granted by default and that users cannot control or revoke. + +Third-party libraries (SDKs) further complicate permission management by requiring permissions that the app itself does not need and by using the app's granted permissions to collect data. Similarly, AI-enabled features can be given permission-backed tools that allow them to access sensitive data or act on the user's behalf beyond what the feature requires. Mobile permission models often fail to distinguish between permissions granted to an app and those assigned to third-party components, a challenge highlighted in the [IEEE research paper "Engineering Privacy in Smartphone Apps"](https://ieeexplore.ieee.org/document/9001128) (Section IV, _"Third-party content"_). Furthermore, third-party services behind these SDKs may continue accessing data collected over the network even after permissions are revoked or the app is deleted. + +## Modes of Introduction + +- **Requesting Excessive Permissions**: Requesting more permissions than necessary for the app's core functionality. +- **Lack of Use of Privacy-Friendly Alternatives**: Failing to use less intrusive alternatives, such as requesting fine location when coarse location would suffice or requesting camera and photo-library access instead of using an image picker. +- **Retaining Unneeded Permissions**: Not revoking permissions that are no longer necessary. +- **Inadequate Permission Explanations**: Failing to provide clear explanations for why each permission is required. +- **Third-Party Permission Requirements**: Including SDKs that require permissions beyond the app's functional needs or use granted permissions to collect and analyze data. +- **Excessive AI Agent Permissions**: Giving an AI-enabled feature permission-backed tools or data access beyond what it requires for its intended task. +- **Unjustified Full Access in a Bundled Keyboard**: Shipping a custom keyboard extension that sets `RequestsOpenAccess` to `true` without a feature that requires it, allowing the keyboard to transmit typed input or write it to a shared container. + +## Impact + +- **Violation of User Privacy**: Apps and embedded components can use unnecessarily granted access to collect location, contacts, or media, resulting in tracking, surveillance, or profiling of the user. +- **Compromise of Sensitive Data**: Apps and embedded components can retain sensitive data collected through unnecessary permissions, resulting in broader exposure of that data when the app or a third-party service suffers a data breach. +- **Loss of User Trust**: Users can perceive permission requests as unjustified, resulting in refused permissions, negative reviews, lower user engagement, and reduced retention for the app owner. +- **Legal and Regulatory Non-Compliance**: Requesting or retaining unnecessary permissions can violate data minimization requirements in regulations like GDPR or CCPA, resulting in fines, legal action, or removal from app stores for the app owner. + +## Mitigations + +- **Limit Permissions to Essential Needs**: Ensure the app and any AI-enabled features only request permissions necessary for core functionality, avoiding the collection of unnecessary data and adhering to the principle of data minimization. +- **Prefer Privacy-Friendly Alternatives**: Use privacy-friendly alternatives to permissions that are less intrusive and provide users with more control over their data. For example, use coarse location instead of fine location, or use an image picker instead of requesting access to the camera and photo gallery. +- **Enable Proactive Permission Revocation**: Automatically relinquish permissions that are no longer necessary to minimize unnecessary data access over time, and ensure that users can manually revoke permissions at any time through a clear and accessible interface. +- **Implement Just-in-Time Permission Requests**: Request permissions only when they are needed, providing clear explanations for why each permission is required. This approach helps build user trust and ensures users understand the implications of granting access to their data. +- **Add Proper Permission Explanations**: Provide clear explanations for why each permission is required, helping users understand the necessity and scope of the requested access. +- **Avoid Full Access in Bundled Keyboards**: Do not set `RequestsOpenAccess` in a custom keyboard extension unless a user-facing feature requires it, and never use it to transmit or store the characters the keyboard receives. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0073.md b/weaknesses/MASVS-PRIVACY/MASWE-0073.md new file mode 100644 index 00000000..858894dd --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0073.md @@ -0,0 +1,39 @@ +--- +title: Inadequate Tracking Domains Declarations +id: MASWE-0073 +alias: tracking-domains-declarations +requirement: "The app adequately declares all tracking domains it connects to." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0073 +attacks: [MAS-ATTACK-0074, MAS-ATTACK-0075] +mappings: + masvs-v2: [MASVS-PRIVACY-3] + cwe: [359] + maswe-beta: [MASWE-0108] +refs: +- https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api +- https://developer.apple.com/documentation/bundleresources/privacy_manifest_files +- https://developer.apple.com/app-store/app-privacy-details/#user-tracking +- https://developer.apple.com/documentation/apptrackingtransparency/ +--- + +## Overview + +This weakness occurs when an app fails to declare the domains it uses for tracking, declares them incompletely, or declares them inconsistently with its actual network behavior. + +Platforms increasingly require apps to declare their tracking domains so the system can enforce the user's tracking choices. For example, Apple's privacy manifest lists tracking domains (`NSPrivacyTrackingDomains`), and connections to those domains are blocked when the user has not granted App Tracking Transparency permission. Inadequate or inaccurate declarations prevent the platform from enforcing the user's tracking preferences, mislead users about how their data is used, and can lead to app-review rejections. + +## Modes of Introduction + +- **Missing or Incomplete Declarations**: Not declaring tracking domains at all, or declaring only a subset of the domains the app actually contacts for tracking purposes. + +## Impact + +- **Violation of User Privacy**: Tracking traffic can bypass the platform's enforcement of the user's tracking choice, resulting in users being tracked despite having refused permission. +- **Loss of User Trust**: Users and researchers can discover undeclared tracking connections, resulting in negative publicity and reduced trust in the app. +- **Legal and Regulatory Non-Compliance**: Inaccurate tracking declarations can violate platform policies and privacy regulations, resulting in app-review rejection, removal, or fines for the app owner. + +## Mitigations + +- **Declare All Tracking Domains**: Enumerate every domain used for tracking, including those contacted by third-party SDKs, in the platform's declaration mechanism (e.g. the privacy manifest's `NSPrivacyTrackingDomains`). diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0074.md b/weaknesses/MASVS-PRIVACY/MASWE-0074.md new file mode 100644 index 00000000..1025a8f0 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0074.md @@ -0,0 +1,45 @@ +--- +title: Usage of Non-Privacy-Preserving Functionality +id: MASWE-0074 +alias: non-privacy-preserving-functionality +requirement: "The app uses privacy-preserving functionality." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0074 +attacks: [MAS-ATTACK-0076, MAS-ATTACK-0088] +mappings: + masvs-v2: [MASVS-PRIVACY-2] + cwe: [359] + android-core-app-quality: [Minimize_Permissions] +refs: +- https://datatracker.ietf.org/doc/html/rfc8252#appendix-B +- https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession +- https://developer.android.com/training/data-storage/shared/photopicker +- https://developer.apple.com/documentation/photokit/phpickerviewcontroller +--- + +## Overview + +This weakness occurs when an app uses functionality that unnecessarily exposes user data even though the platform provides a privacy-preserving alternative. + +Platforms increasingly offer least-exposing APIs for common tasks: system authentication sessions (ASWebAuthenticationSession on iOS and Custom Tabs on Android, as recommended by RFC 8252, Appendix B) keep credentials and browsing state isolated from the app; system pickers (e.g., PHPickerViewController on iOS and the Android Photo Picker) return only the items selected by the user without granting broad permissions; and on-device processing can avoid sending data to remote AI services. Choosing a less privacy-preserving option leads to avoidable data exposure and over-collection. This is the privacy-focused counterpart to @MASWE-0047, which applies the same "prefer platform-provided functionality" principle from a security perspective; some features, such as system authentication sessions, improve both security and privacy. + +## Modes of Introduction + +- **Embedded Authentication Flows**: Handling third-party authentication in embedded WebViews or deprecated session APIs, exposing credentials and browsing state to the app, instead of isolated system authentication sessions. +- **Broad Permissions Instead of Pickers**: Requesting full photo-library, camera, or file access when a system picker would return only the user-selected items without any permission. +- **Remote Processing Instead of On-Device AI**: Sending user data to remote AI services when on-device processing can support the feature. +- **Over-Exposing API Choices**: Choosing APIs that reveal more user data than the feature requires when a least-exposing platform alternative exists (see also @MASWE-0072). + +## Impact + +- **Violation of User Privacy**: The app and its embedded components can collect and correlate credentials, browsing state, or whole data collections that a privacy-preserving alternative would never have exposed, resulting in tracking, surveillance, or profiling of the user. +- **Compromise of Sensitive Data**: The app and its embedded components can retain data that a privacy-preserving alternative would not expose, resulting in broader exposure when the app or a third-party service suffers a data breach. +- **Loss of User Trust**: Users can perceive unnecessary permission prompts and embedded login flows as invasive, resulting in refused permissions, abandoned logins, and reduced retention. + +## Mitigations + +- **Use System Authentication Sessions**: Authenticate against third-party services with `ASWebAuthenticationSession` on iOS or Custom Tabs on Android, following RFC 8252, instead of embedded WebViews or deprecated APIs. +- **Prefer System Pickers**: Use the system photo, file, and contact pickers so the app receives only what the user explicitly selects, without broad permission grants. +- **Prefer On-Device Processing**: Use on-device AI or other local processing when it can support the feature without sending user data to a remote service. +- **Choose Least-Exposing APIs**: When the platform offers a privacy-preserving variant of a capability, prefer it and request broad access only when the feature genuinely requires it (see @MASWE-0072). diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0077.md b/weaknesses/MASVS-PRIVACY/MASWE-0077.md new file mode 100644 index 00000000..c08ecf32 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0077.md @@ -0,0 +1,46 @@ +--- +title: Inadequate Awareness for Privacy Relevant Actions +id: MASWE-0077 +alias: inadequate-awareness-privacy-actions +requirement: "The app informs the user about the privacy implications before performing an action." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0077 +attacks: [MAS-ATTACK-0084] +mappings: + masvs-v2: [MASVS-PRIVACY-2] + cwe: [359] + maswe-beta: [MASWE-0109] +refs: +- https://cloud.google.com/sensitive-data-protection/docs/classification-redaction +- https://gdpr-info.eu/recitals/no-26/ +- https://gdpr-info.eu/recitals/no-28/ +- https://gdpr-info.eu/art-4-gdpr/ +- https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en +- https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf +- https://www.statista.com/topics/9460/app-tracking-and-mobile-privacy/ +--- + +## Overview + +This weakness occurs when an app performs a privacy relevant action without making its scope or material consequences reasonably apparent to the user. + +Privacy relevant actions include sharing, exporting, publishing, synchronizing, backing up, changing visibility, responding to a request from another party, or moving data from private app storage to storage or services accessible by other applications, users, or third parties. + +The weakness may cause users to disclose different data, disclose data to a broader audience, or create more persistent copies than they reasonably intended. It includes flows where the app honors another party's request for data without clearly showing the user what will be shared and with whom, or allowing the user to control the disclosure. It does not require the underlying processing to rely on consent. The issue is whether the interface allows the user to understand and control the resulting privacy state. + +## Modes of Introduction + +- **Unclear Disclosure Context**: The interface or action labels do not clearly identify the affected records, files, accounts, data elements, included metadata, destination, audience, or resulting privacy state, including when responding to another party's request for data. +- **Insufficient Disclosure Review and Feedback**: The app does not allow the user to review, control, or confirm a consequential disclosure, or clearly indicate that a high impact or difficult to reverse disclosure has occurred. + +## Impact + +- **Violation of User Privacy**: The app can disclose personal or sensitive data to recipients who are not entitled to receive it under the user's sharing choices, resulting in unauthorized exposure of that data. +- **Loss of User Trust**: Users can discover that the app shared data without their awareness or control, resulting in reduced confidence in the app and its owner. +- **Legal and Regulatory Non-Compliance**: The app can share personal data without adequate transparency or user control, resulting in violations of privacy obligations and potential enforcement action. + +## Mitigations + +- **Provide Clear Disclosure Context and Control**: At the point of action, show the affected data, included metadata, destination, audience, and material privacy consequences; before responding to another party's request for data, identify the requester and recipient and allow the user to approve, limit, or decline the disclosure. +- **Support Review and Reversal of Consequential Disclosures**: Before completion, allow users to review selected items, recipients, audience, included metadata, and visibility; make the resulting privacy state visible and provide proportionate confirmation or undo mechanisms when practical. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0078.md b/weaknesses/MASVS-PRIVACY/MASWE-0078.md new file mode 100644 index 00000000..f58ff084 --- /dev/null +++ b/weaknesses/MASVS-PRIVACY/MASWE-0078.md @@ -0,0 +1,46 @@ +--- +title: Inadequate Defaults for Privacy Relevant Actions +id: MASWE-0078 +alias: unsafe-defaults-privacy-actions +requirement: "The app uses adequate defaults for privacy relevant actions." +platform: [android, ios] +profiles: [P] +threat: MAS-THREAT-0078 +attacks: [MAS-ATTACK-0084, MAS-ATTACK-0087] +mappings: + masvs-v2: [MASVS-PRIVACY-2] + cwe: [359] + maswe-beta: [MASWE-0109] +refs: +- https://cloud.google.com/sensitive-data-protection/docs/classification-redaction +- https://gdpr-info.eu/recitals/no-26/ +- https://gdpr-info.eu/recitals/no-28/ +- https://gdpr-info.eu/art-4-gdpr/ +- https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en +- https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf +- https://www.statista.com/topics/9460/app-tracking-and-mobile-privacy/ +--- + +## Overview + +This weakness occurs when an app uses defaults for a privacy relevant action that expose more data than is necessary for the expected functionality. + +Privacy relevant actions include sharing, exporting, publishing, synchronizing, backing up, changing visibility, responding to a request from another party, or moving data from private app storage to storage or services accessible by other applications, users, or third parties. + +The weakness may cause users to disclose different data, disclose data to a broader audience, or create more persistent copies than they reasonably intended. The issue is whether the default configuration results in a more exposing privacy state than is necessary for the requested functionality. + +## Modes of Introduction + +- **Unclear Disclosure Context**: The interface or action labels do not clearly identify the affected records, files, accounts, data elements, included metadata, destination, audience, or resulting privacy state, including when responding to another party's request for data. +- **Overly Exposing Defaults**: The app preselects broader audiences, more data, longer retention, public visibility, or additional recipients when a less exposing default would satisfy the expected functionality. + +## Impact + +- **Violation of User Privacy**: The app can disclose personal or sensitive data to recipients who are not entitled to receive it under the user's sharing choices, resulting in unauthorized exposure of that data. +- **Loss of User Trust**: Users can discover that the app shared more data, or shared it more broadly, than they reasonably expected, resulting in reduced confidence in the app and its owner. +- **Legal and Regulatory Non-Compliance**: The app can share personal data using unnecessarily exposing defaults, resulting in violations of privacy obligations and potential enforcement action. + +## Mitigations + +- **Provide Clear Disclosure Context and Control**: At the point of action, show the affected data, included metadata, destination, audience, and material privacy consequences; before responding to another party's request for data, identify the requester and recipient and allow the user to approve, limit, or decline the disclosure. +- **Use Privacy Protective Defaults**: Default to the narrowest audience, smallest data set, shortest appropriate persistence, and least exposing destination that supports the requested functionality. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0108.md b/weaknesses/MASVS-PRIVACY/MASWE-0108.md deleted file mode 100644 index 30848744..00000000 --- a/weaknesses/MASVS-PRIVACY/MASWE-0108.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Sensitive Data in Network Traffic -id: MASWE-0108 -alias: sensitive-data-in-network-traffic -platform: ["android", "ios"] -profiles: ["P"] -mappings: - masvs-v1: [MSTG-NETWORK-1] - masvs-v2: [MASVS-PRIVACY-1] - cwe: [359] -status: new ---- - -## Overview - -Sensitive data in network traffic refers to the transmission of personal or confidential information over the network in a manner that could be intercepted and accessed by unauthorized parties. While the data may be sent using secure protocols such as HTTPS, the primary concern is the appropriateness and necessity of the data being shared or collected. - -The risk is not in the security of the transmission method, but in the privacy implications of the data being transmitted. This could include personal user information, location data, usage patterns, or any other information that could compromise user privacy. - -## Modes of Introduction - -This risk can be introduced in various scenarios, including: - -- Over-collection of user data beyond the app's functional requirements. -- Transmission of detailed user location or behavior analytics without proper anonymization. -- Sharing sensitive information with third-party services (e.g., analytics, advertising networks) without user consent. -- Unnecessary collection of identifiers like IMEI, email, or phone numbers. - -## Impact - -The impact of exposing sensitive data in network traffic includes: - -- **Violation of User Privacy**: Users may not be aware that their personal information is being transmitted, leading to privacy infringement. -- **Compliance and Legal Risks**: Breach of data protection laws and regulations (like GDPR), resulting in legal consequences and fines. -- **Loss of User Trust**: Users losing trust in the application, leading to reputational damage and potential loss of business. - -## Mitigations - -To mitigate this risk, consider the following strategies: - -- Minimize the collection of user data to what is strictly necessary for app functionality. -- Implement and strictly enforce data privacy policies, including user consent for data collection and sharing. -- Use anonymization techniques for user data that is transmitted for analytics or other secondary purposes. -- Regularly review and audit data transmitted over the network to ensure it aligns with privacy policies and user expectations. -- Provide clear user-facing privacy settings, allowing users to control what data is shared. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0109.md b/weaknesses/MASVS-PRIVACY/MASWE-0109.md deleted file mode 100644 index 5a53aa1c..00000000 --- a/weaknesses/MASVS-PRIVACY/MASWE-0109.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Lack of Anonymization or Pseudonymisation Measures -id: MASWE-0109 -alias: anonymization-pseudonymization-measures -platform: ["android", "ios"] -profiles: ["P"] -mappings: - masvs-v1: [] - masvs-v2: [MASVS-PRIVACY-2] - cwe: [359] -refs: -- https://cloud.google.com/sensitive-data-protection/docs/classification-redaction -- https://gdpr-info.eu/recitals/no-26/ -- https://gdpr-info.eu/recitals/no-28/ -- https://gdpr-info.eu/art-4-gdpr/ -- https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf -- https://www.statista.com/topics/9460/app-tracking-and-mobile-privacy/ -status: new ---- - -## Overview - -The absence of unlinkability techniques like data abstraction, anonymization, and pseudonymization can enable the identification and tracking of users across different services and over time. Anonymization, through methods like randomization or generalization, irreversibly de-identifies individuals by removing or altering data, such as obfuscating location or scrambling sensitive attributes. In contrast, pseudonymization replaces identifiable data with tokens or hashed values, making it more secure but still technically reversible under certain conditions. - -This lack of privacy safeguards can result in unauthorized profiling, targeted advertising without consent, and potential legal liabilities due to non-compliance with privacy regulations. - -## Modes of Introduction - -- **Lack of Anonymization or Pseudonymization Measures**: Failure to remove direct identifiers, such as user ID or name, from data before server-side collection, or to manipulate the data to prevent linkage to real-world identities. This also includes not implementing protocols like Private Information Retrieval or Oblivious HTTP (OHTTP) to enhance privacy. - -## Impact - -- **Violation of User Privacy**: Users may not be aware that their personal information is being collected for tracking purposes, leading to privacy infringement. -- **Compliance and Legal Risks**: Breach of data protection laws and regulations (like GDPR), resulting in legal consequences and fines. - -## Mitigations - -- **Use Anonymisation and Pseudonymisation**: Ensure techniques like anonymisation and pseudonymisation are implemented to prevent user identification. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0111.md b/weaknesses/MASVS-PRIVACY/MASWE-0111.md deleted file mode 100644 index e3fc5bfd..00000000 --- a/weaknesses/MASVS-PRIVACY/MASWE-0111.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Inadequate Privacy Policy -id: MASWE-0111 -alias: privacy-policy -platform: ["android", "ios"] -profiles: ["P"] -mappings: - masvs-v1: [MASVS-STORAGE-12] - masvs-v2: [MASVS-PRIVACY-3] - cwe: [359] -refs: -- https://support.google.com/googleplay/android-developer/answer/9859455#privacy_policy -- https://developer.apple.com/app-store/app-privacy-details/#privacy-links -- https://developer.apple.com/app-store/review/guidelines/#5.1.1 -status: new ---- - -## Overview - -Mobile apps must provide users with a clear and comprehensive statement regarding how their data is collected, processed, shared, and protected. Privacy policies should be easily accessible, tailored specifically to the app in question, and written in a way that users can easily understand. Without a robust privacy policy, users are unable to make informed decisions about their data, and may be unaware of how their information is being used or shared. - -A privacy policy that is incomplete, vague, or does not match the app's behavior can mislead users and lead to a lack of transparency, resulting in potential privacy violations and legal repercussions for developers. - -## Modes of Introduction - -- **Unclear or Absent Privacy Policy**: Not providing a privacy policy, or having one that is not easily accessible or clear to the user, or that doesn't specifically address the data practices of that particular app, instead being a generic document that covers multiple services. -- **Discrepancies in Policy vs Behavior**: Differences between the privacy policy and the app's actual behavior. - -## Impact - -- **Violation of User Privacy**: Users may unknowingly provide data without understanding how it will be used, exposing them to privacy risks, such as data sharing with third parties, profiling, or targeted advertising without explicit consent. -- **Loss of User Trust**: Users are more likely to lose trust in an app that lacks transparency, which may lead to negative reviews, decreased user engagement, and reduced retention rates. -- **Legal and Compliance Issues**: Failure to provide an adequate privacy policy can result in non-compliance with privacy laws and regulations, such as GDPR or CCPA, potentially leading to fines, legal action, or removal from app stores. - -## Mitigations - -- **Provide a Clear Privacy Policy**: Make sure a comprehensive and understandable privacy policy is readily accessible to users. Tailor it to the specific data practices of your app and write it in clear, understandable language as stated in Article 12 of the GDPR. -- **Ensure Consistency in Privacy vs Behavior**: Keep your data collection practices documented and up to date in privacy policies, privacy labels, and app store listings. Ensure that these documents match the app's actual behavior to avoid discrepancies that could mislead users or violate platform policies. -- **Regularly Review and Update Privacy Policy**: Regularly review and update the privacy policy to reflect any changes in data collection practices, new features, or modifications to existing features that may impact how user data is handled. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0112.md b/weaknesses/MASVS-PRIVACY/MASWE-0112.md deleted file mode 100644 index 4b77bfb1..00000000 --- a/weaknesses/MASVS-PRIVACY/MASWE-0112.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Inadequate Data Collection Declarations -id: MASWE-0112 -alias: data-collection-declarations -platform: ["android", "ios"] -profiles: ["P"] -mappings: - masvs-v1: [MSTG-STORAGE-12] - masvs-v2: [MASVS-PRIVACY-3] - cwe: [359] -refs: -- https://support.apple.com/en-us/102188 -- https://support.apple.com/kb/HT211970 -- https://developer.apple.com/app-store/review/guidelines/#5.1.2 -- https://developer.apple.com/app-store/app-privacy-details/#data-collection -- https://support.google.com/googleplay/android-developer/answer/10787469 -- https://developer.apple.com/videos/play/wwdc2023/10060 -- https://support.google.com/googleplay/answer/11416267 -- https://www.youtube.com/watch?v=J7TM0Yy0aTQ -- https://www.youtube.com/watch?v=4rfF3y4xchU -status: new ---- - -## Overview - -When a mobile app's stated data collection practices, such as those documented in Apple's [App Privacy Report](https://support.apple.com/en-us/102188) and [Privacy Nutrition Labels](https://support.apple.com/kb/HT211970), or Google's [Data Safety section](https://support.google.com/googleplay/android-developer/answer/10787469?hl=en), are incomplete or inconsistent with the app's actual behavior, users are prevented from making informed decisions about their privacy, including understanding whether data will be linked to their identity, used for tracking, or shared with third parties. - -These declarations must clearly outline what data is collected, how it is used, whether it is linked to the user's identity, and whether it is shared with third parties in accordance with the platform's policies. - -**Note about third-party libraries (SDKs)**: Developers, as data controllers, are legally responsible for ensuring that third-party components process sensitive data lawfully, fairly, and transparently, as highlighted in the [ENISA study on GDPR compliance](https://www.enisa.europa.eu/sites/default/files/publications/WP2017%20O-2-2-4%20GDPR%20Mobile.pdf) (Section 2.2.7, _"Data transfers and processing by third parties"_). However, in some cases, it may be challenging for mobile app developers to be fully aware of what data these third-party SDKs actually collect. - -## Modes of Introduction - -- **Undeclared Data Collection and Purpose**: Failing to declare what data is being collected (e.g., location, contacts, identifiers) and for what purposes (e.g., analytics, personalization), leaving users unaware of how their information is used. -- **Discrepancies in Declarations vs Behavior**: Differences between privacy label declarations (such as Apple's Privacy Nutrition Labels or Google's Data Safety Section) and the app's actual behavior, including undeclared data collection, sharing with third parties not mentioned in privacy labels, or using data for purposes not disclosed, which are against both Apple and Google guidelines. - -## Impact - -- **Violation of User Privacy**: Users may unknowingly share data without fully understanding its purpose, which can lead to unauthorized sharing, profiling, or targeted advertising. -- **Loss of User Trust**: Inconsistent declarations can result in users losing trust in the app, leading to negative reviews, lower user engagement, and reduced retention. -- **Legal and Compliance Issues**: Inaccurate or inconsistent data declarations may lead to non-compliance with regulations like GDPR or CCPA, resulting in potential fines, legal action, or removal from app stores. - -## Mitigations - -- **Maintain Accurate Privacy Labels**: Comply with Apple's Privacy Nutrition Labels and Google's Data Safety Section requirements by providing accurate and transparent information about your data practices, including data collection and sharing with third parties. -- **Ensure Consistency in Declarations vs Behavior**: Keep your data collection practices documented and up to date in privacy policies, privacy labels, and app store listings. Ensure that these documents match the app's actual behavior to avoid discrepancies that could mislead users or violate platform policies. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0113.md b/weaknesses/MASVS-PRIVACY/MASWE-0113.md deleted file mode 100644 index b9ccf765..00000000 --- a/weaknesses/MASVS-PRIVACY/MASWE-0113.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Lack of Proper Data Management Controls -id: MASWE-0113 -alias: data-management-controls -platform: ["android", "ios"] -profiles: ["P"] -mappings: - masvs-v1: [] - masvs-v2: [MASVS-PRIVACY-4] - cwe: [359] -refs: -- https://developer.apple.com/app-store/app-privacy-details/#privacy-links -status: new ---- - -## Overview - -When mobile apps do not provide users with mechanisms specifically designed to manage their personal data, users are left without adequate options to manage their information. This limits users' rights over their own data, leading to privacy concerns, increased severity of potential data breaches, and potential non-compliance with privacy regulations. - -These mechanisms typically include the ability for users to delete, export, modify, or opt out of data collection directly within the app interface. For example, some apps provide data management features within the settings menu, while others provide a link to an external website where users can manage their data. - -## Modes of Introduction - -- **Lack of Proper Data Management Settings**: Failing to provide users with the ability to delete, export, modify, or opt out of data collection, resulting in users having limited or no control over their personal data. - -## Impact - -- **Violation of User Rights**: Users may be unable to exercise their rights to manage their personal data, such as deleting or exporting their information, leading to a lack of control and increased privacy risks. -- **Non-Compliance with Privacy Regulations**: Non-compliance with regulations like GDPR and CCPA, which require providing users with data management capabilities, can result in fines, legal action, and other consequences. -- **Loss of User Trust**: Users may lose trust in an app that does not allow them to manage their personal data, which can lead to negative reviews, decreased user engagement, and reduced retention. - -## Mitigations - -- **Implement Data Management Mechanisms**: Ensure that mechanisms are in place for users to delete, export, or modify their data. Provide granular controls for specific aspects of data collection and sharing (e.g., location services, contacts, media access). -- **Regularly Update Data Management Features**: Regularly review and update data management features to ensure compliance with evolving regulations and user expectations. This helps maintain transparency and user trust. -- **User-Friendly Data Management Interface**: Create a user-friendly interface for data management controls, ensuring that users can easily navigate and exercise their rights over their personal data without friction. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0114.md b/weaknesses/MASVS-PRIVACY/MASWE-0114.md deleted file mode 100644 index 172b9114..00000000 --- a/weaknesses/MASVS-PRIVACY/MASWE-0114.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Inadequate Data Visibility Controls -id: MASWE-0114 -alias: data-visibility-control -platform: ["android", "ios"] -profiles: ["P"] -mappings: - masvs-v1: [] - masvs-v2: [MASVS-PRIVACY-4] - cwe: [359] -refs: -- https://firebase.google.com/support/privacy/storing-privacy-settings -- https://www.researchgate.net/publication/335863205_Demystifying_Hidden_Privacy_Settings_in_Mobile_Apps -status: new ---- - -## Overview - -If mobile apps do not give users sufficient control over how their personal information is shared with other users or the broader environment, users may inadvertently disclose sensitive data, leading to privacy concerns and unwanted attention from other users or third parties. Examples of such information include last connection status, read receipts, birthday, email address, or discoverability settings. - -Ensuring that users have clear and granular options, typically in the form of app settings, to control data visibility is critical to maintaining their privacy and building trust in the app. - -## Modes of Introduction - -- **Lack of Granular Privacy Settings**: Failing to provide privacy settings with sufficient granularity to allow users to control specific aspects of data collection and sharing, such as differentiating between location services, contacts, or media access. This lack of control results in users being unable to decide which types of information are shared and with whom. - -## Impact - -- **Exposure of Personal Data**: Users may unintentionally expose personal information, such as their email address, birthday, or online status, to others without their consent, increasing the risk of harassment or identity theft. -- **Non-Compliance with Privacy Regulations**: Apps that do not offer sufficient privacy controls may face non-compliance issues with regulations like GDPR or CCPA, which require user control over data visibility and sharing. -- **Loss of User Trust**: Users may lose trust in the app if they feel they have inadequate control over what information is shared and with whom, leading to negative reviews and decreased app engagement. - -## Mitigations - -- **Offer Granular Privacy Settings**: Provide privacy settings with sufficient granularity, allowing users to control individual data collection categories (e.g., location, contacts) and manage their sharing preferences. Allow users to choose what information is visible to others, such as connection status or discoverability. -- **User Education on Privacy Options**: Clearly inform users about available privacy settings and how to use them effectively to manage data visibility. This can be done through tutorials, help sections, or contextual tips within the app. -- **Default Privacy-Friendly Settings**: Set default privacy settings to the most restrictive options, allowing users to opt-in to sharing specific information rather than having to opt-out, which helps to ensure user privacy by default. diff --git a/weaknesses/MASVS-PRIVACY/MASWE-0117.md b/weaknesses/MASVS-PRIVACY/MASWE-0117.md deleted file mode 100644 index 546f50ab..00000000 --- a/weaknesses/MASVS-PRIVACY/MASWE-0117.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Inadequate Permission Management -id: MASWE-0117 -alias: inadequate-permission-management -platform: ["android", "ios"] -profiles: ["P"] -mappings: - masvs-v1: [] - masvs-v2: [MASVS-PRIVACY-1] - cwe: [250] -refs: -- https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission -- https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources -- https://developer.android.com/training/permissions/requesting -- https://support.google.com/googleplay/android-developer/answer/9888170?hl=en -- https://developer.android.com/privacy-and-security/minimize-permission-requests -- https://developer.android.com/training/permissions/usage-notes -- https://arxiv.org/pdf/1905.02713 -- https://arxiv.org/pdf/2203.10583 -- https://ieeexplore.ieee.org/document/9001128 -- https://www.enisa.europa.eu/sites/default/files/publications/WP2017%20O-2-2-4%20GDPR%20Mobile.pdf - -status: new ---- - -## Overview - -Permissions control access to sensitive device features such as the camera, microphone, location, and storage, making them a crucial aspect of mobile app privacy. Proper permission management is essential to protect user privacy and comply with regulations, as permissions serve as the gateway for data collection and processing. - -### First-party Apps - -First-party apps may request more permissions than necessary, sometimes overlooking privacy-friendly alternatives due to a lack of awareness, technical constraints, or business needs. Developers face the challenge of balancing functionality with privacy: while some permissions are essential for core features (e.g., a camera app requiring camera access), excessive permissions can lead to unnecessary data collection and potential privacy violations. - -From the user's perspective, privacy concerns may lead to reluctance in granting permissions, forcing them to choose between privacy and app functionality as in some cases, refusing to grant permissions could render the app unusable. Conversely, users may grant permissions without fully understanding the implications, resulting in unintended data exposure. - -### Pre-installed Apps - -Pre-installed apps frequently come with excessive permissions that users cannot control or revoke, as they are often granted by default without explicit consent. This lack of control can result in continuous data collection and persistent privacy risks. - -### Third-party Libraries (SDKs) - -**Third-party libraries (SDKs)** further complicate permission management by inheriting app permissions and introducing privacy and security risks that are difficult to audit and control. Mobile permission models often fail to distinguish between permissions granted to an app and those assigned to third-party components, a challenge highlighted in the [IEEE research paper "Engineering Privacy in Smartphone Apps"](https://ieeexplore.ieee.org/document/9001128) (Section IV, _"Third-party content"_). Furthermore, third-party services behind these SDKs may continue accessing data collected over the network even after permissions are revoked or the app is deleted, creating long-term risks for user privacy. - -## Modes of Introduction - -- **Requesting Excessive Permissions**: Apps requesting more permissions than necessary for their core functionality. -- **Lack of Use of Privacy-Friendly Alternatives**: Failing to use privacy-friendly alternatives to permissions that are less intrusive and provide users with more control over their data. For example, using coarse location instead of fine location, or using an image picker instead of requesting access to the camera and photo gallery. -- **Lack of Proactive Permission Revocation**: Not automatically revoking app permissions that are no longer necessary, resulting in unnecessary data access over time. -- **Inadequate Permission Explanations**: Failing to provide clear explanations for why each permission is required. - -## Impact - -- **Violation of User Privacy**: Users may have their personal data unnecessarily accessed by mobile apps, leading to potential misuse, identity theft, or surveillance. -- **Loss of User Trust**: Users may lose trust in an app if it requests unnecessary permissions or does not allow them to revoke permissions that are no longer relevant. This can lead to negative reviews, lower user engagement, and reduced retention. -- **Legal and Compliance Issues**: Apps that improperly manage permissions may face non-compliance with privacy regulations like GDPR or CCPA, which require data minimization and appropriate user control over data access, resulting in potential fines, legal action, or removal from app stores. -- **Malicious Abuse:** Harmful apps can misuse permissions from privileged apps to record, track, or steal data without user consent. -- **Data Breaches:** Once sensitive data leaves the app, its security can no longer be guaranteed, increasing the risk of large-scale data exposure via data breaches. - -## Mitigations - -- **Enable Proactive Permission Revocation**: Automatically revoke permissions that are no longer necessary to minimize unnecessary data access over time. Ensure that users can manually revoke permissions at any time through a clear and accessible interface. -- **Prefer Privacy-Friendly Alternatives**: Use privacy-friendly alternatives to permissions that are less intrusive and provide users with more control over their data. For example, use coarse location instead of fine location, or use an image picker instead of requesting access to the camera and photo gallery. -- **Limit Permissions to Essential Needs**: Ensure apps only request permissions necessary for core functionality, avoiding the collection of unnecessary data and adhering to the principle of data minimization. -- **Implement Just-in-Time Permission Requests**: Request permissions only when they are needed, providing clear explanations for why each permission is required. This approach helps build user trust and ensures users understand the implications of granting access to their data. -- **User Education on Permissions**: Educate users about why specific permissions are needed and how they can manage these permissions. Providing transparency builds user trust and ensures users understand the importance and relevance of each permission. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0008.md b/weaknesses/MASVS-RESILIENCE/MASWE-0008.md deleted file mode 100644 index 1b68e789..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0008.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Missing Device Secure Lock Verification Implementation -id: MASWE-0008 -alias: secured-device-detection-not-implemented -platform: [android, ios] -profiles: [L2] -mappings: - masvs-v1: [MSTG-STORAGE-11] - masvs-v2: [MASVS-RESILIENCE-1] - -refs: -- https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id -- https://grep.app/search?q=isdevicesecure%28&filter[repo][0]=threema-ch/threema-android -- https://developer.android.com/reference/android/hardware/biometrics/BiometricManager#canAuthenticate(int) -draft: - description: The app may not check for a secure device lock (e.g. device passcode) and may allow for unauthorized access to sensitive data. On iOS enforcing device lock security (i.e., ensuring a passcode is set) has an additional benefit which is that it is tightly coupled with data encryption, assuming the app leverages the correct data protection APIs. - topics: - - user set a device passcode via `isDeviceSecure()` on Android better than only ensuring that the secure screen lock is set via `KeyguardManager.isKeyguardSecure()` - - before attempting to authenticate, test to make sure that you actually have the ability to do so by calling the `LAContext.canEvaluatePolicy(_:error:)` method on iOS - - to make sure that biometrics can be used, verify that the `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly` or the `kSecAttrAccessibleWhenPasscodeSet` protection class is set when the `SecAccessControlCreateWithFlags` method is called -status: placeholder - ---- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0050.md b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md new file mode 100644 index 00000000..472753d5 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0050.md @@ -0,0 +1,46 @@ +--- +title: Debug Mechanisms Not Disabled +id: MASWE-0050 +alias: debuggable-flag +requirement: "The app disables debug mechanisms." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0050 +attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003, MAS-ATTACK-0004] +mappings: + masvs-v1: [MSTG-RESILIENCE-2] + masvs-v2: [MASVS-RESILIENCE-4, MASVS-PLATFORM-2] + cwe: [489] + android-risks: + - android-debuggable + maswe-beta: [MASWE-0067, MASWE-0074] +refs: +- https://developer.android.com/guide/topics/manifest/application-element +- https://developer.android.com/reference/android/webkit/WebView#setWebContentsDebuggingEnabled(boolean) +- https://developer.apple.com/documentation/webkit/wkwebview/4111163-isinspectable +- https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.debugger +--- + +## Overview + +This weakness occurs when the application has debug mechanisms enabled in production builds, allowing the usage of platform debuggers, or exposes embedded web or JavaScript content to developer inspection tools. + +Mobile apps typically include configuration flags and mechanisms that enable debugging. While these are essential during development, leaving them enabled in production makes the app inspectable and manipulable. + +Beyond the application-level debuggable flag, this weakness also covers web-content debugging, which lets a remote inspector attach to the app's web content (e.g. Android's [`WebView.setWebContentsDebuggingEnabled(true)`](https://developer.android.com/reference/android/webkit/WebView#setWebContentsDebuggingEnabled(boolean)) or iOS's [`WKWebView.isInspectable`](https://developer.apple.com/documentation/webkit/wkwebview/isinspectable)). Like the debuggable flag, this must be disabled in production builds. + +## Modes of Introduction + +- **Misconfigured Build Settings**: Accidentally leaving the app in a debuggable state through improper selection of build variants, errors in CI/CD configurations, or mistakenly applying debug settings to production environments. +- **WebView or JavaScript Debugging Enabled**: Leaving WebView content debugging enabled in production (e.g. `setWebContentsDebuggingEnabled(true)` on Android or `isInspectable = true` on iOS). + +## Impact + +- **Compromise of Sensitive Data**: Attackers can read the app's memory and logs to obtain encryption keys, API keys, user credentials, or tokens that are never written to the app's code or disk, resulting in unauthorized disclosure of secrets and user data. +- **Authentication or Authorization Bypass**: Attackers can manipulate the app's execution flow to skip authentication and authorization checks, resulting in unauthorized access to protected functionality. +- **Facilitated Reverse Engineering and Instrumentation**: Debug access reduces the effort required to observe and manipulate the application's behavior and may facilitate further dynamic analysis or instrumentation. + +## Mitigations + +- **Disable Application Debugging in Release Builds**: Ensure that the debuggable flag in the app's configuration file is not enabled for production builds. For example, set [`isDebuggable = false` or `debuggable false`](https://developer.android.com/studio/publish/preparing) in Android or ensure that the `get-task-allow` entitlement is absent or set to `false` in iOS applications. +- **Disable WebView and JavaScript Content Debugging in Release Builds**: Ensure that the WebViews and JavaScript contexts in the application are not debuggable. For example, do not call `setWebContentsDebuggingEnabled(true)` on Android and keep `WKWebView.isInspectable` set to `false` on iOS. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0051.md b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md new file mode 100644 index 00000000..4c70d4a4 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0051.md @@ -0,0 +1,42 @@ +--- +title: Code Obfuscation Not Implemented +id: MASWE-0051 +alias: code-obfuscation +requirement: "The app implements code obfuscation." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0051 +attacks: [MAS-ATTACK-0001] +mappings: + masvs-v1: [MSTG-RESILIENCE-9, MSTG-RESILIENCE-12] + masvs-v2: [MASVS-RESILIENCE-3] + cwe: [693] + maswe-beta: [MASWE-0089, MASWE-0091, MASWE-0092] +refs: +- https://developer.android.com/topic/performance/app-optimization/enable-app-optimization#overview +--- + +## Overview + +This weakness occurs when an app's code, particularly its security-relevant logic, ships without effective obfuscation, facilitating reverse engineering and static analysis. + +Obfuscation does not prevent reverse engineering, but it raises its cost. Identifier renaming or string encryption are easier to implement and are considered common obfuscation techniques. However, there are other obfuscation techniques, like control-flow transformations, opaque predicates, instruction substitution, instruction block chopping, and method inlining, as well as hindering decompilers from producing usable output. Most of these techniques can be combined together. + +## Modes of Introduction + +- **No Obfuscation Applied**: Shipping release builds without any minification or obfuscation, leaving class, method, and symbol names intact. +- **Security-Relevant Logic Left Readable**: Not applying enough obfuscation to security-relevant code, leaving code sections like security checks, licensing logic, and proprietary algorithms trivially analyzable. +- **Obfuscation Without Hardening**: Applying standard obfuscation whose transformations are automatically reversible by publicly available tooling. + +## Impact + +- **Bypass of Protection Mechanisms**: Attackers can quickly locate and defeat client-side checks such as root detection, licensing, or anti-tampering logic, resulting in the circumvention of the app's defenses. +- **Compromise of Sensitive Data**: Attackers can recover proprietary algorithms and embedded secrets from readable code, resulting in intellectual property theft and easier planning of further attacks. + +## Mitigations + +- **Enable Obfuscation for Release Builds**: Apply the platform's minification and obfuscation tooling or established commercial obfuscators to all release builds. +- **Harden Security-Relevant Code**: Apply stronger transformations (opaque predicates, instruction substitution, control-flow obfuscation, method inlining) to the security-relevant code. +- **Implement Lossy Obfuscation**: Implement obfuscation in a way that intentionally removes information from the code, rather than only shift things around. +- **Assess Obfuscation Effectiveness**: Regularly attempt to reverse engineer the release build with state-of-the-art decompilers and deobfuscators to validate that the protection meets its goal. +- **Combine with Runtime Protections**: Pair obfuscation with runtime integrity and anti-instrumentation checks (see the mitigations in @MASWE-0053, @MASWE-0061, @MASWE-0064), since obfuscation alone only delays attackers. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0052.md b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md new file mode 100644 index 00000000..4514f2e8 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0052.md @@ -0,0 +1,37 @@ +--- +title: Resource Obfuscation Not Implemented +id: MASWE-0052 +alias: resource-obfuscation +requirement: "The app applies resource obfuscation to hinder reverse engineering." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0052 +attacks: [MAS-ATTACK-0001] +mappings: + masvs-v1: [MSTG-RESILIENCE-11] + masvs-v2: [MASVS-RESILIENCE-3] + cwe: [693] + maswe-beta: [MASWE-0090] +--- + +## Overview + +This weakness occurs when an app's resources and assets are left in clear, unprotected form, revealing how the app works and aiding reverse engineering. + +In addition to application code, various artifacts such as strings, layouts, configuration files and bundled data all contain information about the app's inner workings. Attackers mining the package can use them to map features, find security-relevant configuration, and identify targets for tampering. Note that obfuscation or encryption applied without integrity validation can itself be tampered with, so resource protection should complement, not replace, integrity checks (see @MASWE-0063). + +## Modes of Introduction + +- **Resources Left in Clear**: Shipping strings, configuration, and other assets unobfuscated and unencrypted in the application package. +- **Identifiers Left Meaningful**: Keeping descriptive resource and string identifiers that map directly to features and security controls. + +## Impact + +- **Bypass of Protection Mechanisms**: Attackers can locate security-relevant configuration and assets and use cross-references to target the app's security-relevant code locations, resulting in easier circumvention of its protections. +- **Compromise of Sensitive Data**: Attackers can extract proprietary content and internal information from clear resources, resulting in intellectual property exposure. + +## Mitigations + +- **Obfuscate Sensitive Resources**: Obfuscate strings, configuration, and assets that reveal security-relevant behavior. +- **Obfuscate Resource Identifiers**: Replace meaningful resource and string identifiers with non-descriptive ones in release builds. +- **Validate Resource Integrity**: Combine resource protection with integrity verification (see @MASWE-0063) so protected resources cannot simply be replaced. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0053.md b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md new file mode 100644 index 00000000..f82a08bb --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0053.md @@ -0,0 +1,42 @@ +--- +title: Malware Detection Not Implemented +id: MASWE-0053 +alias: malware-detection +requirement: "The app detects attacks by malware." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0076 +attacks: [MAS-ATTACK-0036, MAS-ATTACK-0052] +mappings: + masvs-v2: [MASVS-RESILIENCE-2] + cwe: [693] +refs: +- https://developers.google.com/android/play-protect +- https://developers.google.com/android/play-protect/client-protections +--- + +## Overview + +This weakness occurs when an app does not implement or integrate techniques to detect malware on the device or malicious apps and components that could target it. + +Mobile malware commonly attacks other apps indirectly: abusing accessibility services to read screens and drive the UI, drawing overlays to phish credentials, or exploiting a compromised runtime environment. For high-assurance apps, detecting a potentially hostile environment, e.g. known malicious packages, apps holding accessibility or overlay capabilities, or platform threat signals such as Google Play Protect status, allows the app to warn the user, restrict functionality, or trigger other protective responses. This complements environment-integrity checks such as @MASWE-0056 and platform services such as the Play Integrity API. + +## Modes of Introduction + +- **No Hostile-Environment Checks**: Not checking for known malicious packages or platform threat signals before enabling sensitive functionality. +- **Abuse-Prone Capabilities Ignored**: Not considering apps holding accessibility or overlay capabilities in the app's risk decisions for sensitive flows (see @MASWE-0031, @MASWE-0039). +- **No Response Strategy**: Detecting a hostile environment but not warning the user or restricting sensitive functionality. +- **Insufficient Response Strategy**: Only responding on the current device, rather than on the account level. Malware will often intercept credentials and use them to onboard a legitimate app onto an attacker-controlled device. As part of the response strategy, risky behaviour (such as onboarding the app on a new device) must be blocked in case of a suspected compromise. + +## Impact + +- **Compromise of Sensitive Data**: Malware can capture credentials, one-time codes, and displayed content while the app takes no protective action, resulting in exposure of user data the app could have defended. +- **Financial Loss**: Malware can automate or manipulate transactions against the unprotected app, resulting in direct financial harm to users and fraud losses for the app owner. + +## Mitigations + +- **Integrate Platform Threat Signals**: Use available platform services (e.g. Play Protect status, Play Integrity verdicts) to learn about known malware and a compromised environment. +- **Assess Risky Capabilities**: Factor the presence of accessibility- or overlay-capable apps into risk decisions for sensitive flows, combined with the UI-level defenses of @MASWE-0031 and @MASWE-0039. +- **Respond Proportionately**: Warn the user, require additional verification, restrict functionality, or block sensitive operations when a hostile environment is detected. +- **Lock Down Account**: Apply restrictions to the account, not just the local client. This will prevent attackers from performing actions on a non-hostile environment after the initial compromise. +- **Assess Effectiveness**: Validate the detection against current malware behaviors and update it as the threat landscape evolves. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0054.md b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md new file mode 100644 index 00000000..4863a9b2 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0054.md @@ -0,0 +1,43 @@ +--- +title: Debug Artifacts Not Removed +id: MASWE-0054 +alias: non-production-resources +requirement: "The app does not contain debug artifacts." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0054 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0006] +mappings: + masvs-v1: [MSTG-CODE-3, MSTG-CODE-4] + masvs-v2: [MASVS-RESILIENCE-3] + cwe: [489, 497, 540, 912, 1295] + android-risks: + - test-debug + android-core-app-quality: [Production_Build_Quality] + maswe-beta: [MASWE-0094, MASWE-0093, MASWE-0095] +--- + +## Overview + +This weakness occurs when an app ships to production containing developer debug artifacts, such as verbose logging, testing utilities, debugging symbols, or leftover debug and test code. + +Such artifacts help adversaries understand the app's behavior and internals, may include sensitive implementation details, and, most critically, may include backdoors, such as hidden switches enabling debug menus or an insecure trust manager, that can disable security controls like TLS certificate validation. Note the distinction from @MASWE-0006: that weakness covers developer leftover artifacts that leak confidentiality (staging URLs, developer identities, source files), while this one covers debug artifacts that weaken the app's resilience. + +## Modes of Introduction + +- **Verbose Logging and Debug Flows**: Leaving verbose or debug-level logging and diagnostic code paths active in production builds. +- **Testing Utilities Enabled**: Shipping with development-time utilities enabled, such as StrictMode on Android. +- **Debugging Symbols Not Stripped**: Releasing binaries with debugging symbols that map the code for reverse engineers. +- **Backdoors or Hidden Switches and Debug Menus**: Leaving debug or test code that can disable security controls, e.g. an insecure trust manager or a hidden configuration flag that turns off TLS verification. + +## Impact + +- **Bypass of Protection Mechanisms**: Attackers can activate leftover debug switches or code paths that disable security controls such as certificate validation, resulting in the defeat of protections the production app is supposed to enforce. +- **Compromise of Sensitive Data**: Attackers can use verbose logs, symbols, and debug flows to learn implementation details and extract sensitive values, resulting in information disclosure that enables further attacks. + +## Mitigations + +- **Strip Symbols and Debug Code**: Remove debugging symbols and compile debug-only code paths out of release builds using build variants and flags. +- **Disable Verbose Logging in Production**: Ensure debug and verbose logging is removed or disabled in release configurations. +- **Remove Testing Utilities**: Keep development-time utilities such as StrictMode out of production builds. +- **Eliminate Backdoors**: Enforce code review and release checks that reject hidden switches, test hooks, or alternative code paths capable of weakening security controls in production. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0055.md b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md new file mode 100644 index 00000000..1d6c0ae6 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0055.md @@ -0,0 +1,37 @@ +--- +title: No Application-Level Payload Encryption +id: MASWE-0055 +alias: data-unencrypted +requirement: "The app applies application-level payload encryption in addition to transport-layer encryption." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0055 +attacks: [MAS-ATTACK-0064] +mappings: + masvs-v1: [MSTG-RESILIENCE-13] + masvs-v2: [MASVS-RESILIENCE-3, MASVS-NETWORK-1] + cwe: [319] + maswe-beta: [MASWE-0096] +--- + +## Overview + +This weakness occurs when an app relies solely on transport-layer encryption for its network traffic, without an additional layer of application-level payload encryption. + +Even when the connection uses HTTPS, an attacker who controls the device can bypass transport protections (for example by defeating certificate pinning with instrumentation) and observe or tamper with the plaintext payloads, revealing the inner workings of the app and its API. Application-level payload encryption raises the effort required to analyze and manipulate the app's traffic. This is a resilience measure aimed at hindering analysis and abuse; it complements rather than replaces transport security (see @MASWE-0025, @MASWE-0027). + +## Modes of Introduction + +- **TLS-Only Protection**: Sending security-relevant API payloads with no protection beyond the transport channel, so they appear in plaintext as soon as TLS is intercepted on a controlled device. +- **No Integrity Binding on Requests**: Not signing or otherwise binding sensitive requests, so intercepted payloads can be modified and replayed once the transport layer is bypassed. + +## Impact + +- **Compromise of System Integrity and Business Operations**: Attackers can map the app's API and craft or tamper with requests, resulting in fraud, scraping, and abuse of backend services at the app owner's expense. +- **Bypass of Protection Mechanisms**: Attackers can easily modify payloads that carry security-relevant state, without having to reverse-engineer the application to first circumvent the additional encryption. + +## Mitigations + +- **Encrypt Sensitive Payloads at the Application Layer**: Apply an additional layer of encryption to security-relevant payloads before they enter the transport channel, using keys managed via the platform keystore. +- **Sign Security-Relevant Requests**: Authenticate and integrity-protect sensitive requests (e.g. with signatures bound to attested, hardware-backed keys) so tampered payloads are rejected server-side. +- **Treat It as Defense in Depth**: Keep full transport security (TLS and pinning) in place; application-level encryption raises analysis effort but is still client-side and ultimately bypassable. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0056.md b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md new file mode 100644 index 00000000..95c37530 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0056.md @@ -0,0 +1,40 @@ +--- +title: Root/Jailbreak Detection Not Implemented +id: MASWE-0056 +alias: root-jailbreak-detection +requirement: "The app detects if it runs on a rooted/jailbroken device and reacts appropriately." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0056 +attacks: [MAS-ATTACK-0003, MAS-ATTACK-0005, MAS-ATTACK-0065] +mappings: + masvs-v1: [MSTG-RESILIENCE-1, MSTG-RESILIENCE-8] + masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] + cwe: [1326] + +status: new +--- + +## Overview + +This weakness occurs when an app does not implement effective techniques to detect whether the device it runs on is rooted or jailbroken. + +On a rooted or jailbroken device, the platform's sandboxing and permission guarantees no longer hold: privileged users and tools (e.g. Magisk, SuperSU, Xposed, or jailbreak toolchains and their managers) can access the app's private data, instrument its process, and defeat its client-side controls. More broadly, the app should apply Runtime Application Self-Protection (RASP) techniques that detect a compromised environment and trigger appropriate responses. + +## Modes of Introduction + +- **No Detection Implemented**: Shipping without any checks for rooting or jailbreak artifacts, such as management apps, su binaries, hooking frameworks, modified system properties, or writable system partitions. +- **Naive or Single-Point Checks**: Implementing one easily located check whose removal or hooking disables the entire defense. +- **No Response Strategy**: Detecting a compromised environment but not responding to it in a way appropriate to the app's risk profile. + +## Impact + +- **Bypass of Protection Mechanisms**: Attackers can use elevated privileges to defeat the app's client-side security controls, resulting in the circumvention of protections such as anti-tampering, licensing, or fraud controls. +- **Compromise of Sensitive Data**: Attackers can read the app's private data and intercept its runtime state without sandbox restrictions, resulting in exposure of user data, keys, and tokens. + +## Mitigations + +- **Implement Layered Detection**: Combine multiple, varied checks (file-system artifacts, system properties, management apps, behavioral probes) implemented in different layers (e.g. native code) so no single patch disables them all. +- **Respond Appropriately**: Define graded responses to detection, from warning the user to restricting sensitive functionality or terminating, matched to the app's risk profile. +- **Combine with Attestation**: Back local checks with server-verified device attestation (see @MASWE-0059) so the backend can act on integrity signals even if local checks are bypassed. +- **Assess Effectiveness**: Regularly test the detection against publicly available bypass tools and update it as evasion techniques evolve. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0057.md b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md new file mode 100644 index 00000000..16490596 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0057.md @@ -0,0 +1,41 @@ +--- +title: App Virtualization Environment Detection Not Implemented +id: MASWE-0057 +alias: app-virtualization-detection +requirement: "The app detects when it is running inside an app-virtualization environment." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0057 +attacks: [MAS-ATTACK-0067] +mappings: + masvs-v2: [MASVS-RESILIENCE-1] + cwe: [693] + maswe-beta: [MASWE-0098] +--- + +## Overview + +This weakness occurs when an app does not detect that it is running inside an app-virtualization or cloning environment. + +App virtualization and "dual-app" container frameworks run an app inside another app's process, letting the hosting app intercept its calls, access its data, and instrument it, all without rooting the device. They also enable running multiple cloned instances of the same app. An app that does not check for anomalies in its process path and package structure, or for known virtualization frameworks, cannot respond to running in such a hostile host. + +## Modes of Introduction + +- **No Virtualization Checks**: Not verifying the app's process path, package structure, or runtime environment for signs of running inside another app's process. +- **Known Frameworks Not Detected**: Not checking for artifacts of known virtualization and cloning frameworks. +- **No Response Strategy**: Detecting a virtualized environment but continuing to operate normally with sensitive functionality enabled. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can intercept the virtualized app's files, credentials, and API calls from the hosting app, resulting in exposure of user data without requiring root access. +- **Bypass of Protection Mechanisms**: Attackers can instrument the app inside the container to defeat its client-side controls, resulting in the circumvention of its defenses on unrooted devices. +- **Compromise of System Integrity and Business Operations**: Attackers can run multiple cloned instances to abuse promotions or multi-account limits, resulting in fraud against the app owner. +- **Lack of Server-Verified Platform Attestation**: Failing to validate the app's package identity, signing certificate via hardware-backed platform attestation (e.g., Play Integrity or App Attest) on a backend server, allowing the app to execute unchecked inside virtual containers or cloned spaces. + +## Mitigations + +- **Detect Environment Anomalies**: Verify the app's process path, data directory, and package structure at runtime and treat mismatches as indicators of virtualization. +- **Check for Known Frameworks**: Detect artifacts of known virtualization and cloning frameworks and their hosting packages. +- **Respond to Detection**: Restrict sensitive functionality, notify the backend, or terminate when a virtualized environment is detected, according to the app's risk profile. +- **Assess Effectiveness**: Test the detection against current virtualization frameworks and update it as they evolve. +- **Attest Application Integrity**: Use platform attestation frameworks such as Play Integrity on Android or App Attest on iOS (see @MASWE-0059) with backend nonce verification to validate the official package name, signing certificate, and application integrity. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0058.md b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md new file mode 100644 index 00000000..a26dfa9e --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0058.md @@ -0,0 +1,46 @@ +--- +title: Emulated or Virtual Device Detection Not Implemented +id: MASWE-0058 +alias: emulated-virtual-device-detection +requirement: "The app detects when it is running in an emulated or virtual device environment." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0058 +attacks: [MAS-ATTACK-0003, MAS-ATTACK-0066] +mappings: + masvs-v1: [MSTG-RESILIENCE-5, MSTG-RESILIENCE-8] + masvs-v2: [MASVS-RESILIENCE-1, MASVS-RESILIENCE-4] + maswe-beta: [MASWE-0099, MASWE-0103] +refs: +- https://developer.android.com/google/play/integrity/overview +- https://developer.android.com/google/play/integrity/verdicts +- https://github.com/eltavine/Duck-Detector-Refactoring +- https://github.com/Lakr233/vphone-cli +- https://developer.apple.com/documentation/devicecheck +- https://ieeexplore.ieee.org/document/10935812 + +--- + +## Overview + +This weakness occurs when an app does not implement effective techniques to detect that it is running in an emulator or virtual device. + +Emulators give attackers a fully controlled, snapshottable environment for analyzing the app, automating interactions, and running it at scale in bot farms. Detection typically relies on identifying the features and limitations of commonly used emulation solutions, such as characteristic device identifiers, emulator-specific file-paths, hardware properties, sensors, and timing behavior. + +## Modes of Introduction + +- **No Emulator Checks**: Shipping without any verification of device properties, hardware features, or sensor behavior that distinguish emulators from real devices. +- **Single-Source Detection Signals**: Relying on a single source of emulation or virtualization indicators (e.g. system properties) that emulators can trivially fake. +- **No Response Strategy**: Detecting an emulated environment but not adapting the app's behavior in response. + +## Impact + +- **Bypass of Protection Mechanisms**: Attackers can iterate on bypasses of the app's defenses with snapshots and full inspection, resulting in faster and cheaper circumvention of its protections. +- **Compromise of System Integrity and Business Operations**: Attackers can run automated fleets of emulated instances, resulting in bot-driven fraud, fake accounts, and abuse of the app owner's services. + +## Mitigations + +- **Detect Emulator Characteristics**: Check device identifiers, hardware capabilities, sensor availability, file paths and behavioral traits that differ between emulators and physical devices, combining multiple signals. +- **Respond to Detection**: Restrict sensitive functionality, require additional verification, or terminate when an emulated environment is detected, according to the app's risk profile. +- **Combine with Attestation**: Use server-verified device attestation (see @MASWE-0059) so emulated environments are also flagged independently of local checks. +- **Assess Effectiveness**: Test the detection against popular emulators and hardening/evasion tools and refine it over time. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0059.md b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md new file mode 100644 index 00000000..fc4db041 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0059.md @@ -0,0 +1,64 @@ +--- +title: Device Attestation Not Implemented +id: MASWE-0059 +alias: device-attestation +requirement: "The app implements device attestation." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0059 +attacks: [MAS-ATTACK-0065, MAS-ATTACK-0066, MAS-ATTACK-0068] +mappings: + masvs-v1: [MSTG-RESILIENCE-10] + masvs-v2: [MASVS-RESILIENCE-1] + maswe-beta: [MASWE-0100] +refs: +- https://developer.android.com/google/play/integrity +- https://developer.android.com/google/play/integrity/verdicts +- https://developer.android.com/google/play/integrity/standard +- https://developer.android.com/google/play/integrity/classic +- https://github.com/android/keyattestation +- https://source.android.com/docs/security/features/keystore/attestation +- https://grapheneos.org/articles/attestation-compatibility-guide +- https://developer.apple.com/documentation/devicecheck +- https://developer.apple.com/documentation/devicecheck/accessing-and-modifying-per-device-data +- https://developer.apple.com/documentation/devicecheck/establishing-your-app-s-integrity +- https://developer.apple.com/documentation/devicecheck/validating-apps-that-connect-to-your-server +- https://github.com/Oliver-Binns/app-attest +- https://github.com/VisionR1/KeyAttestation +- https://github.com/JingMatrix/TEESimulator +- https://github.com/5ec1cff/TrickyStore +--- + +## Overview + +This weakness occurs when an app does not implement device attestation, so its backend cannot distinguish requests made from genuine, uncompromised devices from those coming from rooted, emulated, tampered, or automated environments. + +Device attestation uses platform services, such as the standard Android hardware attestation API, the Play Integrity API or iOS DeviceCheck and App Attest, to provide the backend with cryptographically verifiable evidence about the device associated with a request. The evidence and security properties differ by platform and service. Without device attestation, the backend cannot independently verify device-origin claims made by the client. The backend must validate attestation evidence and apply the service-specific request-binding, freshness, and replay protections; client-side evaluation is another bypassable local check. + +On Android, both the hardware-backed attestation and Play Integrity APIs can provide server-verifiable assurance that the device has not been compromised in ways covered by its device-integrity verdicts or signals, such as an unlocked bootloader, an unrecognized operating-system image or an outdated security patch level. Their main differences include: + +- **Google Mobile Services (GMS) Requirement**: Direct hardware-backed key attestation uses Android Keystore and does not require Google Play services on the device to request an attestation. Play Integrity depends on Google Play components and Google services. +- **Verdict Generation and Policy Enforcement**: With direct key attestation, the backend receives signed properties and defines which boot states, operating-system signing keys, patch levels, and application identities it accepts. Play Integrity evaluates the available signals and returns Google-defined verdict labels. In both cases, the developer decides how the backend responds. + +On iOS, DeviceCheck and App Attest do not provide equivalent assurance about operating-system compromise. They can establish that evidence originates from genuine Apple hardware; App Attest also binds that evidence to a legitimate app instance, but neither service attests the integrity of iOS. + +## Modes of Introduction + +- **No Attestation Integrated**: Not using the platform's attestation services at all, leaving the backend with no device-integrity signal. +- **Client-Side-Only Verification**: Requesting attestation but evaluating the verdict in the app instead of verifying it server-side. +- **Missing Freshness Guarantees**: Verifying attestation without a server-issued nonce or timeliness check, allowing verdicts to be replayed. +- **Verdicts Not Enforced**: Collecting attestation results but not gating sensitive operations on them. +- **Incomplete Evidence Validation**: Accepting device-attestation evidence without applying the service-specific checks for request binding, replay protection, and the device claims required by the backend's policy. + +## Impact + +- **Compromise of System Integrity and Business Operations**: Attackers can drive the backend with automated or tampered clients, resulting in fraud, scraping, fake accounts, and abuse of the app owner's services. +- **Bypass of Protection Mechanisms**: Attackers can leverage tampered running environments to bypass the app's security checks or feature restrictions, resulting in unauthorized access to protected app functionality. +- **Financial Loss**: Attackers can abuse promotions, premium features, or transaction flows from unattested environments, resulting in direct monetary loss to the app owner. + +## Mitigations + +- **Integrate Platform Attestation**: Validate the [rootOfTrust](https://source.android.com/docs/security/features/keystore/attestation#rootoftrust-fields) fields from the key attestation extension or use Play Integrity API and iOS DeviceCheck / App Attest to obtain device- and app-integrity verdicts. +- **Verify Server-Side with Freshness**: Have the backend verify attestation tokens cryptographically, bind them to a server-issued nonce, and check timeliness before trusting them. +- **Gate Sensitive Operations on Verdicts**: Require valid attestation for high-risk API calls and degrade or deny service to unattested clients. +- **Layer with Local Checks**: Combine attestation with local environment checks (see @MASWE-0056, @MASWE-0058) for defense in depth, and assess the overall scheme against known bypasses. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0060.md b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md new file mode 100644 index 00000000..c16f75ba --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0060.md @@ -0,0 +1,44 @@ +--- +title: Debugger Detection Not Implemented +id: MASWE-0060 +alias: debugger-detection +requirement: "The app detects debugger attachment at runtime and responds to protect sensitive operations." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0060 +attacks: [MAS-ATTACK-0002] +mappings: + masvs-v1: [MSTG-RESILIENCE-2] + masvs-v2: [MASVS-RESILIENCE-4] + maswe-beta: [MASWE-0101] +refs: +- https://developer.android.com/reference/android/os/Debug#isDebuggerConnected() +- https://man7.org/linux/man-pages/man5/proc_pid_status.5.html +- https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/ptrace.2.html +- https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/sysctl.3.html +- https://www.youtube.com/watch?v=ih6gWZDuNME +--- + +## Overview + +This weakness occurs when an app does not detect the presence of a debugger attached to it at runtime. + +A debugger lets an attacker inspect memory, set breakpoints, and alter control flow to bypass client-side controls, even when the release build is not flagged as debuggable (see @MASWE-0050 for that case). Platforms offer detection primitives such as `Debug.isDebuggerConnected()` (Java debugging) and the `TracerPid` field in `/proc/self/status` on Android (Native debugging), or `sysctl`- and `ptrace`-based checks on iOS. Without such checks and a response, a debugger can be attached and used against the app unnoticed. + +## Modes of Introduction + +- **No Debugger Checks**: Shipping without any runtime verification that a debugger is attached to the process. +- **One-Time or Single-Point Checks**: Checking only at startup or in a single code path instead of around sensitive operations and throughout runtime. +- **No Response Strategy**: Detecting a debugger but not reacting in a way that protects the app's sensitive operations. + +## Impact + +- **Bypass of Protection Mechanisms**: Attackers can alter control flow at breakpoints to skip the app's client-side checks, resulting in the circumvention of its defenses. +- **Compromise of Sensitive Data**: Attackers can read secrets and user data from process memory during debugging, resulting in exposure of credentials, keys, and tokens. + +## Mitigations + +- **Implement Debugger Detection**: Use platform primitives (e.g. `Debug.isDebuggerConnected()`, `TracerPid`, `sysctl`/`ptrace`-based checks) implemented in multiple layers, including native code. +- **Check Continuously**: Run detection periodically and around sensitive operations, not only at startup, so late attachment is also caught. +- **Respond to Detection**: Terminate, wipe sensitive state, or restrict functionality when a debugger is detected, according to the app's risk profile. +- **Assess Effectiveness**: Test the checks against common anti-anti-debugging techniques and refine them over time. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0061.md b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md new file mode 100644 index 00000000..b454d499 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0061.md @@ -0,0 +1,48 @@ +--- +title: Dynamic Analysis Tools Detection Not Implemented +id: MASWE-0061 +alias: dynamic-analysis-tools +requirement: "The app detects dynamic analysis tools and responds to protect sensitive operations." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0061 +attacks: [MAS-ATTACK-0003] +mappings: + masvs-v1: [MSTG-RESILIENCE-4] + masvs-v2: [MASVS-RESILIENCE-4] + maswe-beta: [MASWE-0102] +refs: +- https://frida.re/docs/home/ +- https://github.com/LSPosed/LSPosed +- https://github.com/LSPosed/LSPlant +- https://www.cydiasubstrate.com/api/c/MSHookFunction/ +- https://github.com/tealbathingsuit/ellekit +- https://github.com/roothide/Bootstrap +- https://burjcdigital.urjc.es/server/api/core/bitstreams/d249ebbb-5923-48ea-9215-af14cf2cc0b9/content +--- + +## Overview + +This weakness occurs when an app does not detect the presence of dynamic instrumentation and hooking frameworks at runtime. + +Tools such as Frida, Xposed/LSPosed, and ElleKit/Cydia Substrate let attackers observe and modify the app while it runs, replacing method implementations and defeating client-side security controls. These frameworks can leave detectable artifacts, such as loaded libraries, named pipes, listening ports, installed hooks, or framework-specific classes, but attackers can often rename, relocate, hide, or patch these indicators to bypass shallow detection. Without layered detection and a response, instrumentation can proceed unnoticed. + +Unlike runtime code integrity verification (see @MASWE-0064), this weakness focuses on detecting the presence of instrumentation tools and frameworks through tool-specific indicators. On the other hand, runtime code integrity verification checks whether loaded code, executable memory, or security-critical functions were modified, even when no known tool artifact is present. + +## Modes of Introduction + +- **No Instrumentation Checks**: Shipping without any detection of well-known instrumentation and hooking frameworks. +- **Artifact Checks Missing or Shallow**: Not checking for hooking artifacts such as suspicious loaded libraries, named pipes, listening ports, or known trampoline instruction sequences in function prologues, or checking only from easily hooked Java/Swift code. +- **No Response Strategy**: Detecting instrumentation but continuing to expose sensitive functionality. + +## Impact + +- **Bypass of Protection Mechanisms**: Attackers can hook and replace the app's security checks at runtime, resulting in the circumvention of its client-side defenses, including root, debugger, and integrity checks. +- **Compromise of Sensitive Data**: Attackers can intercept function arguments and memory contents during instrumentation, resulting in exposure of credentials, keys, and user data. + +## Mitigations + +- **Detect Instrumentation Artifacts**: Check for known frameworks and their artifacts (loaded libraries, named pipes, listening ports, hooked functions), implementing the checks in native code where they are harder to bypass. +- **Check Continuously and Diversify**: Run varied checks at multiple points in the app lifecycle so a single hook cannot disable them all. +- **Respond to Detection**: Terminate, restrict sensitive functionality, or signal the backend when instrumentation is detected. +- **Assess Effectiveness**: Regularly test the detection against current instrumentation tools and their evasion modules, and update it as they evolve. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0062.md b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md new file mode 100644 index 00000000..a014142c --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0062.md @@ -0,0 +1,43 @@ +--- +title: App Attestation Not Implemented +id: MASWE-0062 +alias: app-integrity +requirement: "The app implements app attestation." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0062 +attacks: [MAS-ATTACK-0040, MAS-ATTACK-0068, MAS-ATTACK-0069] +mappings: + masvs-v1: [MSTG-CODE-1] + masvs-v2: [MASVS-RESILIENCE-2] + cwe: [347] + maswe-beta: [MASWE-0104, MASWE-0106] +refs: +- https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format +- https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service +--- + +## Overview + +This weakness occurs when an app does not attest its own authenticity and integrity, i.e. it implements no effective techniques to verify that the running binary is a genuine, unmodified copy of the app. + +App attestation includes verifying the app's signature and binaries at runtime, detecting an invalid or unexpected signing certificate, and using platform attestation services that vouch for the app's identity (e.g. App Attest on iOS, Play Integrity app verdicts on Android). It also covers using current signing schemes: outdated formats, such as Android V1-only signatures or an iOS CodeDirectory version below 20400, weaken the platform's own integrity guarantees. Verifying the package or signature against expected values, which also provides official-store assurance, remains one of the applicable techniques. + +## Modes of Introduction + +- **No Runtime Integrity Verification**: Not verifying the app's signature, package identity, or binaries at runtime, so a repackaged copy runs unnoticed. +- **No Platform App Attestation**: Not using platform services that attest the app's identity to the backend, so servers cannot distinguish genuine clients from modified ones. +- **Outdated Signing Schemes**: Signing releases with outdated formats (e.g. Android V1-only signatures, iOS CodeDirectory below version 20400) that are easier to abuse. + +## Impact + +- **Bypass of Protection Mechanisms**: Attackers can strip resiliency controls from a repackaged copy, making it easier to further analyze and reverse-engineer the application. +- **Compromise of Sensitive Data**: Attackers can distribute trojanized versions of the app that harvest credentials and data from the users they deceive, resulting in account compromise attributed to the app. +- **Compromise of System Integrity and Business Operations**: Modified clients, cracked features, and cloned apps circulate under the app's brand, resulting in revenue loss and reputational damage for the app owner. + +## Mitigations + +- **Verify App Integrity at Runtime**: Check the app's signing certificate, package identity, and binaries at runtime against expected values, implementing checks in layers that are harder to patch out (e.g. native code). +- **Use Platform App Attestation**: Integrate services such as iOS App Attest or Play Integrity app verdicts and verify their results server-side, so the backend rejects modified or repackaged clients. +- **Use Current Signing Schemes**: Sign releases with up-to-date signature formats and rotate away from deprecated ones. +- **Respond to Failed Checks**: Terminate, restrict functionality, or flag the session to the backend when integrity verification fails, and assess the checks against known bypass techniques. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0063.md b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md new file mode 100644 index 00000000..15b418f2 --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0063.md @@ -0,0 +1,46 @@ +--- +title: App Resources Integrity Not Verified +id: MASWE-0063 +alias: app-resources-integrity +requirement: "The app verifies the integrity of its resources." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0063 +attacks: [MAS-ATTACK-0009, MAS-ATTACK-0070] +mappings: + masvs-v1: [MSTG-RESILIENCE-3] + masvs-v2: [MASVS-RESILIENCE-2, MASVS-CODE-4] + cwe: [471] + maswe-beta: [MASWE-0105] +refs: +- https://developer.android.com/privacy-and-security/cryptography +- https://developer.android.com/privacy-and-security/keystore +- https://developer.apple.com/documentation/cryptokit/hmac +- https://developer.apple.com/documentation/cryptokit/storing-cryptokit-keys-in-the-keychain +- https://developer.apple.com/documentation/security/restricting-keychain-item-accessibility +--- + +## Overview + +This weakness occurs when an app does not verify that the resources it relies on have not been tampered with. + +Beyond the app package, apps depend on non-executable resources whose integrity matters: files in the app sandbox, configuration, downloaded content, and data restored from backups. An attacker who can alter these resources can change the app's behavior or inject malicious content without modifying its packaged code, sidestepping package- and code-integrity checks (see @MASWE-0062, @MASWE-0064). Safe dynamic code loading is covered by @MASWE-0044. + +## Modes of Introduction + +- **Sandbox Files Not Verified**: Trusting files in the app's data directory without verifying their integrity. +- **Downloaded Resources Not Verified**: Using downloaded content or configuration without verifying its integrity and authenticity. +- **Restored Data Not Revalidated**: Using data restored from backups or device transfers without revalidating its integrity. +- **Verification Result Ignored**: Continuing to use a resource after its integrity verification fails. + +## Impact + +- **Bypass of Protection Mechanisms**: Attackers can modify configuration or state files that drive security-relevant behavior, resulting in the circumvention of controls without modifying any code. +- **Execution of Unauthorized Code**: Attackers can inject malicious content into resources the app renders or interprets (e.g. scripts or templates), resulting in attacker-controlled behavior inside the app. + +## Mitigations + +- **Verify Resource Integrity**: Compare security-relevant files against a trusted expected hash, HMAC, or digital signature before use. Protect keys and reference values from modification, and treat local verification as a defense-in-depth control on compromised devices. +- **Authenticate Downloaded Content**: Verify integrity and authenticity (e.g. a signature, see @MASWE-0015) of downloaded resources before use. +- **Treat Restored Data as Untrusted**: Re-validate data that reappears via backup restore or device transfer before acting on it (see @MASWE-0048). +- **Respond to Failed Checks**: Discard or re-fetch tampered resources, restrict functionality, or alert the backend when validation fails. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0064.md b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md new file mode 100644 index 00000000..c1f9ae9d --- /dev/null +++ b/weaknesses/MASVS-RESILIENCE/MASWE-0064.md @@ -0,0 +1,41 @@ +--- +title: Runtime Code Integrity Not Verified +id: MASWE-0064 +alias: runtime-code-integrity +requirement: "The app detects unauthorized changes to its code and execution flow at runtime." +platform: [android, ios] +profiles: [R] +threat: MAS-THREAT-0064 +attacks: [MAS-ATTACK-0002, MAS-ATTACK-0003] +mappings: + masvs-v1: [MSTG-RESILIENCE-6] + masvs-v2: [MASVS-RESILIENCE-2] + maswe-beta: [MASWE-0107] +--- + +## Overview + +This weakness occurs when an app is running in an unsafe environment (rooted or jailbroken device) and does not verify the integrity of its own code at runtime, allowing in-memory patching, code injection, and hooking to go undetected. + +Even a correctly signed app can be modified while it runs: attackers can patch instructions in memory, inject libraries into the process, or hook functions to change their behavior. Runtime code integrity verification, such as checking loaded code segments, detecting injected libraries, and spotting patched function prologues, complements packaged-app integrity verification (see @MASWE-0062) by covering tampering that happens after the app has launched. + +Unlike dynamic-analysis tool detection (see @MASWE-0061), runtime integrity verification detects unauthorized changes to the app's memory and execution state without relying on tool-specific artifacts. + +## Modes of Introduction + +- **No Runtime Code Checks**: Not verifying the integrity of loaded code segments or executable memory at runtime. +- **Injected Libraries or Executable Mappings Not Detected**: Not inspecting the process for executable memory mappings or libraries that are unexpected for the app or platform. +- **Hooked Functions Not Detected**: Not checking security-critical functions for patched prologues or redirected implementations. +- **No Response to Tampering**: Detecting modifications but not reacting to protect sensitive operations. + +## Impact + +- **Bypass of Protection Mechanisms**: Attackers can patch or hook the functions implementing the app's security checks, resulting in the circumvention of its client-side defenses. +- **Compromise of Sensitive Data**: Attackers can redirect or wrap data-handling functions to siphon their inputs and outputs, resulting in exposure of credentials and user data processed by the app. + +## Mitigations + +- **Verify Code Segments at Runtime**: Periodically validate the integrity of the app's loaded code and executable memory, especially around sensitive operations. +- **Detect Injection and Hooking**: Check for foreign libraries in the process and for patched prologues or redirected implementations of security-critical functions. +- **Layer and Protect the Checks**: Implement checks in native code, diversify them, and protect them with obfuscation (see @MASWE-0051) so they cannot all be disabled with one patch. +- **Respond to Detection**: Terminate, restrict functionality, or signal the backend when runtime tampering is detected, and assess the checks against current hooking frameworks. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0067.md b/weaknesses/MASVS-RESILIENCE/MASWE-0067.md deleted file mode 100644 index 93f40c8c..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0067.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Debuggable Flag Not Disabled -id: MASWE-0067 -alias: debuggable-flag -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-2] - masvs-v2: [MASVS-RESILIENCE-4] - android-risks: - - https://developer.android.com/privacy-and-security/risks/android-debuggable - cwe: [489] - -refs: -- https://developer.android.com/guide/topics/manifest/application-element -status: new ---- - -## Overview - -Mobile apps typically include a configuration flag that determines whether the app is debuggable. While this flag is essential during development, leaving it enabled in production can introduce serious security risks. A debuggable app allows attackers to attach debuggers, inspect memory, manipulate execution flow, and bypass client-side controls, even on non-rooted or non-jailbroken devices. It may also expose sensitive information through verbose logging or developer tools that would otherwise be inaccessible. - -## Impact - -- **Read and Modify Memory**: Attackers can read and modify the app's memory space, which can lead to the exposure of sensitive information, such as encryption keys, API keys, user credentials, or tokens that otherwise would be inaccessible since they aren't present in the app's code or stored to disk. -- **Bypassing Security Controls**: Attackers can bypass security controls, such as authentication and authorization mechanisms, by manipulating the app's execution flow. -- **Execute Unauthorized Code**: Attackers can inject and execute arbitrary code within the app's context, leading to further exploitation of the device or the app's data. For example, attackers can inject reverse engineering tools like Frida into the app even on non-rooted or non-jailbroken devices. -- **Access to Sensitive Logs**: Attackers can access logs that may contain sensitive information, such as user credentials, API keys, or other sensitive data that would otherwise be inaccessible. This can lead to further exploitation of the app or the device. - -## Mode of Introduction - -- **Misconfigured Build Settings**: Misconfigured build settings can accidentally leave an app in a state that is debuggable, exposing it to security vulnerabilities. This can result from improper selection of build variants, errors in CI/CD configurations, or mistakenly applying debug settings to production environments. - -## Mitigations - -- Ensure that the debuggable flag in the app's configuration file is not enabled for production builds. For example, by using build variants or flavours to separate debug and release configurations, ensure that the debuggable flag is enabled only for debug builds. diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0089.md b/weaknesses/MASVS-RESILIENCE/MASWE-0089.md deleted file mode 100644 index bb2e1cab..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0089.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Code Obfuscation Not Implemented -id: MASWE-0089 -alias: code-obfuscation -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-9] - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective obfuscation techniques to protect against reverse engineering (CWE-693), e.g. polymorphic obfuscation, method-inlining, insertion of opaque predicates, instruction substitution, and instruction block chopping. - topics: - - polymorphic obfuscation - - method-inlining - - insertion of opaque predicates - - instruction substitution - - instruction block chopping -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0090.md b/weaknesses/MASVS-RESILIENCE/MASWE-0090.md deleted file mode 100644 index 07ab1dbf..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0090.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Resource Obfuscation Not Implemented -id: MASWE-0090 -alias: resource-obfuscation -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-11] - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [693] - -draft: - description: e.g. resource obfuscation, binary encryption/packing - topics: - - data/resource obfuscated/encrypted - - binaries encrypted/packed - - obfuscation/encryption used without integrity validation (CWE-649) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0091.md b/weaknesses/MASVS-RESILIENCE/MASWE-0091.md deleted file mode 100644 index 2159ec91..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0091.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Anti-Deobfuscation Techniques Not Implemented -id: MASWE-0091 -alias: anti-deobfuscation -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-12] - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective anti-deobfuscation techniques to protect against reverse engineering (CWE-693) - topics: - - anti-deobfuscation techniques -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0092.md b/weaknesses/MASVS-RESILIENCE/MASWE-0092.md deleted file mode 100644 index 6650d60e..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0092.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Static Analysis Tools Not Prevented -id: MASWE-0092 -alias: static-analysis-tools -platform: [android, ios] -profiles: [R] -mappings: - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [693] - -draft: - description: AKA static damage control. The app's code doesn’t implement effective techniques to prevent static analysis tools from decompiling the app (CWE-693). - topics: - - prevent decompilation -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0093.md b/weaknesses/MASVS-RESILIENCE/MASWE-0093.md deleted file mode 100644 index a40d3966..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0093.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Debugging Symbols Not Removed -id: MASWE-0093 -alias: debugging-symbols -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-CODE-3] - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [497, 540] - -draft: - description: The app contains debugging symbols, which can be exploited by attackers to understand the app's behavior (CWE-497). The app's debugging symbols are considered sensitive information (CWE-540) and should not be present in production builds. - topics: - - debugging symbols not removed -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0094.md b/weaknesses/MASVS-RESILIENCE/MASWE-0094.md deleted file mode 100644 index c383f95f..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0094.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Non-Production Resources Not Removed -id: MASWE-0094 -alias: non-production-resources -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-CODE-4] - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [497, 540, 1295] - -draft: - description: The app contains non-production resources that should not be present in production builds, such as non-production URLs, code flows, or verbose logging. These resources help adversaries understand the app's behavior and potentially exploit it (CWE-497), may include sensitive information (CWE-540) or implementation details (CWE-1295). - topics: - - non-production URLs - - code flows - - verbose logging (e.g., using logging utilities) - - enabled testing utilities (e.g., StrictMode) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0095.md b/weaknesses/MASVS-RESILIENCE/MASWE-0095.md deleted file mode 100644 index 3dabbd4c..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0095.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Code That Disables Security Controls Not Removed -id: MASWE-0095 -alias: code-disables-security -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-CODE-4] - masvs-v2: [MASVS-RESILIENCE-3] - cwe: [489, 912] - -draft: - description: The app contains leftover debugging logic or test code (CWE-489) that was not removed before release, which can disable critical protections like TLS certificate validation. It may also include hidden settings or functions that allow bypassing security controls (CWE-912), making the app vulnerable to manipulation. - topics: - - backdoors - - hidden settings to e.g. disable TLS verification -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0096.md b/weaknesses/MASVS-RESILIENCE/MASWE-0096.md deleted file mode 100644 index fe27399b..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0096.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Data Sent Unencrypted Over Encrypted Connections -id: MASWE-0096 -alias: data-unencrypted -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-13] - masvs-v2: [MASVS-RESILIENCE-3, MASVS-NETWORK-1] - cwe: [319] - -draft: - description: Use payload/End-2-End Encryption. Even if the connection is encrypted - (e.g. HTTPS), performing a MITM attack should not reveal any sensitive information - (e.g. about the inner workings of the app and its operations. This is not necessarily - related to privacy). - topics: null -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0097.md b/weaknesses/MASVS-RESILIENCE/MASWE-0097.md deleted file mode 100644 index 58b9e039..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0097.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Root/Jailbreak Detection Not Implemented -id: MASWE-0097 -alias: root-jailbreak-detection -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-1] - masvs-v2: [MASVS-RESILIENCE-1] - cwe: [693] - -draft: - description: no root/jailbreak detection implemented e.g. check for Cydia, SuperSU, - Magisk, Xposed, etc. The app does not implement effective techniques to detect if the device is rooted or jailbroken (CWE-693). - topics: - - detection in place - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0098.md b/weaknesses/MASVS-RESILIENCE/MASWE-0098.md deleted file mode 100644 index fb29e6d0..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0098.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: App Virtualization Environment Detection Not Implemented -id: MASWE-0098 -alias: app-virtualization-detection -platform: [android, ios] -profiles: [R] -mappings: - masvs-v2: [MASVS-RESILIENCE-1] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective techniques to detect if it is running in a virtualized environment (CWE-693), e.g. checking for known virtualization software or anomalies in the environment. - topics: - - detection in place for "cloned" apps or virtualized environments - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0099.md b/weaknesses/MASVS-RESILIENCE/MASWE-0099.md deleted file mode 100644 index 4d3d8ac3..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0099.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Emulator Detection Not Implemented -id: MASWE-0099 -alias: emulator-detection -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-5] - masvs-v2: [MASVS-RESILIENCE-1] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective techniques to detect if it is running in an emulator (CWE-693), e.g. identifying features and limitations available for commonly used emulation solutions - topics: - - detection in place - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0100.md b/weaknesses/MASVS-RESILIENCE/MASWE-0100.md deleted file mode 100644 index 14055f5e..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0100.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Device Attestation Not Implemented -id: MASWE-0100 -alias: device-attestation -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-10] - masvs-v2: [MASVS-RESILIENCE-1] - cwe: [693] - -refs: -- https://developer.android.com/google/play/integrity -- https://support.google.com/googleplay/android-developer/answer/11395166?hl=en -- https://www.youtube.com/watch?v=TyxL78e5Bag -- https://github.com/1nikolas/play-integrity-checker-app -- https://developer.apple.com/videos/play/wwdc2021/10244/ -- https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service -- https://github.com/iansampson/AppAttest -- https://github.com/firebase/firebase-ios-sdk/blob/v8.15.0/FirebaseAppCheck/Sources/AppAttestProvider/DCAppAttestService%2BFIRAppAttestService.h -- https://blog.restlesslabs.com/john/ios-app-attest -draft: - description: The app doesn't use App Attestation APIs, such as Google Play Integrity API, iOS DeviceCheck API,so the backend cannot ensure requests originate from a genuine app binary (CWE-693). This exposes the app to tampering, fraud, replay attacks, and unauthorized use of premium features. - topics: - - detection in place - - Effectiveness Assessment (e.g. bypassing the detection) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0101.md b/weaknesses/MASVS-RESILIENCE/MASWE-0101.md deleted file mode 100644 index f3cc129e..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0101.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Debugger Detection Not Implemented -id: MASWE-0101 -alias: debugger-detection -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-2] - masvs-v2: [MASVS-RESILIENCE-4] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective techniques to detect if it is being debugged (CWE-693), e.g. checking for debugger presence. - topics: - - debugger detection -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0102.md b/weaknesses/MASVS-RESILIENCE/MASWE-0102.md deleted file mode 100644 index d54f2349..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0102.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Dynamic Analysis Tools Detection Not Implemented -id: MASWE-0102 -alias: dynamic-analysis-tools -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-4] - masvs-v2: [MASVS-RESILIENCE-4] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective techniques to detect if it is being analyzed by dynamic analysis tools (CWE-693), e.g. Frida, Xposed, Ellekit, etc. - topics: - - Frida detection - - Xposed detection - - ElleKit detection -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0103.md b/weaknesses/MASVS-RESILIENCE/MASWE-0103.md deleted file mode 100644 index 50509c2a..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0103.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: RASP Techniques Not Implemented -id: MASWE-0103 -alias: rasp-techniques -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-8] - masvs-v2: [MASVS-RESILIENCE-4] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective RASP techniques to detect if it is running in a compromised environment (CWE-693), e.g. Runtime Application Self-Protection, detection triggering different responses. - topics: - - detection triggering different responses -status: placeholder - ---- diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0104.md b/weaknesses/MASVS-RESILIENCE/MASWE-0104.md deleted file mode 100644 index bfdba9ed..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0104.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: App Integrity Not Verified -id: MASWE-0104 -alias: app-integrity -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-CODE-1] - masvs-v2: [MASVS-RESILIENCE-2] - cwe: [347] - -refs: -- https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format -draft: - description: The app's code doesn’t implement effective techniques to verify the integrity of its own code (CWE-347), potentially relevant for apps in alternative app stores (not Google PlayStore or Apple AppStore). Also, e.g. Android V1 signing scheme only or iOS CodeDirectory v less than 20400. Also, e.g. App Signature or Binaries, native libraries including e.g. AppAttest. - topics: - - App Signature or Binaries check on runtime - - native libraries including e.g. AppAttest - - Invalid App Signing Certificate - - Latest Available Signing Scheme Not Used - Android V1 signing scheme only - - Latest Available Signing Scheme Not Used - iOS CodeDirectory v less than 20400 - - detection in place - - Effectiveness Assessment (e.g. bypassing the detection) - note: consider Static Code Modification? / Repackaging Detection Not Implemented -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0105.md b/weaknesses/MASVS-RESILIENCE/MASWE-0105.md deleted file mode 100644 index 2e0ecdd7..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0105.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Integrity of App Resources Not Verified -id: MASWE-0105 -alias: app-resources-integrity -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-3] - masvs-v2: [MASVS-RESILIENCE-2, MASVS-CODE-4] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective techniques to verify the integrity of its own resources (CWE-693). - topics: - - Sandbox Integrity - - Integrity of downloaded resources - - Integrity of dynamically loaded resources (e.g. via backup restore) -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0106.md b/weaknesses/MASVS-RESILIENCE/MASWE-0106.md deleted file mode 100644 index db5a2d71..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0106.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Official Store Verification Not Implemented -id: MASWE-0106 -alias: store-verification -platform: [android, ios] -profiles: [R] -mappings: - masvs-v2: [MASVS-RESILIENCE-2] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective techniques to verify if it is downloaded from an official store and therefore not relying on security and other assurances provided by the store (CWE-693). - topics: - - checking the app's signature or package name -status: placeholder - ---- - diff --git a/weaknesses/MASVS-RESILIENCE/MASWE-0107.md b/weaknesses/MASVS-RESILIENCE/MASWE-0107.md deleted file mode 100644 index b71fa44b..00000000 --- a/weaknesses/MASVS-RESILIENCE/MASWE-0107.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Runtime Code Integrity Not Verified -id: MASWE-0107 -alias: runtime-code-integrity -platform: [android, ios] -profiles: [R] -mappings: - masvs-v1: [MSTG-RESILIENCE-6] - masvs-v2: [MASVS-RESILIENCE-2] - cwe: [693] - -draft: - description: The app's code doesn’t implement effective techniques to verify the integrity of its own code at runtime (CWE-693). - topics: - - memory tampering detection -status: placeholder - ---- diff --git a/weaknesses/MASVS-STORAGE/MASWE-0001.md b/weaknesses/MASVS-STORAGE/MASWE-0001.md index cd3b511c..ba1861a3 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0001.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0001.md @@ -2,47 +2,44 @@ title: Insertion of Sensitive Data into Logs id: MASWE-0001 alias: data-in-logs -platform: ["android", "ios"] -profiles: ["L1", "L2", "P"] +requirement: "The app excludes sensitive data from application logs." +platform: [android, ios] +profiles: [L1, L2, P] +threat: MAS-THREAT-0001 +attacks: [MAS-ATTACK-0005, MAS-ATTACK-0006] mappings: masvs-v1: [MSTG-STORAGE-7] masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] cwe: [209, 359, 497, 532] android-risks: - - https://developer.android.com/privacy-and-security/risks/log-info-disclosure + - log-info-disclosure + android-core-app-quality: [Sensitive_Data_Logging] + maswe-beta: [MASWE-0001] refs: - - https://stackoverflow.com/questions/45270547/is-read-logs-a-normal-or-dangerous-android-permission -status: new +- log-info-disclosure +- https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code --- ## Overview -Mobile apps may write [sensitive data](../../Document/0x04b-Mobile-App-Security-Testing.md#identifying-sensitive-data "Sensitive Data") to logs. This may include sensitive user data, such as passwords, credit card numbers, or other personally identifiable information (PII), as well as sensitive system data, such as cryptographic keys, session tokens, or other sensitive information. +This weakness occurs when an app writes sensitive data to system or application logs. This may include sensitive user data, such as passwords, credit card numbers, or other personally identifiable information (PII), as well as sensitive system data, such as cryptographic keys or session tokens. -Logging all possible information is very useful at development time, especially for debugging the app. However, in production it might not always be necessary and should be prevented whenever possible to avoid any accidentally exposure to potential attackers. +Logging all possible information is very useful at development time, especially for debugging the app. However, in production it might not always be necessary and should be prevented whenever possible to avoid any accidental exposure to potential attackers. ## Modes of Introduction -This can typically occur in two ways: - -- **System Logs**: The application may log sensitive data to the system log, which can be accessed by other applications on the device (in old OS versions or compromised devices or if they hold the appropriate permissions). -- **App Logs**: The application may log sensitive data to a file in the application's data directory, which can be accessed by any application on the device if the device is rooted. +- **Sensitive Data in System Logs**: Writing sensitive data to the system log via platform logging APIs, often as leftover debugging statements. +- **Sensitive Data in App Log Files**: Writing sensitive data to custom log files in the app's data directory, e.g. via third-party logging frameworks. +- **Verbose Logging in Production**: Shipping release builds with debug or verbose log levels still enabled, so diagnostic details containing sensitive data end up in production logs. ## Impact -Loss of confidentiality: Sensitive data within logs is at risk of being exposed to an attacker with access to the device who may be able to extract it. This may lead to further attacks, such as identity theft, or compromise of the application's backend. +- **Compromise of Sensitive Data**: Attackers can read passwords, credit card numbers, or PII from log output, resulting in unauthorized disclosure of user data and enabling further attacks such as identity theft. +- **Authentication or Authorization Bypass**: Attackers can reuse leaked credentials or session tokens, resulting in unauthorized access to the user's account and the app's backend services. ## Mitigations -The following are generic recommendations to avoid logging sensitive data in production releases: - -- Avoid logging sensitive data at all. -- Redact sensitive data in logs. -- Remove logging statements unless deemed necessary to the application or explicitly identified as safe, e.g. as a result of a security audit. -- Use log levels properly to ensure that sensitive data is not logged in production releases. -- Use flags to disable logging in production releases. - -The documentation for each platform provides best practices for developers: - -- [Android mitigations to avoid log disclosure](https://developer.android.com/privacy-and-security/risks/log-info-disclosure#mitigations) -- [iOS mitigations to avoid log disclosure](https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code#3665948) +- **Avoid Logging Sensitive Data**: Do not log sensitive data at all; treat any user or system secret as unloggable by default. +- **Redact Sensitive Data**: Where log statements are needed around sensitive values, redact or mask those values before writing them. +- **Use Log Levels Properly**: Assign debug-only details to debug or verbose levels and ensure those levels are disabled in production releases. +- **Disable Logging in Production**: Use build flags or configuration to disable logging in production releases, following the platform guidance for [Android](https://developer.android.com/privacy-and-security/risks/log-info-disclosure#mitigations) and [iOS](https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code#3665948). diff --git a/weaknesses/MASVS-STORAGE/MASWE-0002.md b/weaknesses/MASVS-STORAGE/MASWE-0002.md index 9ba2363e..0de4b150 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0002.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0002.md @@ -1,30 +1,46 @@ --- -title: Sensitive Data Stored With Insufficient Access Restrictions in Internal Locations +title: Sensitive Data Not Excluded From Backup id: MASWE-0002 -alias: data-insufficient-access-restrictions-internal -platform: [android] -profiles: [L1, L2] +alias: data-not-excluded-backup +requirement: "The app excludes sensitive data from backups." +platform: [android, ios] +profiles: [L1, L2, P] +threat: MAS-THREAT-0002 +attacks: [MAS-ATTACK-0008, MAS-ATTACK-0009] mappings: - masvs-v1: [MSTG-STORAGE-2] - masvs-v2: [MASVS-STORAGE-2] - cwe: [200, 284, 732, 922] + masvs-v1: [MSTG-STORAGE-8] + masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] + cwe: [212, 313] android-risks: - - https://developer.android.com/privacy-and-security/risks/file-providers - + - backup-best-practices + maswe-beta: [MASWE-0004, MASWE-0003] refs: -- https://developer.android.com/about/versions/nougat/android-7.0-changes#permfilesys -- https://developer.android.com/privacy-and-security/security-tips#internal-storage -draft: - description: Sensitive data may be stored in internal locations without ensuring - exclusive app access (e.g. by using the wrong file permissions) and may be accessible - to other apps. - topics: - - File permissions (Android) - - improperly configured FileProvider (Android) - - Avoid the deprecated MODE_WORLD_WRITEABLE and MODE_WORLD_READABLE modes for IPC files, see https://developer.android.com/privacy-and-security/security-tips#internal-storage. They don't provide the ability to limit data access to particular applications, and they don't provide any control of data format. If you want to share your data with other app processes, consider using a content provider instead, which offers read and write permissions to other apps and can make dynamic permission grants on a case-by-case basis. - - Keychain items holding arbitrary data (excluding keys for this weakness) protected with weak protections such as kSecAttrAccessibleAlways, kSecAttrAccessibleAfterFirstUnlock, kSecAttrAccessibleWhenUnlocked (iOS) - -status: placeholder - +- https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-11 +- https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-12 +- https://developer.android.com/guide/topics/data/autobackup#define-device-conditions --- +## Overview + +This weakness occurs when an app fails to exclude sensitive data from device backups, so that user and app secrets end up in cloud or local backup archives. + +iOS and Android automatically back up app data to cloud services, users can create local backups on physical machines, and backups are also created during data transfers when switching between phones. When developers do not properly configure how their app handles backups and neglect to exclude sensitive files, the backups may contain sensitive user and app data. Under certain conditions, the backups may not be adequately secured by the cloud provider, or a malicious actor could tamper with the backed-up files. + +## Modes of Introduction + +- **Automatic System Backups**: Relying on the platform's default cloud backup behavior, which includes app data once the user consents during the initial device setup, without defining backup exclusion rules for sensitive files. +- **Local Backups**: Allowing sensitive data to be included in backups that users create on local systems (e.g., laptops), where it may be stored unencrypted. +- **Device-To-Device Transfer**: Allowing sensitive data to be included in device-to-device migrations (e.g., via iCloud or Google's migration tools) without restricting transfer conditions. +- **Sensitive Data Unencrypted in Backups**: Storing sensitive data in backed-up locations without additional encryption, so it is readable by anyone who obtains the backup. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can extract personal information, photos, documents, or audio files from backups, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can extract passwords, cryptographic keys, and session tokens from backups, resulting in identity theft, account takeover, or unauthorized access to backend services. +- **Bypass of Protection Mechanisms**: Attackers can modify backed-up app state, e.g. a database tracking premium features, or restore a pre-redemption backup to reuse one-time coupons, resulting in circumvention of business logic and revenue loss for the app owner. + +## Mitigations + +- **Exclude Sensitive Data from Backups**: Declare backup rules that exclude sensitive information, files, and key material from all backup mechanisms. +- **Encrypt Data That Must Be Backed Up**: If sensitive data has to be included in backups, encrypt it with an algorithm strong enough to protect the data for its entire required lifetime, even if the backup is later compromised. +- **Constrain Backup Conditions**: On Android, declare the appropriate [device conditions](https://developer.android.com/guide/topics/data/autobackup#define-device-conditions), such as requiring client-side encryption (`requireFlags="clientSideEncryption"`) and disabling device-to-device transfer (`deviceToDeviceTransfer`) for sensitive datasets, so that unencrypted copies are never produced. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0003.md b/weaknesses/MASVS-STORAGE/MASWE-0003.md index 1addd594..92d0c2c7 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0003.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0003.md @@ -1,25 +1,53 @@ --- -title: Backup Unencrypted +title: Sensitive Data Stored Unencrypted in Private Storage id: MASWE-0003 -alias: backup-unencrypted -platform: [android] +alias: data-unencrypted-private-storage +requirement: "The app encrypts sensitive data stored in private storage." +platform: [android, ios] profiles: [L2] +threat: MAS-THREAT-0003 +attacks: [MAS-ATTACK-0005, MAS-ATTACK-0007, MAS-ATTACK-0008] mappings: - masvs-v1: [MSTG-STORAGE-8] - masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] - cwe: [313] + masvs-v1: [MSTG-STORAGE-2] + masvs-v2: [MASVS-STORAGE-1, MASVS-STORAGE-2, MASVS-CRYPTO-2, MASVS-PRIVACY-1] + cwe: [200, 284, 312, 313, 732, 922] android-risks: - - https://developer.android.com/privacy-and-security/risks/backup-best-practices - + - file-providers + maswe-beta: [MASWE-0006, MASWE-0002, MASWE-0118] refs: -- https://developer.android.com/guide/topics/data/autobackup#define-device-conditions -draft: - description: The app may not encrypt sensitive data in backups, which may compromise - data confidentiality. - topics: - - Backup Device Conditions clientSideEncryption and deviceToDeviceTransfer Not Checked - (Android) -status: placeholder - +- https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files +- https://developer.android.com/about/versions/nougat/android-7.0-changes#permfilesys +- https://developer.android.com/privacy-and-security/security-tips#internal-storage --- +## Overview + +This weakness occurs when an app stores sensitive data unencrypted in private storage locations, such as the application sandbox, where it can be exposed via incorrect file permissions, an app or device vulnerability, or data backup mechanisms. + +Sensitive data may include personally identifiable information (PII), passwords, cryptographic keys, or session tokens. + +## Modes of Introduction + +- **Data Stored Unencrypted**: Writing sensitive data to the app's private data directory (sandbox) unencrypted. +- **Hardcoded Encryption Key**: Encrypting sensitive data with a key that is hardcoded inside the application. +- **Encryption Key Stored on Filesystem**: Encrypting sensitive data but storing the generated key alongside it or in another easily accessible location. +- **Insufficient Encryption**: Encrypting sensitive data with an algorithm or configuration that is not considered strong. +- **Insufficient Access Restrictions**: Exposing private files to other apps through incorrect file permissions (e.g. the deprecated `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE` file permission modes on Android), a misconfigured `FileProvider`, or Keychain items protected with weak accessibility attributes on iOS (e.g. `kSecAttrAccessibleAlways`). +- **Data Not Removed After Use**: Retaining sensitive data in private storage (including caches, temporary files, WebView state, and network caches) longer than needed. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can extract PII and other user data from the application sandbox, resulting in unauthorized disclosure and enabling further attacks such as identity theft. +- **Authentication or Authorization Bypass**: Attackers can extract passwords, cryptographic keys, or session tokens, resulting in account takeover or unauthorized access to protected functionality. + +## Mitigations + +- **Minimize Local Storage of Sensitive Data**: Avoid storing sensitive data locally if it is not required for app functionality, e.g. keep PII server-side, render it at time of use, and remove any cached data on logout. +- **Restrict File Access**: Use platform APIs to restrict file access as much as possible (least privilege principle). On Android, share data through a properly configured `ContentProvider`/ `FileProvider` with per-grant permissions instead of the deprecated `MODE_WORLD_READABLE`/`MODE_WORLD_WRITEABLE` file permission modes. On iOS, store Keychain items with the strictest viable accessibility attribute (e.g. `kSecAttrAccessibleWhenUnlockedThisDeviceOnly`). +- **Remove Data When No Longer Needed**: Clear sensitive data, caches, and temporary files as soon as they are no longer needed (e.g. on logout or when leaving a sensitive flow) to limit the window during which they can be exposed. +- **Use Platform Keystores**: Store cryptographic keys exclusively using the platform's hardware-backed keystore solution, such as the Android Keystore or the iOS Keychain. +- **Encrypt Data at Rest**: For other files and preferences, use platform-provided features for encrypting data at rest or techniques implementing envelope encryption with Data Encryption Keys (DEK) and Key Encryption Keys (KEK) or equivalent methods. For example, on Android, use [`EncryptedFile`](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile) or [`EncryptedSharedPreferences`](https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences); on iOS, use [iOS Data Protection](https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files). + +!!! Warning + + The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0004.md b/weaknesses/MASVS-STORAGE/MASWE-0004.md index 347ac523..0ea26fd8 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0004.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0004.md @@ -1,40 +1,54 @@ --- -title: Sensitive Data Not Excluded From Backup +title: Sensitive Data Stored Unencrypted Outside of Private Storage id: MASWE-0004 -alias: data-not-excluded-backup -platform: [android, ios] -profiles: [L1, L2, P] +alias: data-unencrypted-shared-storage-no-user-interaction +requirement: "The app encrypts sensitive data stored outside of private storage." +platform: [android] +profiles: [L1, L2] +threat: MAS-THREAT-0004 +attacks: [MAS-ATTACK-0010, MAS-ATTACK-0011] mappings: - masvs-v1: [MSTG-STORAGE-8] - masvs-v2: [MASVS-STORAGE-2, MASVS-PRIVACY-1] - cwe: [212] + masvs-v1: [MSTG-STORAGE-2] + masvs-v2: [MASVS-STORAGE-1, MASVS-STORAGE-2] + cwe: [200, 284, 312, 313, 732, 921, 922] android-risks: - - https://developer.android.com/privacy-and-security/risks/backup-best-practices - + - sensitive-data-external-storage + android-core-app-quality: [Sensitive_Data_Storage] + maswe-beta: [MASWE-0007, MASWE-0002] refs: -- https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-11 -- https://developer.android.com/guide/topics/data/autobackup#include-exclude-android-12 -status: new - +- https://developer.android.com/training/data-storage +- https://developer.android.com/privacy-and-security/security-tips#external-storage --- ## Overview -iOS and Android automatically back up app data to cloud services, and users can also create local backups on physical machines, or backups are automatically created during data transfers when switching between phones. When developers fail to properly configure how their app handles backups and neglect to exclude sensitive files, the backups may contain sensitive user and app data. Under certain conditions, the backups may not be adequately secured by the cloud provider, or a malicious actor could tamper with the backed up files, potentially altering the app's behavior or extracting confidential information. +This weakness occurs when an app stores sensitive data unencrypted in shared or external storage, where other apps can access it without any user interaction. -## Impact +On Android, apps can store data explicitly in an app-specific external storage (`getExternalFilesDir()`), use the `MediaStore`-API or Storage Access Framework (SAF) to access shared folders. The app-specific external storage can not be accessed by other apps. However, if the external storage is located on a physical SD card, it can be removed and read. If the external storage is emulated by the system, actors with access to an unlocked phone can access it using _Android Debug Bridge (ADB)_. -- **Modification of App's Behavior**: An attacker can tamper with data inside the backup, altering the app's logic. For example, they could modify a database that tracks the state of premium features and then restore the modified backup to the device. Another common scenario is backing up the device before redeeming a one-time coupon and restoring the backup afterward, which would allow the malicious actor to reuse the same coupon multiple times. -- **Loss of Confidentiality**: Sensitive data stored in backups (e.g., personal information, photos, documents or audio files) may be extracted by attackers, leading to privacy breaches. -- **Leakage of Authentication Material**: An attacker can extract passwords, cryptographic keys, and session tokens to facilitate additional attacks, such as identity theft, account takeover, or unauthorized access. +This weakness primarily concerns Android, which permits the explicit use of shared and external storage. However, while it is not possible to directly read and write an external folder on iOS, apps can use the by default pre-installed Files app or the document picker to read and write to a system-wide shared location. ## Modes of Introduction -- **Automatic System Backups**: By default, iOS and Android back up app data to the cloud once the user consents during the initial setup. -- **Local Backups**: Users can back up their devices to local systems (e.g., laptops). If local backups are stored unencrypted or not securely handled, attackers could tamper with this data. -- **Device-To-Device Transfer**: Transferring data between devices (e.g., via iCloud or Google's device-to-device migration tools) enables an attacker to perform similar attacks. +- **Data Stored Unencrypted**: Writing sensitive data to shared or external storage unencrypted. On Android, this also includes the app-specific external storage. +- **Hardcoded Encryption Key**: Encrypting sensitive data stored in external storage with a key that is hardcoded inside the application. +- **Encryption Key Stored on Filesystem**: Encrypting sensitive data stored in external storage but storing the key alongside it or in another easily accessible location. +- **Insufficient Encryption**: Encrypting sensitive data with an algorithm or configuration that is not considered strong. +- **Reuse of Encryption Key**: Sharing the encryption key between two devices owned by a single user, enabling data cloning between those devices via external storage. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can extract personal information and media such as photos, documents, and audio files, resulting in unauthorized disclosure of user data. +- **Authentication or Authorization Bypass**: Attackers can extract passwords, cryptographic keys, and session tokens, resulting in identity theft or account takeover. +- **Bypass of Protection Mechanisms**: Attackers can tamper with data used by the app, e.g. a database describing the state of premium features, resulting in circumvention of business logic and revenue loss for the app owner. ## Mitigations -- Exclude sensitive information, files, and key material from backups. -- If you have to include sensitive data in backups, ensure it is encrypted with an algorithm strong enough to protect the data for its entire required lifetime, even if the backup is later compromised. +- **Prefer Private Storage**: Store files in the [private internal storage](https://developer.android.com/training/data-storage/app-specific#internal) whenever possible. +- **Limit Platform File Sharing**: Prohibit sensitive data to be shared using the platform's storage sharing frameworks such as Storage Access Framework (SAF) on Android or document picker on iOS whenever possible. +- **Encrypt Data Before Writing**: Encrypt any sensitive data stored in shared or external storage, e.g. using [Android's `EncryptedFile` API](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile). +- **Protect Encryption Keys**: Protect any keys used for data encryption with the device's hardware-backed keystore where available, and never hardcode them inside the application. + +!!! Warning + + The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0005.md b/weaknesses/MASVS-STORAGE/MASWE-0005.md new file mode 100644 index 00000000..aa82022e --- /dev/null +++ b/weaknesses/MASVS-STORAGE/MASWE-0005.md @@ -0,0 +1,50 @@ +--- +title: Cryptographic Keys Stored Outside of Platform Keystore +id: MASWE-0005 +alias: crypto-keys-not-protected-at-rest +requirement: "The app stores cryptographic keys inside the platform-provided secure keystore." +platform: [android, ios] +profiles: [L1, L2] +threat: MAS-THREAT-0005 +attacks: [MAS-ATTACK-0001, MAS-ATTACK-0005, MAS-ATTACK-0008] +mappings: + masvs-v1: [MSTG-STORAGE-1, MSTG-CRYPTO-1] + masvs-v2: [MASVS-STORAGE-1, MASVS-CRYPTO-2] + cwe: [312, 318, 321] + android-risks: + - hardcoded-cryptographic-secrets + maswe-beta: [MASWE-0013, MASWE-0014, MASWE-0016] +refs: +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf +- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf +- https://developer.android.com/privacy-and-security/keystore#ImportingEncryptedKeys +- https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_as_data +- https://developer.android.com/privacy-and-security/keystore#StrongBoxKeyMint +--- + +## Overview + +This weakness occurs when cryptographic keys are stored outside the platform-provided secure keystore, in locations such as unencrypted preferences, unprotected files, or the application code itself. + +Cryptographic keys are essential for securing sensitive data in mobile applications. Keys that are hardcoded in the app, included in source control and shipped in the final package, or written to insecure storage locations lack the access control and hardware-backed protection that platform keystores, such as the [Android Keystore](https://developer.android.com/training/articles/keystore) and the [iOS Keychain](https://developer.apple.com/documentation/security/keychain_services), are designed to provide. + +## Modes of Introduction + +- **Insecure Storage Locations**: Storing cryptographic keys in locations that are not designed for secure storage, such as regular configuration or user preferences files, application data directories, or other areas lacking encryption and access control mechanisms. +- **Hardcoded Cryptographic Keys**: Including cryptographic keys directly in the application code or in resources shipped with the app package. +- **Insecure Key Import**: Importing keys into the keystore in plaintext instead of using secure wrapped or encrypted import, exposing the key material outside the secure environment. + +## Impact + +- **Compromise of Sensitive Data**: Attackers can decrypt protected information or forge encrypted data, resulting in unauthorized disclosure or modification of sensitive data. +- **Authentication or Authorization Bypass**: Attackers can create valid cryptographic values or impersonate trusted parties, resulting in unauthorized access to protected accounts, data, or functionality. +- **Bypass of Protection Mechanisms**: Attackers can forge licensing, entitlement, or integrity tokens signed with a compromised key to unlock restricted features or defeat client-side checks, resulting in circumvention of the protections the app enforces. +- **Financial Loss**: Attackers can abuse a compromised key that authenticates to a paid or metered backend service to run up usage on the owner's account, resulting in unexpected charges to the app owner. + +## Mitigations + +- **Use Platform Keystores**: Where possible, generate cryptographic keys dynamically on the device, rather than using predefined keys, and ensure that they are securely stored after creation. For this you can use the platform-specific keystores, such as the [Android Keystore](https://developer.android.com/training/articles/keystore) or the [iOS Keychain](https://developer.apple.com/documentation/security/keychain_services). +- **Implement Strongest Hardware Security Solutions**: For the most critical cases and whenever [available and compatible](https://developer.android.com/privacy-and-security/keystore#HardwareSecurityModule) for the use case at hand, leverage the strongest hardware-backed security options such as [Android StrongBox](https://developer.android.com/privacy-and-security/keystore#StrongBoxKeyMint) or iOS's Secure Enclave [`kSecAttrTokenIDSecureEnclave`](https://developer.apple.com/documentation/security/ksecattrtokenidsecureenclave) option to ensure the highest protection including physical and side-channel attacks. +- **Use Cryptographic Key Management Systems**: Securely retrieve keys from server-side services that provide secure storage, access control, and auditing for sensitive data. For example, AWS Secrets Manager, Azure Key Vault, or Google Cloud Secret Manager are some popular managed secrets storage solutions. The app can securely retrieve the necessary secrets at runtime through secure, authenticated API calls. +- **Encrypt and Wrap Keys**: Whenever storing keys in platform keystores is not suitable for the use case or keys need to be exported, use envelope encryption (DEK+KEK) and key wrapping techniques as specified in [NIST.SP.800-175Br1 5.3.5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf) to protect cryptographic keys before storing them. +- **Follow Standard Key Management Best Practices**: Implement proper key management practices, including key rotation and robust protection mechanisms for keys in storage as outlined in [NIST.SP.800-57pt1r5 6.2.2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), ensuring availability, integrity, confidentiality, and proper association with usage, entities, and related information. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0006.md b/weaknesses/MASVS-STORAGE/MASWE-0006.md index db84dd8b..5761555b 100644 --- a/weaknesses/MASVS-STORAGE/MASWE-0006.md +++ b/weaknesses/MASVS-STORAGE/MASWE-0006.md @@ -1,42 +1,53 @@ --- -title: Sensitive Data Stored Unencrypted in Private Storage Locations +title: Sensitive Data Hardcoded in the App Package id: MASWE-0006 -alias: data-unencrypted-private-storage +alias: data-hardcoded-app-package +requirement: "The app does not hardcode sensitive data in the application package." platform: [android, ios] -profiles: [L2] +profiles: [L1, L2] +threat: MAS-THREAT-0006 +attacks: [MAS-ATTACK-0001] mappings: - masvs-v1: [MSTG-STORAGE-2] - masvs-v2: [MASVS-STORAGE-1, MASVS-CRYPTO-2] - mastg-v1: [MASTG-TEST-0052, MASTG-TEST-0001] - cwe: [312, 313, 922] + masvs-v1: [MSTG-STORAGE-1, MSTG-CODE-2] + masvs-v2: [MASVS-STORAGE-1] + cwe: [312, 321, 540, 798] + android-risks: + - insecure-api-usage + maswe-beta: [MASWE-0005, MASWE-0013, MASWE-0036] refs: - - https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files -status: new +- https://cloud.google.com/docs/authentication/api-keys#securing +- https://cloud.google.com/docs/authentication/api-keys#api_key_restrictions +- https://github.com/gitleaks/gitleaks --- ## Overview -Mobile apps may need to store sensitive data locally within private storage locations such as the application sandbox and this data is at risk of exposure via, for example, incorrect file permissions, an app vulnerability, device vulnerability or data backup mechanisms. +This weakness occurs when sensitive data is embedded in the app package (APK/IPA) and shipped with the app, where anyone who downloads the package can recover it. -[Sensitive data](../../Document/0x04b-Mobile-App-Security-Testing.md#identifying-sensitive-data "Sensitive Data") may include personally identifiable information (PII), passwords, cryptographic keys or session tokens. +The hardcoded sensitive data may include API keys and secrets for first- or third-party services, credentials such as passwords or session tokens, and cryptographic material such as symmetric or private keys embedded directly in the package (as opposed to being generated and stored in a platform keystore, see @MASWE-0005). It also includes developer leftover artifacts, such as staging or integration URLs, developer emails and usernames, and source code files left in the package (e.g. `.swift`, `.cpp`, map files, or other build artifacts) that leak internal information. -## Impact - -- **Loss of Confidentiality**: Under the right conditions an attacker could extract sensitive data stored internally within the application sandbox leading to loss of confidentiality and enable further attacks such as identity theft or account takeover. +Note that developer _debug_ artifacts (verbose logging, backdoors, testing utilities, hidden switches) are covered separately under resilience in @MASWE-0054. The focus here is on hardcoded sensitive data that leaks confidentiality regardless of any anti-tampering considerations. ## Modes of Introduction -- **Data Stored Unencrypted**: Sensitive data is written to the app's private data directory (sandbox) unencrypted. -- **Hardcoded Encryption Key**: Sensitive data is encrypted but the key is hardcoded inside the application. -- **Encryption Key Stored on Filesystem**: Sensitive data is encrypted 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. +- **App Source Code**: Embedding secrets directly in the code that is compiled into the app. +- **App Assets and Resources**: Including secrets in configuration files, manifests, property lists, string resources, and other bundled files. +- **Libraries**: Including secrets in the configuration files or source code of first-party, third-party, or transitive dependencies. +- **Build and Developer Leftovers**: Inadvertently packaging staging/integration endpoints, developer identities, and source files with the app. -## Mitigations +## Impact -- Avoid storing sensitive data locally if not required for application functionality to reduce the likelihood and impact of this weakness. For example keeping PII server-side, rendering it at time of use, and removing any cached data on logout. -- Store cryptographic keys exclusively using the platform's hardware-backed keystore solution, such as the Android Keystore or the iOS Keychain. -- For storing other files and preferences, use platform-provided features for encrypting data at rest or other techniques implementing envelope encryption with Data Encryption Keys (DEK) and Key Encryption Keys (KEK) or equivalent methods. For example, on Android, use [`EncryptedFile`](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile) or [`EncryptedSharedPreferences`](https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences); on iOS, use [iOS Data Protection](https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files). +- **Financial Loss**: Attackers can abuse compromised API keys to make unauthorized billed API calls (e.g., AI/ML services), resulting in unexpected charges to the app owner. +- **Compromise of System Integrity and Business Operations**: Attackers can use extracted credentials to access backend services, resulting in service disruption, policy-violation suspensions, or denial of service. +- **Compromise of Sensitive Data**: Attackers can use extracted cryptographic material to decrypt protected data, resulting in unauthorized disclosure of user or app data. +- **Bypass of Protection Mechanisms**: Attackers can use hardcoded keys to unlock paid features or access restricted content, resulting in circumvention of the protections the app enforces. -!!! Warning +## Mitigations - The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available. +- **Proxy Static Secrets Through a Middleware**: If a stateful API service is not viable, front the stateless API with a middleware solution (API proxy or gateway) that proxies requests between the app and the API endpoint, keeping the static secret server-side rather than in the client. Use JSON Web Tokens (JWT) and JSON Web Signature (JWS) as appropriate. +- **Use Stateful API Services**: Prefer API services that provide secure authentication, client validation, and session controls. Implement dynamic tokens that expire after a reasonably short time (e.g., 1 hour) to reduce the impact of key exposure, and ensure proper error handling and logging to detect unauthorized access attempts. Consider OAuth 2.0 and libraries such as AppAuth to simplify secure OAuth flows. +- **Retrieve Secrets at Runtime**: Consider using a [Key Management Service](https://cloud.google.com/kms/docs/key-management-service) behind a middleware solution (API proxy or gateway) to retrieve secrets at runtime after validating device and app integrity and over a secure, pinned channel that protects the transferred secrets (see @MASWE-0027). +- **Restrict Unavoidable Hardcoded Secrets**: If secrets must be hardcoded, configure them with the minimum required permissions and restrictions to reduce the impact in case of exposure. +- **Use Platform Keystores**: Store cryptographic keys and authentication material using the platform's hardware-backed keystore (Android Keystore, iOS Keychain) instead of embedding them in the package. See @MASWE-0005. +- **Audit for Leftover Secrets**: Regularly audit the codebase and dependencies for hardcoded sensitive data and developer leftovers (e.g., using tools such as [gitleaks](https://github.com/gitleaks/gitleaks)) and strip build artifacts and source files from release packages. +- **Harden Only as a Last Resort**: When no other secure option is available, use white-box cryptography, code/resource obfuscation, and RASP to raise the effort required to extract secrets, ensuring keys are only assembled in memory when needed. These techniques deter but do not prevent extraction and must not replace the mitigations above. diff --git a/weaknesses/MASVS-STORAGE/MASWE-0007.md b/weaknesses/MASVS-STORAGE/MASWE-0007.md deleted file mode 100644 index fb362eed..00000000 --- a/weaknesses/MASVS-STORAGE/MASWE-0007.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Sensitive Data Stored Unencrypted in Shared Storage Requiring No User Interaction -id: MASWE-0007 -alias: data-unencrypted-shared-storage-no-user-interaction -platform: [android] -profiles: [L1, L2] -mappings: - masvs-v1: [MSTG-STORAGE-2] - masvs-v2: [MASVS-STORAGE-1] - mastg-v1: [MASTG-TEST-0052, MASTG-TEST-0001] - cwe: [312, 313, 921, 922] - android-risks: - - https://developer.android.com/privacy-and-security/risks/sensitive-data-external-storage -status: new ---- - -## 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](https://developer.android.com/training/data-storage/app-specific#internal) and using [Android's EncryptedFile API wrapper for file encryption](https://developer.android.com/reference/androidx/security/crypto/EncryptedFile). - -!!! Warning - - The **Jetpack security crypto library**, including the `EncryptedFile` and `EncryptedSharedPreferences` classes, has been [deprecated](https://developer.android.com/privacy-and-security/cryptography#jetpack_security_crypto_library). However, since an official replacement has not yet been released, we recommend using these classes until one is available.