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

---
platform: ios
title: Use of the iOS General Pasteboard
id: MASTG-TEST-0276
type: [static]
weakness: MASWE-0053
threat: [app]
prerequisites:
- identify-sensitive-data
profiles: [L2]
knowledge: [MASTG-KNOW-0083]
---

## Overview

This test checks whether the app uses the systemwide general @MASTG-KNOW-0083, which is persistent across device restarts and app uninstalls and is accessible by all foreground apps and, in some cases, other devices. Placing sensitive data here may pose a privacy risk.

The test statically analyzes the code for use of the general pasteboard ([`UIPasteboard.general`](https://developer.apple.com/documentation/uikit/uipasteboard/general)) and checks whether sensitive data is written using any of the following methods:

- [`addItems`](https://developer.apple.com/documentation/uikit/uipasteboard/additems(_:))
- [`setItems`](https://developer.apple.com/documentation/uikit/uipasteboard/setitems(_:options:))
- [`setData`](https://developer.apple.com/documentation/uikit/uipasteboard/setdata(_:forpasteboardtype:))
- [`setValue`](https://developer.apple.com/documentation/uikit/uipasteboard/setvalue(_:forpasteboardtype:))

## Steps

1. Run a static analysis scan using @MASTG-TOOL-0073 to detect usage of the general pasteboard.
2. Run a static analysis scan using @MASTG-TOOL-0073 to detect usage of the pasteboard methods which may be handling sensitive data.

## Observation

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

## Evaluation

The test fails if calls are made to `UIPasteboard.generalPasteboard` and sensitive data is written to it.

Since determining what constitutes sensitive data is context-dependent, it can be difficult to detect statically. To check if sensitive data is being written to the pasteboard using the aforementioned methods, inspect the reported code locations in the reverse-engineered code (see @MASTG-TECH-0076).
OWASP Mobile Application Security Testing Guide: MASTG TEST 0290

---
title: Runtime Verification of Sensitive Content Exposure in Screenshots During App Backgrounding
platform: ios
id: MASTG-TEST-0290
type: [dynamic, manual]
profiles: [L2]
weakness: MASWE-0055
prerequisites:
- identify-sensitive-screens
knowledge: [MASTG-KNOW-0099]
---

## Overview

This test verifies that the app hides sensitive content from the screen when it moves to the background. This is important because iOS captures a snapshot of the app UI when it transitions to the background. This snapshot is used for the [App Switcher](https://support.apple.com/guide/iphone/switch-between-open-apps-iph1a1f981ad/ios) and transitions, and can expose sensitive content if the app does not protect it.

## Steps

1. Exercise your app until you get to each of the screens identified as sensitive. While on each of those screens, move the app to the background (for example by pressing **Home** or opening the **App Switcher** and exiting it) and continue to the next screen.
2. Once finished, use @MASTG-TECH-0053 to copy the snapshots taken by the system to your analysis workstation. The system stores them under `/var/mobile/Containers/Data/Application/<APP_ID>/Library/SplashBoard/Snapshots/sceneID:<APP_NAME>-default/`. Note that the exact path and structure may vary across iOS versions.

## Observation

The output should include a collection of snapshots cached when the app entered the background state.

## Evaluation

The test case fails if any snapshot displays sensitive data that should have been protected.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0277

---
platform: ios
title: Sensitive Data in the iOS General Pasteboard at Runtime
id: MASTG-TEST-0277
type: [dynamic]
weakness: MASWE-0053
threat: [app]
prerequisites:
- identify-sensitive-data
profiles: [L2]
knowledge: [MASTG-KNOW-0083]
---

## Overview

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

In this case we'll monitor the @MASTG-KNOW-0083 for sensitive data being written to it at runtime. Note that this can be challenging to detect, as it requires the app to be running and the pasteboard to be modified while the test is being executed. You can trigger the pasteboard by manually entering sensitive data into the app, such as passwords or personal information, while the test is running. Or you can do it automatically by using a script that simulates user input or modifies the pasteboard directly.

## Steps

1. Monitor the pasteboard for sensitive data using @MASTG-TECH-0134.
2. Run the app and perform actions that may write sensitive data to the pasteboard, such as copying passwords or personal information.

## Observation

The output should contain a list of pasteboard items that were written during the test.

## Evaluation

The test fails if sensitive data is traced during a write operation to the general pasteboard specifically.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0331

---
platform: ios
title: Use of Deprecated WebView APIs
id: MASTG-TEST-0331
type: [static]
available_since: 2.0
deprecated_since: 12.0
weakness: MASWE-0072
profiles: [L1, L2]
best-practices: [MASTG-BEST-0032]
knowledge: [MASTG-KNOW-0076]
---

## Overview

In this test, we look for references to `UIWebView` (@MASTG-KNOW-0076), a deprecated component since iOS 12.0, in favor of `WKWebView`. `UIWebView` presents security and performance risks: it does not allow JavaScript to be fully disabled, lacks process isolation (which `WKWebView` provides), and doesn't support modern web security features like Content Security Policy (CSP).

## Steps

1. Extract the app as described in @MASTG-TECH-0058.
2. Look for references to `UIWebView` in the app using @MASTG-TECH-0070 on all executables and libraries.

## Observation

The output should contain a list of locations where `UIWebView`s are used.

## Evaluation

The test case fails if any use of `UIWebView` is found in the app.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0280

---
platform: ios
title: Pasteboard Contents Not Restricted to Local Device
id: MASTG-TEST-0280
type: [static]
weakness: MASWE-0053
threat: [app]
profiles: [L2]
knowledge: [MASTG-KNOW-0083]
---

## Overview

This test checks if the app restricts the contents of the general @MASTG-KNOW-0083 to the local device by using the `UIPasteboard.setItems(_:options:)` method with the `UIPasteboard.OptionsKey.localOnly` option. If sensitive data is placed in the general pasteboard without this restriction, it can be synced across devices via Universal Clipboard, leading to potential data leaks.

## Steps

1. Run a static analysis scan using @MASTG-TOOL-0073 to detect usage of the [`UIPasteboard.general`](https://developer.apple.com/documentation/uikit/uipasteboard/1622106-generalpasteboard "UIPasteboard generalPasteboard") property.
2. Run a static analysis scan using @MASTG-TOOL-0073 to detect usage of the `UIPasteboard.setItems(_:options:)` method.

## Observation

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

## Evaluation

The test fails if the app uses the general pasteboard without restricting its contents to the local device. Specifically, ensure that the `UIPasteboard.setItems(_:options:)` method is called with the `UIPasteboard.Options.localOnly` option.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0333

---
platform: ios
title: Overly Broad File Read Access in WebViews
id: MASTG-TEST-0333
type: [static]
weakness: MASWE-0069
best-practices: [MASTG-BEST-0033]
knowledge: [MASTG-KNOW-0076]
profiles: [L1, L2]
---

## Overview

iOS apps can load local files into a [`WKWebView`](https://developer.apple.com/documentation/webkit/wkwebview) using [`loadFileURL(_:allowingReadAccessTo:)`](https://developer.apple.com/documentation/webkit/wkwebview/loadfileurl(_:allowingreadaccessto:)).

This test checks whether the app uses `loadFileURL(_:allowingReadAccessTo:)` with an overly broad `readAccessURL`. If attacker-controlled input influences the loaded file URL and the read access scope is too broad, the WebView may gain access to sensitive files within the app container.

## Steps

1. Extract the app as described in @MASTG-TECH-0058.
2. Run a static analysis tool such as @MASTG-TOOL-0073 on the app binary, looking for calls to `WKWebView.loadFileURL(_:allowingReadAccessTo:)`.

## Observation

The output should contain a list of locations in the binary where `WKWebView.loadFileURL(_:allowingReadAccessTo:)` is called.

## Evaluation

The test case fails if any call to `loadFileURL(_:allowingReadAccessTo:)` is found where the `readAccessURL` argument grants overly broad read access, for example to the entire `Documents` directory or the app container root.

Inspect each reported call site using @MASTG-TECH-0076.

- Inspect the `fileURL` argument and determine whether it can be influenced by attacker-controlled input.
- Inspect the `readAccessURL` argument and determine whether it grants broader access than necessary.
- Verify that the allowed read scope is restricted to the minimum directory required for the intended content.

The test passes if every use of `loadFileURL(_:allowingReadAccessTo:)` restricts `readAccessURL` to the minimum necessary scope and does not allow attacker-influenced file loading to reach unintended files.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0278

---
platform: ios
title: Pasteboard Contents Not Cleared After Use
id: MASTG-TEST-0278
type: [static]
weakness: MASWE-0053
threat: [app]
profiles: [L2]
knowledge: [MASTG-KNOW-0083]
---

## Overview

This test checks if the app clears the contents of the general @MASTG-KNOW-0083 when it moves to the background or terminates. If sensitive data is left in the pasteboard, it can be accessed by other apps, leading to potential data leaks.

Apps can clear the contents of the general pasteboard by setting `UIPasteboard.general.items = []` in the appropriate lifecycle methods, such as `applicationDidEnterBackground:` or `applicationWillTerminate:`.

## Steps

1. Run a static analysis scan using @MASTG-TOOL-0073 to detect usage of the [`UIPasteboard.general`](https://developer.apple.com/documentation/uikit/uipasteboard/1622106-generalpasteboard "UIPasteboard generalPasteboard") property.
2. Run a static analysis scan using @MASTG-TOOL-0073 to detect usage of the [`UIPasteboard.setItems`](https://developer.apple.com/documentation/uikit/uipasteboard/setitems(_:options:) "UIPasteboard setItems") method.

## Observation

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

## Evaluation

The test fails if the app uses the general pasteboard and does not clear its contents when moving to the background or terminating. Specifically, it should be verified that there are calls to `UIPasteboard.setItems` with an empty array (`[]`) in the appropriate lifecycle methods.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0275

---
platform: ios
title: Dependencies with Known Vulnerabilities in the App's SBOM
id: MASTG-TEST-0275
type: [static, developer]
weakness: MASWE-0076
profiles: [L1, L2]
---

## Overview

This test case checks for dependencies with known vulnerabilities in iOS applications by using a Software Bill of Materials (SBOM). The SBOM should be in CycloneDX format, which is a standard for describing the components and dependencies of software.

## Steps

1. Either ask the development team to share a SBOM in CycloneDX format, or, if you have access to the original source code, create one following @MASTG-TECH-0132.
2. Upload the SBOM to @MASTG-TOOL-0132.
3. Inspect the @MASTG-TOOL-0132 project for the use of vulnerable dependencies.

## Observation

The output should include a list of dependencies with names and CVE identifiers, if any.

## Evaluation

The test case fails if you can find dependencies with known vulnerabilities.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0273

---
platform: ios
title: Identify Dependencies with Known Vulnerabilities by Scanning Dependency Managers Artifacts
id: MASTG-TEST-0273
type: [static]
weakness: MASWE-0076
profiles: [L1, L2]
---

## Overview

In this test case we are identifying dependencies with known vulnerabilities in iOS. Dependencies are integrated through dependency managers, and there might be one or more of them being used. We therefore need all of the relevant artifacts created by them to analyse them with a SCA scanning tool.

## Steps

1. In order to do this in the most efficient way you would need to ask the developer(s) which dependency managers are being used and to share the relevant file(s) created by them. Follow @MASTG-TECH-0133 for on overview of the package managers and request for the relevant files.

2. Run a SCA analysis tool such as @MASTG-TOOL-0131 against the file(s) created by the dependency manager(s) and look for the use of vulnerable dependencies.

## Observation

The output should include the dependency name and the CVE identifiers for any dependency with known vulnerabilities.

## Evaluation

The test case fails if you can find dependencies with known vulnerabilities.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0228

---
title: Position Independent Code (PIC) not Enabled
platform: ios
id: MASTG-TEST-0228
type: [static]
weakness: MASWE-0116
profiles: [L2]
knowledge: [MASTG-KNOW-0061]
---

## Overview

[PIE (Position Independent Executables)](../../../Document/0x04h-Testing-Code-Quality.md#position-independent-code) are designed to enhance security by allowing executables to be loaded at random memory addresses, mitigating certain types of attacks.

In the context Mach-O file format of iOS applications:

- PIE is applicable to executables with the `MH_EXECUTE` file type, which essentially means the main app binary (e.g. `YourApp.app/YourApp`).
- Shared libraries with the `MH_DYLIB` file type (dylibs and frameworks) are inherently position-independent and do not utilize the `MH_PIE` flag.

This test case checks if the main executable is compiled with PIE.

## Steps

1. Extract the application and identify the main binary (@MASTG-TECH-0054).
2. Run @MASTG-TECH-0118 on the main binary and grep for "pic" or the corresponding keyword used by the selected tool.

## Observation

The output should list if PIC is enabled or disabled.

## Evaluation

The test case fails if PIC is disabled.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0230

---
title: Automatic Reference Counting (ARC) not enabled
platform: ios
id: MASTG-TEST-0230
type: [static]
weakness: MASWE-0116
profiles: [L2]
knowledge: [MASTG-KNOW-0061]
---

## Overview

This test case checks if [ARC (Automatic Reference Counting)](../../../Document/0x04h-Testing-Code-Quality.md#automatic-reference-counting) is enabled in iOS apps. ARC is a compiler feature in Objective-C and Swift that automates memory management, reducing the likelihood of memory leaks and other related issues. Enabling ARC is crucial for maintaining the security and stability of iOS applications.

- **Objective-C Code:** ARC can be enabled by compiling with the `-fobjc-arc` flag in Clang.
- **Swift Code:** ARC is enabled by default.
- **C/C++ Code:** ARC is not applicable, as it pertains specifically to Objective-C and Swift.

When ARC is enabled, binaries will include symbols such as `objc_autorelease` or `objc_retainAutorelease`.

## Steps

1. Extract the application and identify the main binary (@MASTG-TECH-0054).
2. Identify all shared libraries (@MASTG-TECH-0082).
3. Run @MASTG-TECH-0118 on the main binary and each shared library looking for ARC symbols like `objc_autorelease` or `objc_retainAutorelease`.

## Observation

The output should contain a list of symbols of the main binary and each shared library.

## Evaluation

The test fails if any binary or library containing Objective-C or Swift code is missing ARC-related symbols. The presence of symbols such as `_objc_msgSend` (Objective-C) or `_swift_allocObject` (Swift) without corresponding ARC symbols indicates that ARC may not be enabled.

**Note:** Checking for these symbols only indicates that ARC is enabled somewhere in the app. While ARC is typically enabled or disabled for the entire binary, there can be corner cases where only parts of the application or libraries are protected. For example, if the app developer statically links a library that has ARC enabled, but disables it for the entire application.

If you want to be sure that specific security-critical methods are adequately protected, you need to reverse-engineer each of them and manually check for ARC, or request the source code from the developer.
OWASP Mobile Application Security Testing Guide: README

# UnCrackable Mobile Apps

<img align="left" width="100px" src="../Document/Images/Other/uncrackable-logo.png" />

These are the UnCrackable Apps for Android and iOS, a collection of mobile reverse engineering challenges. These challenges are used as examples throughout the OWASP MASTG. Of course, you can also solve them for fun.

See <https://mas.owasp.org/crackmes> for more information.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0026

---
title: Dynamic Analysis on Non-Rooted Devices
platform: android
---

If you don't have access to a rooted device, you can patch and repackage the target app to load a dynamic library at startup (e.g., the Frida gadget), enabling dynamic testing with Frida and related tools such as objection. Unlike iOS, Android apps aren't FairPlay-encrypted, so you can extract the APK directly from a device or download it from an alternative store without root access.

!!! note "Using the Android Emulator"
    For researchers and learners, the Android Emulator is often the simplest starting point. Apps running in the Emulator are not subject to the same hardware-backed restrictions as physical devices. You can attach Frida directly to the process without using the Frida Gadget (simply using `frida -U`), without patching the binary, and without re-signing the app. This makes the Emulator ideal for experimentation, scripting, and learning dynamic analysis techniques before moving to real-device testing. Keep in mind that the Emulator doesn't perfectly replicate real-device behavior, especially for hardware-backed features such as TEE/StrongBox, biometrics, certain hardware identifiers, and anti-emulator or root-detection checks.

The following sections walk through each step of the process for real non-rooted devices.

## Step 1: Obtain the APK

Follow @MASTG-TECH-0003 to obtain the APK for the app you want to test.

## Step 2: Inject the Frida Gadget

Follow @MASTG-TECH-0041 to patch the APK and inject the Frida Gadget library. Tools such as @MASTG-TOOL-0038 can automate most of this process as described in @MASTG-TECH-0004.

## Step 3: Sign the APK

Follow @MASTG-TECH-0039 to re-sign the patched APK. A standard Android debug keystore is sufficient; no developer account or special certificate is required.

## Step 4: Install the App

Follow @MASTG-TECH-0005 to install the re-signed APK on your device. If the original app is already installed, you'll need to uninstall it first, as Android rejects installations where the signing certificate has changed.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0143

---
title: Monitor File System Operations in WebViews
platform: android
---

You can monitor any file system operations in the WebView storage directory using various techniques:

Use @MASTG-TECH-0033 to monitor file system operations in the `/data/data/<app_package>/app_webview/` directory. Regardless of whether the app uses these APIs directly, WebViews may use them internally when rendering content (e.g., JavaScript code using `localStorage`). So tracing calls to APIs such as `open`, `openat`, `opendir`, `unlinkat`, etc., can help identify file operations in the WebView storage directory.

In addition to tracing the method calls, you can also monitor all file operations:

- use @MASTG-TECH-0027 to monitor file operations in that directory, e.g., with `lsof -p <app_pid> | grep /app_webview/`.
- or use @MASTG-TECH-0032, e.g. with `strace -p <app_pid>`, to monitor file operations in that directory.
OWASP Mobile Application Security Testing Guide: MASTG TECH 0126

---
title: Obtaining App Permissions
platform: android
---

Android permissions are declared in the `AndroidManifest.xml` file using the `<uses-permission>` tag. You can use multiple tools to view them.

## Using the AndroidManifest

Extract the `AndroidManifest.xml` as explained in @MASTG-TECH-0117 and retrieve all [`<uses-permission>`](https://developer.android.com/guide/topics/manifest/uses-permission-element) elements.

## Using @MASTG-TOOL-0124

`aapt` can be used to view the permissions requested by an application.

```bash
$ aapt d permissions org.owasp.mastestapp.apk
package: org.owasp.mastestapp
uses-permission: name='android.permission.INTERNET'
uses-permission: name='android.permission.CAMERA'
uses-permission: name='android.permission.WRITE_EXTERNAL_STORAGE'
uses-permission: name='android.permission.READ_CONTACTS'
uses-permission: name='android.permission.READ_EXTERNAL_STORAGE'
uses-permission: name='org.owasp.mastestapp.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION'
```

## Using @MASTG-TOOL-0004

`adb` can be used to view the permissions requested by an application. It also shows the status of the permissions (granted or denied) at runtime.

```bash
$ adb shell dumpsys package org.owasp.mastestapp | grep permission
    declared permissions:
    requested permissions:
      android.permission.INTERNET
      android.permission.CAMERA
      android.permission.WRITE_EXTERNAL_STORAGE
      android.permission.READ_CONTACTS
      android.permission.READ_EXTERNAL_STORAGE
    install permissions:
      android.permission.INTERNET: granted=true
      runtime permissions:
        android.permission.READ_EXTERNAL_STORAGE: granted=false, flags=[ RESTRICTION_INSTALLER_EXEMPT]
        android.permission.CAMERA: granted=false
        android.permission.WRITE_EXTERNAL_STORAGE: granted=false, flags=[ RESTRICTION_INSTALLER_EXEMPT]
        android.permission.READ_CONTACTS: granted=false
```
OWASP Mobile Application Security Testing Guide: MASTG TECH 0130

---
title: Software Composition Analysis (SCA) of Android Dependencies by Creating a SBOM
platform: android
---

@MASTG-TOOL-0134 can be used to create a so-called Software Bill of Materials (SBOM) in the CycloneDX format. Navigate to the root directory of the Android Studio project you want to scan and execute the following command:

```bash
$ cdxgen -t java -o sbom.json
```

The created SBOM file needs to be Base64 encoded and can then be uploaded to @MASTG-TOOL-0132 for analysis:

```bash
$ cat sbom.json | base64
$ curl -X "PUT" "http://localhost:8081/api/v1/bom" \
     -H 'Content-Type: application/json' \
     -H 'X-API-Key: <YOUR API KEY>>' \
     -d $'{
  "project": "<YOUR PROJECT ID>",
  "bom": "<BASE64-ENCODED SBOM>"
  }'
```

Go to the frontend of dependency-check, which is <http://localhost:8080>, if you are using the default settings of the dependency-track Docker container. Open the project you uploaded the SBOM to, and you can verify if there are any vulnerable dependencies.

!!! note
    Transitive dependencies are supported by @MASTG-TOOL-0132 for [Java and Kotlin](https://cdxgen.github.io/cdxgen/#/PROJECT_TYPES).