diff --git a/demos/android/MASVS-CODE/MASTG-DEMO-0102/MASTG-DEMO-0102.md b/demos/android/MASVS-CODE/MASTG-DEMO-0102/MASTG-DEMO-0102.md index b7fc3afcd25..c54589a46d8 100644 --- a/demos/android/MASVS-CODE/MASTG-DEMO-0102/MASTG-DEMO-0102.md +++ b/demos/android/MASVS-CODE/MASTG-DEMO-0102/MASTG-DEMO-0102.md @@ -57,3 +57,43 @@ Cursor cursor = qb.query(db, projection, selection, selectionArgs, null, null, s ``` These two code paths create separate SQL injection vectors. + +### Exploitation + +You can use @MASTG-TECH-0148 to interact with the `ContentProvider` and confirm the injection vulnerabilities. + +**Selection-based SQL Injection:** + +An attacker can inject SQL through the `--where` argument of the `content` command: + +```bash +adb shell 'content query --uri content://org.owasp.mastestapp.provider/students --where "name='\''Bob'\'' OR '\''1'\''='\''1'\''"' +``` + +Output: + +```text +Row: 0 id=1, name=Alice +Row: 1 id=2, name=Bob +Row: 2 id=3, name=Charlie +``` + +**Path-based SQL Injection:** + +An attacker can inject SQL through the URI path using the `students/filter/*` route: + +```bash +adb shell 'content query --uri "content://org.owasp.mastestapp.provider/students/filter/id%3D2%20OR%201%3D1"' +``` + +Output: + +```text +Row: 0 id=1, name=Alice +Row: 1 id=2, name=Bob +Row: 2 id=3, name=Charlie +``` + +The `students/#` route is limited to numeric input by `UriMatcher` and isn't practically exploitable, but it's still flagged because it demonstrates unsafe concatenation of user-controlled data into a SQL query. + +Both vulnerabilities arise from directly incorporating untrusted input into SQL statements instead of using parameterized queries or proper input validation. diff --git a/demos/android/MASVS-PLATFORM/MASTG-DEMO-0122/MASTG-DEMO-0122.md b/demos/android/MASVS-PLATFORM/MASTG-DEMO-0122/MASTG-DEMO-0122.md index da4e5a25f18..ee35ab25c2a 100644 --- a/demos/android/MASVS-PLATFORM/MASTG-DEMO-0122/MASTG-DEMO-0122.md +++ b/demos/android/MASVS-PLATFORM/MASTG-DEMO-0122/MASTG-DEMO-0122.md @@ -40,3 +40,45 @@ The rule flags the `files-path` element in `filepaths.xml`: Additionally, `ShareReportActivity` is declared with `android:exported="true"` in the AndroidManifest, meaning any external app can send it a crafted intent with an arbitrary `file_name` extra and receive back a valid `content://` URI. > This attack cannot be reproduced with `adb` alone. `adb shell am start` can launch the exported activity, but it never receives the returned result intent or the temporary URI permission grant, so it can't read the file — and reading it via `su -c 'content read …'` only works because root can read any app's storage directly, which bypasses the provider rather than exploiting it. Demonstrating the real vulnerability therefore requires a separate attacker app that calls the activity with `startActivityForResult()` and reads the granted `content://` URI. + +### Exploitation + +@MASTG-DEMO-0123 demonstrates the full exploit as a self-contained attacker app. Install the attacker APK, tap **Start**, and it sends a crafted intent to `ShareReportActivity` requesting `session_token.txt`. The exfiltrated token appears in a dialog and in logcat: + +```bash +adb logcat -s EXFIL +--------- beginning of main +06-05 08:17:34.993 12771 12771 E EXFIL : Exfiltrated from victim: sess_7f3a9b1e4d2c8f0a5e6b3c1d9f4a2e7b +``` + +## Fix + +There are two independent fixes, which can be combined for defense-in-depth. + +**Option 1: Restrict the `FileProvider` path scope (recommended)** + +In filepaths.xml, replace `path="."` with the specific subdirectory the app intends to share: + +```xml + +``` + +After this change, any call to `FileProvider.getUriForFile()` with a path outside `reports/` throws an error. You can confirm by re-running the attacker app from @MASTG-DEMO-0123, the app will not show the session token anymore. + +Run `adb logcat | grep -A20 "Failed to find configured root"` to validate it: + +```bash +Caused by: java.lang.IllegalArgumentException: Failed to find configured root that contains /data/data/org.owasp.mastestapp/files/session_token.txt +``` + +**Option 2: Restrict or remove the export of `ShareReportActivity`** + +If `ShareReportActivity` doesn't need to be reachable by arbitrary third-party apps, set `android:exported="false"` or remove the activity completely from the Android Manifest: + +```xml + +``` + +This prevents any external app from sending a crafted intent. diff --git a/demos/android/MASVS-PLATFORM/MASTG-DEMO-0128/MASTG-DEMO-0128.md b/demos/android/MASVS-PLATFORM/MASTG-DEMO-0128/MASTG-DEMO-0128.md index 3a01f884dda..ab755e787ef 100644 --- a/demos/android/MASVS-PLATFORM/MASTG-DEMO-0128/MASTG-DEMO-0128.md +++ b/demos/android/MASVS-PLATFORM/MASTG-DEMO-0128/MASTG-DEMO-0128.md @@ -52,3 +52,80 @@ The output also lists other exported activities. These are triaged but not repor `androidx.activity.ComponentActivity` is commonly added by the Compose UI test manifest as a generic host activity for Compose tests. This is expected in debug or test builds, but should be reviewed if it appears in a production build. `androidx.compose.ui.tooling.PreviewActivity` is a Compose tooling activity used by Android Studio to run composable previews. It is not part of the app's authentication flow and should normally be treated as development tooling unless the tested build is intended for production. + +### Confirm the Exposure + +You can use @MASTG-TECH-0160 to start `SecretActivity` directly and confirm that the sensitive screen is reachable without entering the PIN: + +```bash +adb shell am start -n 'org.owasp.mastestapp/org.owasp.mastestapp.MastgTest\$SecretActivity' +``` + +The secret screen appears without any PIN prompt, confirming the authentication bypass. + +An external app can start `SecretActivity` directly, but that does not automatically let the external app read the activity's UI contents or obtain the displayed data programmatically. Android does not normally return another activity's screen text to the caller. + +The security issue is that the protected screen becomes reachable without completing the PIN challenge. This can still expose sensitive data to anyone using the device, to screen capture or accessibility based threats, or to any flow where the attacker can trick the user into opening the activity. If the activity also returns data through results, sends broadcasts, writes files, accepts attacker controlled extras, or performs account actions on launch, the impact could be higher. + +In this sample, the finding is an authentication bypass because `SecretActivity` displays sensitive account data without verifying that the user completed the PIN challenge. The direct launch proves unauthorized access to the protected screen, even though the calling app does not automatically read the displayed data. + +## Fix + +There are two ways to fix this, and the right choice depends on whether `SecretActivity` needs to be reachable by external apps at all. + +**Option 1: Set `android:exported="false"` (recommended for most apps)** + +If `SecretActivity` has no legitimate reason to be started by another app, simply prevent external apps from reaching it: + +```xml + +``` + +Trying to start `SecretActivity` again with `adb` after this change will fail with an error, confirming that the activity is no longer reachable from outside the app: + +```bash +adb shell am start -n 'org.owasp.mastestapp/org.owasp.mastestapp.MastgTest\$SecretActivity' +Starting: Intent { cmp=org.owasp.mastestapp/.MastgTest$SecretActivity } + +Exception occurred while executing 'start': +java.lang.SecurityException: Permission Denial: starting Intent { flg=0x10000000 xflg=0x4 cmp=org.owasp.mastestapp/.MastgTest$SecretActivity } from null (pid=29738, uid=2000) not exported from uid 10225 +``` + +This is the right choice for the vast majority of activities that display sensitive data or are part of an internal authentication flow. Android 12 and later require you to explicitly set `android:exported` on any activity with an ``; setting it to `false` on activities that don't need it is the minimal, correct fix. + +**Option 2: Keep `android:exported="true"` but enforce a `android:permission`** + +If the activity must be reachable by a trusted partner app (for example, a companion widget or a deep-link handler used by a first-party browser), you can keep it exported but gate access with a custom signature-level permission: + +```xml + + + + + +``` + +With `protectionLevel="signature"`, only apps signed with the same certificate are granted the permission automatically. A real-world example is a banking app that exposes a payment-confirmation activity to its own companion wearable app. Both are signed with the bank's certificate, so only the wearable can start the activity, while any third-party app is rejected by the OS before `onCreate` is even called. + +This permission-based fix only resolves the finding if the permission cannot be obtained by untrusted apps. If the activity were protected by a broadly grantable permission, such as a custom permission with `normal` or `dangerous` protection level, the demo would still fail because untrusted apps could still obtain the permission and start the activity. See @MASTG-KNOW-0017 for Android permission protection levels. + +Trying to start `SecretActivity` again with `adb` after this change will fail with a different error, confirming that the activity is still exported but now requires a permission that the calling app does not have: + +```bash +adb shell am start -n 'org.owasp.mastestapp/org.owasp.mastestapp.MastgTest\$SecretActivity' +Starting: Intent { cmp=org.owasp.mastestapp/.MastgTest$SecretActivity } + +Exception occurred while executing 'start': +java.lang.SecurityException: Permission Denial: starting Intent { flg=0x10000000 xflg=0x4 cmp=org.owasp.mastestapp/.MastgTest$SecretActivity } from null (pid=29880, uid=2000) requires org.owasp.mastestapp.ACCESS_SECRET +``` + +**Why not rely solely on the PIN check in the calling activity?:** + +Enforcing authentication only in `PinEntryActivity` and trusting that `SecretActivity` is always reached through it is a broken client-side control. Android's activity model makes no such guarantee: any exported activity can be started directly. Authentication state must be checked inside the activity that performs the sensitive operation, or the activity must not be exported. diff --git a/demos/android/MASVS-PLATFORM/MASTG-DEMO-0129/MASTG-DEMO-0129.md b/demos/android/MASVS-PLATFORM/MASTG-DEMO-0129/MASTG-DEMO-0129.md index 5c0e18a53a0..5c3f0f98e26 100644 --- a/demos/android/MASVS-PLATFORM/MASTG-DEMO-0129/MASTG-DEMO-0129.md +++ b/demos/android/MASVS-PLATFORM/MASTG-DEMO-0129/MASTG-DEMO-0129.md @@ -46,3 +46,69 @@ override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { ``` `VaultActivity` does not protect the underlying exported service. Access control must be enforced at the `AuthService` boundary. + +### Confirm the Exposure + +Use @MASTG-TECH-0161 with `adb` to start `AuthService` directly and pass a new password as an intent extra: + +1. Tap **Start** and note the current password shown in `VaultActivity` (`originalPass123`). +2. Start the exported service with a new password: + + ```bash + adb shell am startservice -n 'org.owasp.mastestapp/org.owasp.mastestapp.MastgTest\$AuthService' --es org.owasp.mastestapp.PASSWORD hacked123 + + Starting service: Intent { cmp=org.owasp.mastestapp/.MastgTest$AuthService (has extras) } + ``` + +3. Return to the app and tap **Refresh**. The vault password now shows `hacked123`, confirming that an external caller changed it through the exported service. + +## Fix + +There are two ways to fix this, and the right choice depends on whether `AuthService` needs to accept commands from external apps at all. + +**Option 1: Set `android:exported="false"` (recommended for most apps)** + +If `AuthService` has no legitimate reason to be started by another app, prevent external apps from reaching it: + +```xml + +``` + +Trying to start `AuthService` again with `adb` after this change will fail with an error, confirming that the service is no longer reachable from outside the app: + +```bash +adb shell am startservice -n 'org.owasp.mastestapp/org.owasp.mastestapp.MastgTest\$AuthService' --es org.owasp.mastestapp.PASSWORD hacked123 +Starting service: Intent { cmp=org.owasp.mastestapp/.MastgTest$AuthService (has extras) } +Error: Requires permission not exported from uid 10225 +``` + +This is the right choice for the vast majority of services that manage internal state, such as credentials, session tokens, or sync state, that no external app should be able to influence. The OS will reject external `startService` and `bindService` calls before they reach the service entry points. + +**Option 2: Keep `android:exported="true"` but enforce a `android:permission`** + +If the service must be reachable by a trusted partner app (for example, a separate authenticator app from the same developer), you can keep it exported but gate access with a custom signature-level permission: + +```xml + + + +``` + +With `protectionLevel="signature"`, only apps signed with the same certificate are granted the permission automatically. A real-world example is an enterprise MDM agent that exposes a configuration service to a companion management app. Both are signed with the enterprise certificate, so only the management app can send commands, while any third-party app is rejected by the OS before `onStartCommand` is called. + +This permission-based fix only resolves the finding if the permission cannot be obtained by untrusted apps. If the service were protected by a broadly grantable permission, such as a custom permission with `normal` or `dangerous` protection level, the demo would still fail because untrusted apps could still obtain the permission and start or bind to the service. See @MASTG-KNOW-0017 for Android permission protection levels. + +Trying to start `AuthService` again with `adb` after this change will fail with a different error, confirming that the service is still exported but now requires a permission that the calling app does not have: + +```bash +adb shell am startservice -n 'org.owasp.mastestapp/org.owasp.mastestapp.MastgTest\$AuthService' --es org.owasp.mastestapp.PASSWORD hacked123 +Starting service: Intent { cmp=org.owasp.mastestapp/.MastgTest$AuthService (has extras) } +Error: Requires permission org.owasp.mastestapp.USE_AUTH_SERVICE +``` diff --git a/demos/android/MASVS-PLATFORM/MASTG-DEMO-0130/MASTG-DEMO-0130.md b/demos/android/MASVS-PLATFORM/MASTG-DEMO-0130/MASTG-DEMO-0130.md index 443f3f379b8..24463b19446 100644 --- a/demos/android/MASVS-PLATFORM/MASTG-DEMO-0130/MASTG-DEMO-0130.md +++ b/demos/android/MASVS-PLATFORM/MASTG-DEMO-0130/MASTG-DEMO-0130.md @@ -47,3 +47,88 @@ override fun onReceive(context: Context, intent: Intent) { `VaultActivity` does not protect the underlying exported broadcast receiver. Access control must be enforced at the `PasswordResetReceiver` boundary. The output also lists `androidx.profileinstaller.ProfileInstallReceiver`. This receiver is added by the AndroidX Profile Installer library and, although exported, is protected by `android:permission="android.permission.DUMP"`, a signature/privileged permission that ordinary apps can't hold. It is development tooling and is not reported as vulnerable in this test case. + +### Confirm the Exposure + +You can use @MASTG-TECH-0162 with @MASTG-TOOL-0004 to deliver the broadcast and trigger the action. + +1. Tap **Start** and note the current password shown in `VaultActivity` (`originalPass123`). +2. Send the broadcast, targeting the receiver explicitly so it's delivered on modern Android: + + ```bash + adb shell am broadcast -a org.owasp.mastestapp.RESET_PASSWORD -n 'org.owasp.mastestapp/org.owasp.mastestapp.MastgTest\$PasswordResetReceiver' --es newpass hacked123 + + Broadcasting: Intent { act=org.owasp.mastestapp.RESET_PASSWORD flg=0x400000 cmp=org.owasp.mastestapp/.MastgTest$PasswordResetReceiver (has extras) } + Broadcast completed: result=0 + ``` + +3. Return to the app and tap **Refresh**. The vault password now shows `hacked123`, confirming that an external caller changed it through the exported receiver. + +The disclosed old password is also visible in the log: + +```bash +adb logcat -s MASTG-DEMO +``` + +Output: + +```bash +06-01 09:26:01.334 30881 30881 D MASTG-DEMO: Password changed from originalPass123 to hacked123 +``` + +## Fix + +There are two ways to fix this, and the right choice depends on whether `PasswordResetReceiver` needs to accept broadcasts from external apps at all. + +**Option 1: Set `android:exported="false"` (recommended for most apps)** + +If `PasswordResetReceiver` has no legitimate reason to receive broadcasts from another app, prevent external apps from reaching it: + +```xml + +``` + +Trying to send the broadcast again with `adb` after this change will not necessarily produce an error, but the password will not change and the log will not show the old password, confirming that the receiver is no longer reachable from outside the app. + +```bash +adb shell am broadcast -a org.owasp.mastestapp.RESET_PASSWORD -n 'org.owasp.mastestapp/org.owasp.mastestapp.MastgTest\$PasswordResetReceiver' --es newpass hacked123 +Broadcasting: Intent { act=org.owasp.mastestapp.RESET_PASSWORD flg=0x400000 cmp=org.owasp.mastestapp/.MastgTest$PasswordResetReceiver (has extras) } +Broadcast completed: result=0 +``` + +This is the right choice for the vast majority of receivers that react to internal app events, such as credential-reset or state-change broadcasts, that no external app should be able to influence. + +**Option 2: Keep `android:exported="true"` but enforce a `android:permission`** + +If the receiver must be reachable by a trusted partner app (for example, a companion lock-screen app from the same developer that can trigger a remote wipe or credential reset), you can keep it exported but gate access with a custom signature-level permission: + +```xml + + + + + +``` + +With `protectionLevel="signature"`, only apps signed with the same certificate are granted the permission automatically. A real-world example is an enterprise remote-wipe receiver that only responds to broadcasts from the company's own device management app. Both are signed with the enterprise certificate, so only the management app can send broadcasts, while any third-party app is rejected by the OS before `onReceive` is called. + +This permission-based fix only resolves the finding if the permission cannot be obtained by untrusted apps. If the receiver were protected by a broadly grantable permission, such as a custom permission with `normal` or `dangerous` protection level, the demo would still fail because untrusted apps could still obtain the permission and send broadcasts to the receiver. See @MASTG-KNOW-0017 for Android permission protection levels. + +Trying to send the broadcast again with `adb` after this change will not necessarily produce an error, but it won't have any effect: + +```bash +adb shell am broadcast -a org.owasp.mastestapp.RESET_PASSWORD -n 'org.owasp.mastestapp/org.owasp.mastestapp.MastgTest\$PasswordResetReceiver' --es newpass hacked123 +Broadcasting: Intent { act=org.owasp.mastestapp.RESET_PASSWORD flg=0x400000 cmp=org.owasp.mastestapp/.MastgTest$PasswordResetReceiver (has extras) } +Broadcast completed: result=0 +``` + +**Additional fix - Remove sensitive data from logs:** + +Regardless of whether the receiver itself is protected, no credentials must be written to the app logs, which are readable by any app that holds `READ_LOGS` (granted to shell and ADB). diff --git a/demos/ios/MASVS-RESILIENCE/MASTG-DEMO-0x01/MASTG-DEMO-0x01.md b/demos/ios/MASVS-RESILIENCE/MASTG-DEMO-0x01/MASTG-DEMO-0x01.md new file mode 100644 index 00000000000..8cf597d0243 --- /dev/null +++ b/demos/ios/MASVS-RESILIENCE/MASTG-DEMO-0x01/MASTG-DEMO-0x01.md @@ -0,0 +1,46 @@ +--- +platform: ios +title: Running Security-Sensitive Code Without Source Code Integrity Checks +code: [swift] +id: MASTG-DEMO-0x01 +test: MASTG-TEST-0x01 +kind: fail +--- + + + +### Exploitation + +You can confirm the missing integrity check by patching the security-sensitive routine and observing that the app still runs: + +1. Use @MASTG-TECH-0065 to locate the `isLicenseValid` comparison in the disassembly. +2. Use @MASTG-TECH-0147 to patch the binary so the check always grants access (for example, force the comparison to return `true`). +3. Use @MASTG-TECH-0092 to re-sign and repackage the patched app, then reinstall it. +4. Launch the app with any key and observe that it grants premium access. The app never detected the patch because it has no source code integrity check. + +## Fix + +Implement a runtime source code integrity check that detects binary patching. See @MASTG-BEST-0x01 for full guidance. + +**Option 1: Hash the `__TEXT/__text` section at runtime and compare it to a reference value (recommended)** + +Resolve the loaded image with `dladdr`, locate the `__TEXT/__text` section (for example with `getsectiondata`, which applies the ASLR slide), compute a SHA-256 hash over it, and compare the result against a reference value embedded in the app. If the values differ, the binary has been modified: + +```swift +import CommonCrypto +import MachO + +var info = Dl_info() +dladdr(#dsohandle, &info) +let header = info.dli_fbase!.assumingMemoryBound(to: mach_header_64.self) +var size: UInt = 0 +let text = getsectiondata(header, "__TEXT", "__text", &size)! +var digest = [UInt8](repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH)) +CC_SHA256(text, CC_LONG(size), &digest) +// Compare `digest` against a securely stored reference hash and react if they differ. +``` + +Store the reference hash where it is hard to locate and modify (for example, obfuscated in the binary or derived at build time), so an attacker cannot simply patch it alongside the code. + +**Why this is only a cost-raising measure:** a determined attacker on a jailbroken device can still patch the check itself or the stored reference hash, or hook the comparison with @MASTG-TECH-0095. Combine it with other resilience controls rather than relying on it alone. \ No newline at end of file diff --git a/demos/ios/MASVS-RESILIENCE/MASTG-DEMO-0x02/MASTG-DEMO-0x02.md b/demos/ios/MASVS-RESILIENCE/MASTG-DEMO-0x02/MASTG-DEMO-0x02.md new file mode 100644 index 00000000000..3208203416c --- /dev/null +++ b/demos/ios/MASVS-RESILIENCE/MASTG-DEMO-0x02/MASTG-DEMO-0x02.md @@ -0,0 +1,59 @@ +--- +platform: ios +title: Storing Data Without File Storage Integrity Checks +code: [swift] +id: MASTG-DEMO-0x02 +test: MASTG-TEST-0x02 +kind: fail +--- + + + +### Exploitation + +You can confirm the missing integrity check at runtime by tampering with the stored file: + +1. Use @MASTG-TECH-0056 to install the app and tap **Start** so it writes `user_profile.json` and prints its path. +2. Use @MASTG-TECH-0059 to access the app's Documents directory and modify the stored file, for example to grant premium access: + + ```sh + echo '{"username":"alice","role":"admin","premium":true}' > /var/mobile/Containers/Data/Application//Documents/user_profile.json + ``` + +3. Tap **Start** again and observe that the app reads back and trusts the modified values without any verification failure. + +## Fix + +Protect stored data by computing a cryptographic authentication tag over it and verifying that tag before use. See @MASTG-BEST-0x01 for full guidance. + +**Option 1: compute and verify an `HMAC` with a Keychain-bound key (recommended)** + +Store an HMAC alongside the data and verify it on read. Keep the HMAC key in the [Keychain](https://developer.apple.com/documentation/security/keychain-services) with a strict accessibility class (for example, `kSecAttrAccessibleWhenUnlockedThisDeviceOnly`) so it cannot be extracted from a backup or transferred to another device: + +```swift +import CryptoKit + +// On write: append an HMAC computed with a Keychain-held key +let mac = HMAC.authenticationCode(for: sensitiveData, using: key) +try (sensitiveData + Data(mac)).write(to: fileURL) + +// On read: recompute and compare before trusting the data +let stored = try Data(contentsOf: fileURL) +let payload = stored.prefix(stored.count - SHA256.byteCount) +let tag = stored.suffix(SHA256.byteCount) +guard HMAC.isValidAuthenticationCode(tag, authenticating: payload, using: key) else { + // Reject the tampered data + return +} +``` + +After applying this fix, modifying the file on disk makes verification fail, so the app rejects the tampered data. For Objective-C or mixed codebases, `CCHmac` from CommonCrypto provides the same capability. + +**Option 2: Use a digital signature with `SecKeyCreateSignature` for asymmetric scenarios** + +When the signer and verifier are different parties (for example, server-signed resources delivered to the app), sign the data with a private key and verify it in the app with [`SecKeyVerifySignature`](https://developer.apple.com/documentation/security/seckeyverifysignature(_:_:_:_:_:)) using the embedded public key. + +**Why file-system protection alone is not enough:** + +iOS [Data Protection](https://support.apple.com/guide/security/data-protection-overview-secf6276da8a/web) encrypts files at rest, but it protects confidentiality, not integrity, and provides no protection on a jailbroken device where an attacker can read and rewrite the app's container. Only an authentication tag that the app verifies lets it detect tampering. \ No newline at end of file diff --git a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0250.md b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0250.md index c8cde57a228..ecb5253adf5 100644 --- a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0250.md +++ b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0250.md @@ -22,6 +22,14 @@ The JavaScript code would have access to any content providers on the device, su Refer to @MASTG-KNOW-0018 for more information on the `setAllowContentAccess` method, the specific files that can be accessed, and the conditions under which they can be accessed. +**Example Attack Scenario:** + +Suppose a banking app uses a WebView to display dynamic content. The developers have not explicitly set the `setAllowContentAccess` method, so it defaults to `true`. Additionally, JavaScript is enabled in the WebView, and the `setAllowUniversalAccessFromFileURLs` method is also used. + +1. An attacker exploits a vulnerability (such as an XSS flaw) to inject malicious JavaScript into the WebView. This could occur through a compromised or malicious link that the WebView loads without proper validation. +2. Thanks to `setAllowUniversalAccessFromFileURLs(true)`, the malicious JavaScript can issue requests to `content://` URIs to read locally stored files or data exposed by content providers. Even those content providers in the app that are not exported can be accessed because the malicious code runs in the same process and origin as the trusted code. +3. The attacker-controlled script exfiltrates sensitive data from the device to an external server. + **Note 1:** We do not consider `minSdkVersion` since `setAllowContentAccess` defaults to `true` regardless of the Android version. **Note 2:** The provider's `android:grantUriPermissions` attribute is irrelevant in this scenario as it does not affect the app itself accessing its own content providers. It allows **other apps** to temporarily access URIs from the provider even though restrictions such as `permission` attributes, or `android:exported="false"` are set. Also, if the app uses a `FileProvider`, the `android:grantUriPermissions` attribute must be set to `true` by [definition](https://developer.android.com/reference/androidx/core/content/FileProvider#:~:text=Set%20the%20android:grantUriPermissions%20attribute%20to%20true%2C%20to%20allow%20you%20to%20grant%20temporary%20access%20to%20files.%20) (otherwise you'll get a `SecurityException: Provider must grant uri permissions"`). diff --git a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0252.md b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0252.md index d00abd02478..3a60c3284ab 100644 --- a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0252.md +++ b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0252.md @@ -25,6 +25,15 @@ Even though these methods have secure defaults and are **deprecated in Android 1 Refer to [Android WebView Local File Access Settings](../../../Document/0x05h-Testing-Platform-Interaction.md#webview-local-file-access-settings) for more information on these methods (default values, deprecation status, security implications), the specific files that can be accessed, and the conditions under which they can be accessed. +**Example Attack Scenario**: + +Suppose a banking app uses a WebView to display dynamic content, and the developers have enabled all three insecure settings. Additionally, JavaScript is enabled in the WebView. + +1. An attacker injects a malicious HTML file into the device (via phishing or another exploit) into a location that the attacker _knows_ the WebView will access it from (e.g. thanks to reverse engineering). For example, an HTML file is used to display the app's terms and conditions. +2. The WebView can load the malicious file because of `setAllowFileAccess(true)`. +3. Thanks to `setJavaScriptEnabled(true)` and `setAllowFileAccessFromFileURLs(true)`, the JavaScript in the malicious file (running in a `file://` context) is able to access other local files using `file://` URLs. +4. The attacker-controlled script exfiltrates sensitive data from the device to an external server. + **Note 1**: Either `setAllowFileAccessFromFileURLs` or `setAllowUniversalAccessFromFileURLs` must be set to `true` for the attack to work. If both settings are set to `false`, the following error will appear in `logcat`: ```bash diff --git a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0355.md b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0355.md index 6d623791e69..214a60d78fe 100644 --- a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0355.md +++ b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0355.md @@ -15,6 +15,14 @@ This test checks whether the app exposes content providers that can be accessed The same applies when no protection level is configured and becomes automatically `android:protectionLevel="normal"`, which is granting access automatically to any requesting app. +**Example Attack Scenario:** + +Suppose a health app exposes a content provider backed by a database of medical records, and the `` element in the AndroidManifest declares no `android:readPermission`. + +1. An attacker reverse engineers the app and finds an exported `` element in the AndroidManifest with no permission restrictions. +2. The manifest shows the provider's authority and no declared read or write permission. +3. Because no permission guards the provider, any app on the device can call `ContentResolver.query()` against it and retrieve the underlying data without any user interaction. + ## Steps 1. Use @MASTG-TECH-0013 to reverse engineer the app. diff --git a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0356.md b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0356.md index a43db855f8a..09f05a441fa 100644 --- a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0356.md +++ b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0356.md @@ -13,6 +13,17 @@ knowledge: [MASTG-KNOW-0020, MASTG-KNOW-0117] If an app exports a content provider without requiring permissions, any app on the device can directly query its underlying database using [`ContentResolver`](https://developer.android.com/reference/android/content/ContentResolver) or using the `adb shell content` command. Even when a permission is declared, a misconfigured protection level (for example, `android:protectionLevel="normal"`) allows any requesting app to obtain it automatically, effectively bypassing the restriction. This test verifies at runtime whether the app's exported content providers are accessible without the required permissions. +**Example Attack Scenario:** + +Suppose a health app stores medical records in a database exposed through an exported content provider with no declared `android:readPermission` and protection level. + +1. An attacker identifies the exported provider's authority from the AndroidManifest. +2. The attacker uses `adb shell content query` to query the provider's URI without any restrictions. +3. The content provider returns all database rows without checking the caller's identity. +4. The attacker reads PII or medical information directly from the app. +5. With this knowledge the attacker crafts a malicious app by using `ContentResolver` and trying to lure potential victims into side-loading the app on their device. +6. When a victim is installing the malicious app it will query for the data and sent it to the attackers server. + ## Steps 1. Use @MASTG-TECH-0005 to install the app. diff --git a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0357.md b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0357.md index 71e2b4d166d..c6bc36d4a7e 100644 --- a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0357.md +++ b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0357.md @@ -13,6 +13,16 @@ knowledge: [MASTG-KNOW-0020, MASTG-KNOW-0117] If the app exports an Android content provider without enforcing access restrictions, external callers may open private files through `content://` URIs. This test checks whether exported providers expose sensitive stored data to callers that don't hold the required permissions. +**Example Attack Scenario:** + +Suppose an app exports a `FileProvider` with a `files-path` element using `path="."`, exposing the entire internal `filesDir`. + +1. An attacker reverse engineers the app and finds the exported `FileProvider` authority and a `files-path` entry with `path="."`, which maps the entire internal filesDir into the provider's shareable root. +2. The attacker identifies an exported component in the victim app (e.g. an Activity or Service) that accepts a filename or path from the caller and uses it to build a URI via `FileProvider.getUriForFile(context, authority, new File(filesDir, attackerInput))`. +3. The attacker crafts a malicious app that invokes that component with a traversal payload such as `../databases/auth.db`, causing the victim app to construct a `content://` URI pointing outside the intended shared subdirectory and return it with `FLAG_GRANT_READ_URI_PERMISSION`. +4. The malicious app calls `ContentResolver.openInputStream()` on the returned `content://` URI to access any file under `filesDir`, including sensitive files such as tokens or private databases. +5. The `FileProvider` serves the file without restricting which paths are accessible, exposing data beyond the intended shared directory. + ## Steps 1. Use @MASTG-TECH-0013 to reverse engineer the app. diff --git a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0364.md b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0364.md index a6ed8a6aa46..c7ac8a73ec7 100644 --- a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0364.md +++ b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0364.md @@ -15,6 +15,15 @@ If an exported activity does not define [`android:permission`](https://developer This test checks whether the app exposes sensitive functionality through exported and unprotected activities. +**Example Attack Scenario:** + +Suppose a banking app protects its account screen behind a login activity but also declares an unprotected account-details activity that is exported, for example by setting `android:exported="true"` and without any limiting `android:permission`. + +1. An attacker reverse engineers the app and finds the exported account-details activity (see @MASTG-TECH-0160). +2. The attacker writes a malicious app that calls `startActivity` with an explicit intent targeting that activity by its component name. +3. The account-details activity starts directly, without going through the login activity. +4. The account-details activity displays the victim's account data without requiring authentication. + ## Steps 1. Use @MASTG-TECH-0013 to reverse engineer the app. diff --git a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0365.md b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0365.md index 5b945c9cbbf..19f5ee200e2 100644 --- a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0365.md +++ b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0365.md @@ -15,6 +15,15 @@ If an exported service does not define [`android:permission`](https://developer. This test checks whether the app exposes sensitive functionality through exported and unprotected services. +**Example Attack Scenario:** + +Suppose a password-manager app uses a bound service with a `Messenger` interface to change the master password, and the service is exported with no `android:permission`. + +1. An attacker reverse engineers the app and identifies the exported service and the message format it expects (see @MASTG-TECH-0161). +2. The attacker writes a malicious app that binds to the service and sends a message that sets a new master password. +3. The service processes the request without verifying the caller, so it resets the password. +4. The attacker now controls the victim's master password and can unlock the password vault. + ## Steps 1. Use @MASTG-TECH-0013 to reverse engineer the app. diff --git a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0366.md b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0366.md index 3af5177e6f1..a58a34afbe8 100644 --- a/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0366.md +++ b/tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0366.md @@ -15,6 +15,15 @@ If an exported receiver does not define [`android:permission`](https://developer This test checks whether the app exposes sensitive functionality through exported and unprotected broadcast receivers. +**Example Attack Scenario:** + +Suppose a banking app declares a broadcast receiver that resets the user's password based on extras in the received intent, and the receiver is exported with no `android:permission`. + +1. An attacker reverse engineers the app and finds the exported receiver, the action it listens for, and the extras it reads (see @MASTG-TECH-0162). +2. The attacker writes a malicious app that sends a broadcast targeting the receiver explicitly, with attacker-chosen extras. +3. The receiver acts on the unvalidated extras and resets the password (and may disclose the old one to the log). +4. The attacker takes over the account without any interaction from the victim. + ## Steps 1. Use @MASTG-TECH-0013 to reverse engineer the app. diff --git a/tests-beta/ios/MASVS-RESILIENCE/MASTG-TEST-0358.md b/tests-beta/ios/MASVS-RESILIENCE/MASTG-TEST-0358.md index 72012de7c43..f32d8efa051 100644 --- a/tests-beta/ios/MASVS-RESILIENCE/MASTG-TEST-0358.md +++ b/tests-beta/ios/MASVS-RESILIENCE/MASTG-TEST-0358.md @@ -15,6 +15,16 @@ This test checks for verbose error logging and debugging messages in iOS applica Common logging APIs on iOS include `NSLog`, `print`, `dump`, `debugPrint`, and `os_log`. If debug-level logging remains enabled in production builds, or if logged error messages are overly detailed, they can reveal implementation details that increase the app's attack surface. +**Example Attack Scenario:** + +Suppose an app logs detailed debug messages and error context in its release build. + +1. An attacker captures device logs while exercising the app and intentionally triggering failures (e.g., invalid inputs, offline mode). +2. The attacker uses the revealed module names, function names, endpoints, and stack traces to map internal code paths. +3. The attacker uses this information to focus reverse engineering efforts and target high-value code paths more efficiently. + +This test focuses on verbose logging that exposes implementation details. For tests specifically targeting sensitive data in logs, see @MASTG-TEST-0296 and @MASTG-TEST-0297. + ## Steps 1. Use @MASTG-TECH-0058 to extract the relevant binaries from app package.