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

---
platform: ios
title: Insecure Random API Usage
id: MASTG-TEST-0311
type: [static, dynamic]
weakness: MASWE-0027
profiles: [L1, L2]
best-practices: [MASTG-BEST-0025]
knowledge: [MASTG-KNOW-0070]
---

## Overview

iOS apps sometimes use insecure pseudorandom number generators (PRNGs) instead of cryptographically secure ones. This test case focuses on detecting the use of insecure alternatives such as the standard C library functions `rand`, `random`, and the `*rand48` family.

## Steps

1. Run a static analysis tool such as @MASTG-TOOL-0073 on the app binary, or use runtime method hooking (see @MASTG-TECH-0095), and look for insecure random APIs.

## Observation

The output should contain a list of locations where insecure random APIs are used, including the function names and code locations where they are called.

## Evaluation

The test case fails if random numbers generated using insecure APIs are used in security-relevant contexts.

For each of the identified API uses, verify the context by decompiling or disassembling the code (see @MASTG-TECH-0076) to determine if the generated random values are used for security-relevant purposes, such as:

- Generating cryptographic keys, initialization vectors (IVs), or nonces
- Creating authentication tokens or session identifiers
- Generating passwords or PINs
- Any other security-relevant operations requiring unpredictability

Other uses of insecure random APIs unrelated to security (e.g., generating random delays, non-security-related identifiers, game mechanics) do not cause the test case to fail.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0317

---
title: Broken Symmetric Encryption Modes
platform: ios
id: MASTG-TEST-0317
type: [static, dynamic]
weakness: MASWE-0020
best-practices: [MASTG-BEST-0005]
profiles: [L1, L2]
---

## Overview

This test focuses on broken symmetric encryption modes such as [ECB (Electronic Codebook)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_(ECB)).

> For more information, please refer to [use of broken encryption modes](../../../Document/0x04g-Testing-Cryptography.md#broken-block-cipher-modes).

In iOS development, the more recent `CryptoKit` does not support ECB mode and is therefore not vulnerable to this issue, as it only supports secure encryption modes like AES-GCM and ChaCha20-Poly1305. However, applications may use the older `CommonCrypto` library or other third-party libraries that may support ECB mode. In this case, it is essential to verify that ECB mode is not being used.

In [`CommonCrypto`](https://web.archive.org/web/[PII_REDACTED]0307/https://opensource.apple.com/source/CommonCrypto/CommonCrypto-36064/CommonCrypto/CommonCryptor.h), ECB mode can be enabled by setting the `kCCOptionECBMode` (value `0x0002` or `2`) in the `options` parameter of the `CCCrypt` function. When `kCCOptionECBMode` is set in the options parameter, the encryption uses ECB mode, which is considered vulnerable. The default behavior (when `kCCOptionECBMode` is not set) is to use CBC mode, which is more secure when used with a proper initialization vector (IV).

## Steps

1. Use @MASTG-TECH-0065 to reverse engineer the app.
2. Use @MASTG-TECH-0072 to look for uses of symmetric encryption and its modes.
3. Use @MASTG-TECH-0076 to analyze the relevant code paths and obtain the values for the encryption modes.

## Observation

The output should contain the uses of symmetric encryption and its modes.

## Evaluation

The test case fails if you can find the use of symmetric encryption with broken modes enabled, such as ECB mode.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0219

---
platform: ios
title: Testing for Debugging Symbols
id: MASTG-TEST-0219
type: [static]
weakness: MASWE-0093
profiles: [R]
knowledge: [MASTG-KNOW-0063]
---

## Overview

This test case checks for [debugging symbols](https://mas.owasp.org/MASWE/MASVS-RESILIENCE/MASWE-0093/) in all binaries contained in the app.

Debugging symbols are added by the [compiler to ease development](https://developer.apple.com/documentation/xcode/building-your-app-to-include-debugging-information "Building your app to include debugging information") and allow symbolication of crashes. However, they can also be used to reverse engineer the app and should not be present in a released app. [Symbolication can also be performed](https://developer.apple.com/documentation/xcode/adding-identifiable-symbol-names-to-a-crash-report "Adding identifiable symbol names to a crash report") with a separate dSYM file.

To manage debugging symbols in Xcode, developers can adjust the following build settings:

- **Generate Debug Symbols**: Xcode adds debugging symbols if the setting [`"Build Settings" > "Apple Clang - Code Generation" > "Generate Debug Symbols"`](https://developer.apple.com/documentation/xcode/build-settings-reference#Generate-Debug-Symbols) is set to `"Yes"`.
- **Debug Information Format**: Found under [`"Build Settings" > "Build Options > "Debug Information Format"`](https://developer.apple.com/documentation/xcode/build-settings-reference#Debug-Information-Format), this setting determines the format of the debug information. Options include:
    - **DWARF**: Embeds debugging information directly into the binary.
    - **DWARF with dSYM File**: Generates a separate dSYM file containing debugging information.

Note that in compiled iOS applications, symbol names may undergo **name mangling** and additional **obfuscation techniques** to further obscure them, making reverse engineering more challenging. While demangling tools can decode standard mangled names (see @MASTG-TECH-0114), they may not effectively reverse custom obfuscation methods.

## Steps

1. Apply @MASTG-TECH-0058 to extract the contents from the IPA file.
2. For all executables and libraries of the app, use @MASTG-TECH-0113 to verify there are no debugging symbols present.

## Observation

The output should contain a list of symbols for each executable and library.

## Evaluation

The test fails if there are symbols marked as debug symbols in the output.

Before releasing an iOS app, verify that the `"Build Settings" > "Apple Clang - Code Generation" > "Generate Debug Symbols"` setting is set to `"No"`. Additionally, utilize tools like the ones used in @MASTG-TECH-0113 to inspect the final binaries for any residual debugging symbols.

For release builds, it's advisable to set `"Build Settings" > "Build Options > "Debug Information Format"` to `"DWARF with dSYM File"` and ensure that the dSYM files are securely stored and not distributed with the app. This approach facilitates post-release crash analysis without exposing debugging symbols in the distributed binary.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0248

---
platform: ios
title: References to APIs for Detecting Secure Screen Lock
id: MASTG-TEST-0248
apis: [LAContext.canEvaluatePolicy, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly]
type: [static]
weakness: MASWE-0008
best-practices: []
profiles: [L2]
knowledge: [MASTG-KNOW-0056]
---

## Overview

This test verifies that an app is running on a device with a secure [screen lock (e.g. a passcode)](https://support.apple.com/en-us/guide/iphone/iph14a867ae/ios).

On iOS, apps can determine whether a secure screen lock is set using the **LocalAuthentication** framework. Specifically, the [LAContext.canEvaluatePolicy(_:error:)](https://developer.apple.com/documentation/localauthentication/lacontext/canevaluatepolicy(_:error:)) method with the [.deviceOwnerAuthentication](https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthentication) or [.deviceOwnerAuthenticationWithBiometrics](https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthenticationwithbiometrics) policy can be used to check if authentication mechanisms, including a passcode, are available.

Apps leveraging the **Keychain Services API** can require passcode authentication before accessing sensitive data using the [kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly](https://developer.apple.com/documentation/security/ksecattraccessiblewhenpasscodesetthisdeviceonly) attribute.

## Steps

1. Run a static analysis tool such as @MASTG-TOOL-0073 on the app binary and look for uses of [LAContext.canEvaluatePolicy(.deviceOwnerAuthentication)](https://developer.apple.com/documentation/localauthentication/lacontext/canevaluatepolicy(_:error:)) API, or data stored with [kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly](https://developer.apple.com/documentation/security/ksecattraccessiblewhenpasscodesetthisdeviceonly) attribute.

## Observation

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

## Evaluation

The test fails if an app doesn't use any API to verify the secure screen lock presence.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0240

---
platform: ios
title: Jailbreak Detection in Code
id: MASTG-TEST-0240
type: [dynamic]
weakness: MASWE-0097
false_negative_prone: true
profiles: [R]
knowledge: [MASTG-KNOW-0084]
---

## Overview

The test verifies that a mobile app can detect if the iOS device it is running on is jailbroken. It does so by statically analyzing the app binary for [common jailbreak detection checks](../../../Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md#common-jailbreak-detection-checks). For example, the app may check for the presence of a third-party app store (e.g. Sileo, Zebra, ...), or for the presence of certain files or directories that are indicative of a jailbroken device.

The limitations of static analysis should be considered. It is possible that the app uses more sophisticated jailbreak detection techniques that are not detected by the used tool. In such cases, careful manual reverse engineering and deobfuscation are required to identify the jailbreak detection checks.

## Steps

1. Run a static analysis tool such as @MASTG-TOOL-0073 on the app binary looking for common jailbreak detection checks.

## Observation

The output should include any instances of common jailbreak detection checks in the app binary.

## Evaluation

The test passes if jailbreak detection is implemented.

The test fails if jailbreak detection is not implemented. However, note that this test is not exhaustive and may not detect all jailbreak detection checks. Manual reverse engineering and deobfuscation may be required to identify more sophisticated jailbreak detection checks.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0220

---
platform: ios
title: Usage of Outdated Code Signature Format
id: MASTG-TEST-0220
type: [static]
weakness: MASWE-0104
profiles: [R]
knowledge: [MASTG-KNOW-0058]
---

## Overview

On iOS, code signatures verify the integrity and authenticity of an app's binary, preventing unauthorized modifications and ensuring that the app is trusted by the operating system. Apple regularly updates its [code signature formats](https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format) to enhance cryptographic strength and improve protection against tampering.

Using an outdated code signature format may expose the app to security risks, as older formats may lack support for current cryptographic standards and may be more vulnerable to manipulation. Adopting the latest code signature format helps maintain app integrity and ensures compatibility with the latest security features in iOS.

## Steps

1. Extract the package as described in @MASTG-TECH-0058.
2. Obtain the version of the code signature format as described in @MASTG-TECH-0112.

## Observation

The output should contain the version of the code signature format.

## Evaluation

The test fails if the version is below the [recommended one](https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format "Apple Developer").

Ensure that the app is using the [latest code signing format](https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format "Apple Developer"). You can retrieve the signing certificate format with @MASTG-TECH-0112. This will ensure that the integrity of the app is protected according to the latest cryptographic standards, preventing tampering with the app binary and ensuring that the unmodified copy is distributed to users.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0246

---
platform: ios
title: Runtime Use of Secure Screen Lock Detection APIs
id: MASTG-TEST-0246
apis: [LAContext.canEvaluatePolicy, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly]
type: [dynamic]
weakness: MASWE-0008
best-practices: []
profiles: [L2]
knowledge: [MASTG-KNOW-0056]
---

## Overview

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

## Steps

1. Run a dynamic analysis tool like @MASTG-TOOL-0039 and look for uses of [LAContext.canEvaluatePolicy(.deviceOwnerAuthentication)](https://developer.apple.com/documentation/localauthentication/lacontext/canevaluatepolicy(_:error:)) API or data stored with [kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly](https://developer.apple.com/documentation/security/ksecattraccessiblewhenpasscodesetthisdeviceonly) attribute.

## Observation

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

## Evaluation

The test fails if an app doesn't use any API to verify the secure screen lock presence.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0241

---
platform: ios
title: Runtime Use of Jailbreak Detection Techniques
id: MASTG-TEST-0241
type: [dynamic]
weakness: MASWE-0097
false_negative_prone: true
profiles: [R]
knowledge: [MASTG-KNOW-0084]
---

## Overview

The test verifies that a mobile application can identify if the iOS device it is running on is jailbroken. It does so by dynamically analyzing the app binary for [common jailbreak detection checks](../../../Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md#common-jailbreak-detection-checks) and trying to bypass them. For example, it may detect a check for the presence of certain files or directories that are indicative of a jailbroken device.

The limitations of using jailbreak detection bypass tools should be considered. It is possible that the app uses more sophisticated jailbreak detection techniques that are not detected by the tool used. In such cases, careful manual reverse engineering and deobfuscation are required to identify the jailbreak detection checks. Also, additional dynamic analysis work may be required to bypass the jailbreak detection checks.

## Steps

1. Run a dynamic analysis tool such as @MASTG-TOOL-0038 on the app and execute its [automated jailbreak detection bypass commands](../../../Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md#automated-jailbreak-detection-bypass)

## Observation

The output should include any instances of common jailbreak detection checks in the app binary and the results of the automated jailbreak detection bypass commands.

## Evaluation

The test passes if the automated jailbreak detection bypass command indicates that the application is testing for known jailbreak artefacts.

The test fails if jailbreak detection is not implemented. However, note that this test is not exhaustive and may not detect all jailbreak detection checks as it relies on predefined bypass code that may not cover all possible jailbreak detection checks or may not be up-to-date. The checks may also be more sophisticated than what the tool can detect so manual reverse engineering and deobfuscation may be required to identify them.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0261

---
platform: ios
title: Debuggable Entitlement Enabled in the entitlements.plist
id: MASTG-TEST-0261
type: [static]
weakness: MASWE-0067
profiles: [R]
knowledge: [MASTG-KNOW-0062]
---

## Overview

The test evaluates whether an iOS application is configured to allow debugging. If an app is debuggable, attackers can leverage debugging tools (see @MASTG-TECH-0084) to analyse the runtime behaviour of the app, and potentially compromise sensitive data or functionality.

## Steps

1. Use @MASTG-TECH-0111 to extract entitlements from the binary.
2. Search for the `get-task-allow` key.

## Observation

The output should contain the value of the `get-task-allow` entitlement.

## Evaluation

The test fails if the `get-task-allow` entitlement is `true`.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0321

---
platform: ios
title: Hardcoded HTTP URLs
id: MASTG-TEST-0321
type: [static]
weakness: MASWE-0050
profiles: [L1, L2]
---

## Overview

An iOS app may have hardcoded HTTP URLs embedded in the app binary, library binaries, or other resources within the IPA. These URLs may indicate potential locations where the app communicates with servers over an unencrypted connection.

## Steps

1. Use @MASTG-TECH-0065 to reverse engineer the app.
2. Use @MASTG-TECH-0071 to search for any `http://` URLs.

## Observation

The output should contain a list of URLs and their locations within the app.

## Evaluation

The test case fails if any HTTP URLs are confirmed to be used for communication.

!!! warning Limitations
    The presence of HTTP URLs alone does not necessarily mean they are actively used for communication. Their usage may depend on runtime conditions, such as how the URLs are invoked and whether cleartext traffic is allowed in the app's ATS configuration. For example, HTTP requests may fail if App Transport Security (ATS) is enabled and no exceptions are configured (see @MASTG-TEST-0322) or may succeed if the app uses low-level APIs that bypass ATS (see @MASTG-TEST-0322).

Additionally, complement this static inspection with dynamic testing methods. For example, capture and analyze network traffic to confirm whether the app connects to the identified HTTP URLs during real-world usage. See @MASTG-TEST-0236.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0323

---
platform: ios
title: Uses of Low-Level Networking APIs for Cleartext Traffic
id: MASTG-TEST-0323
type: [static]
weakness: MASWE-0050
profiles: [L1, L2]
knowledge: [MASTG-KNOW-0073]
---

## Overview

App Transport Security (ATS) only applies to connections made via the [URL Loading System](https://developer.apple.com/documentation/foundation/url_loading_system) (typically `URLSession`). Lower-level networking APIs bypass ATS entirely, meaning they can establish cleartext HTTP connections regardless of the app's ATS configuration.

The following low-level APIs are not affected by ATS:

- **[`Network` framework](https://developer.apple.com/documentation/network)**: A modern low-level networking API for socket-level communication using TCP and UDP.
- **[`CFNetwork`](https://developer.apple.com/documentation/cfnetwork)**: Core Foundation-based networking APIs including `CFSocketStream`, `CFHTTPStream`, and related functions.
- **BSD Sockets**: Low-level POSIX socket APIs accessed through functions like `socket()`, `connect()`, `send()`, and `recv()`.

Apple [recommends](https://developer.apple.com/documentation/security/preventing_insecure_network_connections) preferring high-level frameworks: "ATS doesn't apply to calls your app makes to lower-level networking interfaces like the `Network` framework or `CFNetwork`. In these cases, you take responsibility for ensuring the security of the connection. You can construct a secure connection this way, but mistakes are both easy to make and costly. It's typically safest to rely on the URL Loading System instead."

For more information on when ATS applies, see @MASTG-KNOW-0071.

## Steps

1. Use @MASTG-TECH-0065 to reverse engineer the app.
2. Use @MASTG-TECH-0072 to look for uses of low-level networking APIs in the app binary.
3. Use @MASTG-TECH-0076 to analyze the relevant code paths and determine if they could establish cleartext connections. For example, if using `Network` framework, verify that TLS is properly configured using `.tls` parameter in `NWParameters`.

## Observation

The output should contain a list of low-level networking API usages and their locations within the app binary.

## Evaluation

The test case fails if the app uses low-level networking APIs to establish cleartext connections.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0279

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

## Overview

This test checks if the app sets an expiration date for the contents of the general @MASTG-KNOW-0083 using the `UIPasteboard.setItems(_:options:)` method with the `UIPasteboard.Options.expirationDate` option. If sensitive data is left in the pasteboard without an expiration date, it can be accessed by other apps indefinitely, 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 setting an expiration date for its contents. Specifically, ensure that the `UIPasteboard.setItems(_:options:)` method is called with the `UIPasteboard.Options.expirationDate` option.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0332

---
platform: ios
title: Attacker-Controlled URI in WebViews
id: MASTG-TEST-0332
type: [static]
weakness: MASWE-0071
best-practices: [MASTG-BEST-0034]
profiles: [L1, L2, P]
knowledge: [MASTG-KNOW-0076]
---

## Overview

iOS apps can dynamically load content into a [`WKWebView`](https://developer.apple.com/documentation/webkit/wkwebview) using various URL load methods. These methods can render both remote web content and locally stored files.

The following WKWebView APIs are commonly targeted if they process untrusted input:

**Remote URL Loading:**

- [`load(_:)`](https://developer.apple.com/documentation/webkit/wkwebview/load(_:))

**Local URL and Content Loading:**

- [`loadFileRequest(_:allowingReadAccessTo:)`](https://developer.apple.com/documentation/webkit/wkwebview/loadfilerequest(_:allowingreadaccessto:))
- [`loadFileURL(_:allowingReadAccessTo:)`](https://developer.apple.com/documentation/webkit/wkwebview/loadfileurl(_:allowingreadaccessto:))
- [`loadHTMLString(_:baseURL:)`](https://developer.apple.com/documentation/webkit/wkwebview/loadhtmlstring(_:baseurl:))
- [`load(_:mimeType:characterEncodingName:baseURL:)`](https://developer.apple.com/documentation/webkit/wkwebview/load(_:mimetype:characterencodingname:baseurl:))

Regardless of the source, passing a URL originating from attacker-controlled input (for example through a deep link, custom URL scheme, or user-supplied data from the UI) directly to the `WKWebView` URL load methods can lead to vulnerabilities such as unauthorized redirection, Cross-Site Scripting (XSS), or local file disclosure.

This test checks whether the app passes attacker-controlled input to `WKWebView` URL load APIs without adequate URL validation.

## 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 any `WKWebView` URL load APIs.

## Observation

The output should contain a list of locations in the binary where `WKWebView` URL load APIs are called.

## Evaluation

The test case fails if any call to `WKWebView` URL load APIs is found where the URL is derived from attacker-controlled input without proper validation.

Inspect each reported code location using @MASTG-TECH-0076.

- Trace where the URL originates.
- Determine whether it is derived from attacker-controlled input, for example a custom URL scheme parameter, a deep link component, or unsanitized user input from the UI.
- Verify that the URL is adequately validated before being passed to `WKWebView` URL load APIs.