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

---
masvs_v1_id:
- MSTG-STORAGE-5
masvs_v2_id:
- MASVS-STORAGE-2
platform: ios
title: Finding Sensitive Data in the Keyboard Cache
masvs_v1_levels:
- L1
- L2
profiles: [L1, L2]
status: deprecated
covered_by: [MASTG-TEST-0313, MASTG-TEST-0314]
deprecation_note: New version available in MASTG V2
---

## Overview

## Static Analysis

- Search through the source code for similar implementations, such as

```objectivec
  textObject.autocorrectionType = UITextAutocorrectionTypeNo;
  textObject.secureTextEntry = YES;
```

- Open xib and storyboard files in the `Interface Builder` of Xcode and verify the states of `Secure Text Entry` and `Correction` in the `Attributes Inspector` for the appropriate object.

The application must prevent the caching of sensitive information entered into text fields. You can prevent caching by disabling it programmatically, using the `textObject.autocorrectionType = UITextAutocorrectionTypeNo` directive in the desired UITextFields, UITextViews, and UISearchBars. For data that should be masked, such as PINs and passwords, set `textObject.secureTextEntry` to `YES`.

```objectivec
UITextField *textField = [ [ UITextField alloc ] initWithFrame: frame ];
textField.autocorrectionType = UITextAutocorrectionTypeNo;
```

## Dynamic Analysis

If a jailbroken iPhone is available, execute the following steps:

1. Reset your iOS device keyboard cache by navigating to `Settings > General > Reset > Reset Keyboard Dictionary`.
2. Use the application and identify the functionalities that allow users to enter sensitive data.
3. Retrieve the keyboard cache file with the extension `.dat` from the following directory and its subdirectories (which might be different for iOS versions before 8.0) by @MASTG-TECH-0052:
`/private/var/mobile/Library/Keyboard/`
4. Look for sensitive data, such as username, passwords, email addresses, and credit card numbers. If the sensitive data can be obtained via the keyboard cache file, the app fails this test.

```objectivec
UITextField *textField = [ [ UITextField alloc ] initWithFrame: frame ];
textField.autocorrectionType = UITextAutocorrectionTypeNo;
```

If you must use a non-jailbroken iPhone:

1. Reset the keyboard cache.
2. Key in all sensitive data.
3. Use the app again and determine whether autocorrect suggests previously entered sensitive information.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0063

---
masvs_v1_id:
- MSTG-CRYPTO-6
masvs_v2_id:
- MASVS-CRYPTO-1
platform: ios
title: Testing Random Number Generation
masvs_v1_levels:
- L1
- L2
profiles: [L1, L2]
status: deprecated
covered_by: [MASTG-TEST-0311]
deprecation_note: New version available in MASTG V2
---

## Overview

## Static Analysis

In Swift, the [`SecRandomCopyBytes` API](https://developer.apple.com/reference/security/1399291-secrandomcopybytes "SecRandomCopyBytes (Swift)") is defined as follows:

```default
func SecRandomCopyBytes(_ rnd: SecRandomRef?,
                      _ count: Int,
                      _ bytes: UnsafeMutablePointer<UInt8>) -> Int32
```

The [Objective-C version](https://developer.apple.com/reference/security/1399291-secrandomcopybytes?language=objc "SecRandomCopyBytes (Objective-C)") is

```objectivec
int SecRandomCopyBytes(SecRandomRef rnd, size_t count, uint8_t *bytes);
```

The following is an example of the APIs usage:

```objectivec
int result = SecRandomCopyBytes(kSecRandomDefault, 16, randomBytes);
```

Note: if other mechanisms are used for random numbers in the code, verify that these are either wrappers around the APIs mentioned above or review them for their secure-randomness. Often this is too hard, which means you can best stick with the implementation above.

## Dynamic Analysis

If you want to test for randomness, you can try to capture a large set of numbers and check with [Burp's sequencer plugin](https://portswigger.net/burp/documentation/desktop/tools/sequencer "Sequencer") to see how good the quality of the randomness is.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0062

---
masvs_v1_id:
- MSTG-CRYPTO-1
- MSTG-CRYPTO-5
masvs_v2_id:
- MASVS-CRYPTO-2
platform: ios
title: Testing Key Management
masvs_v1_levels:
- L1
- L2
profiles: [L2]
status: deprecated
covered_by: [MASTG-TEST-0213, MASTG-TEST-0214]
deprecation_note: New version available in MASTG V2
---

## Overview

## Static Analysis

There are various keywords to look for: check the libraries mentioned in the overview and static analysis of the section "Verifying the Configuration of Cryptographic Standard Algorithms" for which keywords you can best check on how keys are stored.

Always make sure that:

- keys are not synchronized over devices if it is used to protect high-risk data.
- keys are not stored without additional protection.
- keys are not hardcoded.
- keys are not derived from stable features of the device.
- keys are not hidden by use of lower level languages (e.g. C/C++).
- keys are not imported from unsafe locations.

Check also the [list of common cryptographic configuration issues](../../../Document/0x04g-Testing-Cryptography.md#common-configuration-issues).

Most of the recommendations for static analysis can already be found in chapter "Testing Data Storage for iOS". Next, you can read up on it at the following pages:

- [Apple Developer Documentation: Certificates and keys](https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys "Certificates and keys")
- [Apple Developer Documentation: Generating new keys](https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/generating_new_cryptographic_keys "Generating new keys")
- [Apple Developer Documentation: Key generation attributes](https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/key_generation_attributes "Key Generation attributes")

## Dynamic Analysis

Hook cryptographic methods and analyze the keys that are being used. Monitor file system access while cryptographic operations are being performed to assess where key material is written to or read from.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0081

---
masvs_v1_id:
- MSTG-CODE-1
masvs_v2_id:
- MASVS-RESILIENCE-2
platform: ios
title: Making Sure that the App Is Properly Signed
masvs_v1_levels:
- R
profiles: [R]
covered_by: [MASTG-TEST-0220]
status: deprecated
deprecation_note: New version available in MASTG V2
---

## Overview

## Static Analysis

You have to ensure that the app is [using the latest code signature format](https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format). You can retrieve the signing certificate information from the application's .app file with @MASTG-TOOL-0114. Codesign is used to create, check, and display code signatures, as well as inquire into the dynamic status of signed code in the system.

After you get the application's IPA file, re-save it as a ZIP file and decompress the ZIP file. Navigate to the Payload directory, where the application's .app file will be.

Execute the following `codesign` command to display the signing information:

```bash
$ codesign -dvvv YOURAPP.app
Executable=/Users/Documents/YOURAPP/Payload/YOURAPP.app/YOURNAME
Identifier=com.example.example
Format=app bundle with Mach-O universal (armv7 arm64)
CodeDirectory v=20200 size=154808 flags=0x0(none) hashes=4830+5 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=455758418a5f6a878bb8fdb709ccfca52c0b5b9e
CandidateCDHash sha256=fd44efd7d03fb03563b90037f92b6ffff3270c46
Hash choices=sha1,sha256
CDHash=fd44efd7d03fb03563b90037f92b6ffff3270c46
Signature size=4678
Authority=iPhone Distribution: Example Ltd
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=4 Aug 2017, 12:42:52
Info.plist entries=66
TeamIdentifier=8LAMR92KJ8
Sealed Resources version=2 rules=12 files=1410
Internal requirements count=1 size=176
```

There are various ways to distribute your app as described at [the Apple documentation](https://developer.apple.com/business/distribute/ "Apple Business"), which include using the App Store or via Apple Business Manager for custom or in-house distribution. In case of an in-house distribution scheme, make sure that no ad hoc certificates are used when the app is signed for distribution.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0091

---
masvs_v1_id:
- MSTG-RESILIENCE-4
masvs_v2_id:
- MASVS-RESILIENCE-4
platform: ios
title: Testing Reverse Engineering Tools Detection
masvs_v1_levels:
- R
profiles: [R]
---

## Overview

Launch the app with various reverse engineering tools and frameworks installed on your test device, such as @MASTG-TOOL-0031, @MASTG-TOOL-0139, or @MASTG-TOOL-0066.

The app should respond in some way to the presence of those tools. For example by:

- Alerting the user and asking for accepting liability.
- Preventing execution by gracefully terminating.
- Securely wiping any sensitive data stored on the device.
- Reporting to a backend server, e.g, for fraud detection.

Next, work on bypassing the detection of the reverse engineering tools and answer the following questions:

- Can the mechanisms be bypassed trivially (e.g., by hooking a single API function)?
- How difficult is identifying the detection code via static and dynamic analysis?
- Did you need to write custom code to disable the defenses? How much time did you need?
- What is your assessment of the difficulty of bypassing the mechanisms?
OWASP Mobile Application Security Testing Guide: MASTG TEST 0088

---
masvs_v1_id:
- MSTG-RESILIENCE-1
masvs_v2_id:
- MASVS-RESILIENCE-1
platform: ios
title: Testing Jailbreak Detection
masvs_v1_levels:
- R
profiles: [R]
status: deprecated
covered_by: [MASTG-TEST-0240, MASTG-TEST-0241]
deprecation_note: New version available in MASTG V2
---

## Overview

To test for jailbreak detection install the app on a jailbroken device.

**Launch the app and see what happens:**

If it implements jailbreak detection, you might notice one of the following things:

- The app crashes and closes immediately, without any notification.
- A pop-up window indicates that the app won't run on a jailbroken device.

Note that crashes might be an indicator of jailbreak detection but the app may be crashing for any other reasons, e.g. it may have a bug. We recommend to test the app on non-jailbroken device first, especially when you're testing preproduction versions.

**Launch the app and try to bypass Jailbreak Detection using an automated tool:**

If it implements jailbreak detection, you might be able to see indicators of that in the output of the tool. See section ["Automated Jailbreak Detection Bypass"](../../../Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md#automated-jailbreak-detection-bypass).

**Reverse Engineer the app:**

The app might be using techniques that are not implemented in the automated tools that you've used. If that's the case you must reverse engineer the app to find proofs. See section ["Manual Jailbreak Detection Bypass"](../../../Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md#manual-jailbreak-detection-bypass).
OWASP Mobile Application Security Testing Guide: MASTG TEST 0092

---
masvs_v1_id:
- MSTG-RESILIENCE-5
masvs_v2_id:
- MASVS-RESILIENCE-1
platform: ios
title: Testing Emulator Detection
masvs_v1_levels:
- R
profiles: [R]
---

## Overview

In order to test for emulator detection you can try to run the app on different emulators as indicated in section ["Emulator Detection"](../../../Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md#emulator-detection) and see what happens.

The app should respond in some way. For example by:

- Alerting the user and asking for accepting liability.
- Preventing execution by gracefully terminating.
- Reporting to a backend server, e.g, for fraud detection.

You can also reverse engineer the app using ideas for strings and methods from section ["Emulator Detection"](../../../Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md#emulator-detection).

Next, work on bypassing this detection and answer the following questions:

- Can the mechanisms be bypassed trivially (e.g., by hooking a single API function)?
- How difficult is identifying the detection code via static and dynamic analysis?
- Did you need to write custom code to disable the defenses? How much time did you need?
- What is your assessment of the difficulty of bypassing the mechanisms?
OWASP Mobile Application Security Testing Guide: MASTG TEST 0089

---
masvs_v1_id:
- MSTG-RESILIENCE-2
masvs_v2_id:
- MASVS-RESILIENCE-4
platform: ios
title: Testing Anti-Debugging Detection
masvs_v1_levels:
- R
profiles: [R]
---

## Overview

In order to test for anti-debugging detection you can try to attach a debugger to the app and see what happens.

The app should respond in some way. For example by:

- Alerting the user and asking for accepting liability.
- Preventing execution by gracefully terminating.
- Securely wiping any sensitive data stored on the device.
- Reporting to a backend server, e.g, for fraud detection.

Try to hook or reverse engineer the app using the methods from section ["Anti-Debugging Detection"](../../../Document/0x05j-Testing-Resiliency-Against-Reverse-Engineering.md#anti-debugging).

Next, work on bypassing the detection and answer the following questions:

- Can the mechanisms be bypassed trivially (e.g., by hooking a single API function)?
- How difficult is identifying the detection code via static and dynamic analysis?
- Did you need to write custom code to disable the defenses? How much time did you need?
- What is your assessment of the difficulty of bypassing the mechanisms?
OWASP Mobile Application Security Testing Guide: MASTG TEST 0093

---
masvs_v1_id:
- MSTG-RESILIENCE-9
masvs_v2_id:
- MASVS-RESILIENCE-3
platform: ios
title: Testing Obfuscation
masvs_v1_levels:
- R
profiles: [R]
---

## Overview

Attempt to disassemble the Mach-O in the IPA and any included library files in the "Frameworks" directory (.dylib or .framework files), and perform static analysis. At the very least, the app's core functionality (i.e., the functionality meant to be obfuscated) shouldn't be easily discerned. Verify that:

- meaningful identifiers, such as class names, method names, and variable names, have been discarded.
- string resources and strings in binaries are encrypted.
- code and data related to the protected functionality is encrypted, packed, or otherwise concealed.

For a more detailed assessment, you need a detailed understanding of the relevant threats and the obfuscation methods used.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0090

---
masvs_v1_id:
- MSTG-RESILIENCE-3
- MSTG-RESILIENCE-11
masvs_v2_id:
- MASVS-RESILIENCE-2
platform: ios
title: Testing File Integrity Checks
masvs_v1_levels:
- R
profiles: [R]
---

## Overview

**Application Source Code Integrity Checks:**

Run the app on the device in an unmodified state and make sure that everything works. Then apply some patches to the executable (e.g. see @MASTG-TECH-0090), re-sign the app (@MASTG-TECH-0092), and run it.

The app should respond in some way. For example by:

- Alerting the user and asking for accepting liability.
- Preventing execution by gracefully terminating.
- Securely wiping any sensitive data stored on the device.
- Reporting to a backend server, e.g, for fraud detection.

Work on bypassing the defenses and answer the following questions:

- Can the mechanisms be bypassed trivially (e.g., by hooking a single API function)?
- How difficult is identifying the detection code via static and dynamic analysis?
- Did you need to write custom code to disable the defenses? How much time did you need?
- What is your assessment of the difficulty of bypassing the mechanisms?

**File Storage Integrity Checks:**

Go to the app data directories as indicated in @MASTG-TECH-0059 and modify some files.

Next, work on bypassing the defenses and answer the following questions:

- Can the mechanisms be bypassed trivially (e.g., by changing the contents of a file or a key-value pair)?
- How difficult is obtaining the HMAC key or the asymmetric private key?
- Did you need to write custom code to disable the defenses? How much time did you need?
- What is your assessment of the difficulty of bypassing the mechanisms?
OWASP Mobile Application Security Testing Guide: MASTG TEST 0082

---
masvs_v1_id:
- MSTG-CODE-2
masvs_v2_id:
- MASVS-RESILIENCE-4
platform: ios
title: Testing whether the App is Debuggable
masvs_v1_levels:
- R
profiles: [R]
status: deprecated
covered_by: [MASTG-TEST-0261]
deprecation_note: New version available in MASTG V2
---

## Overview

## Static Analysis

Extract the entitlements from the app (@MASTG-TECH-0111) and check the value of the `get-task-allow` key. If it is set to `true`, the app is debuggable.

```bash
$ ldid -e iGoat-Swift.app/iGoat-Swift
```

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>application-identifier</key>
    <string>TNAJ496RHB.OWASP.iGoat-Swift</string>
    <key>com.apple.developer.team-identifier</key>
    <string>TNAJ496RHB</string>
    <key>get-task-allow</key>
    <true/>
    <key>keychain-access-groups</key>
    <array>
        <string>TNAJ496RHB.OWASP.iGoat-Swift</string>
    </array>
</dict>
</plist>
```

## Dynamic Analysis

Check whether you can attach a debugger directly, as explained in @MASTG-TECH-0084.

Note: if the application is equipped with anti-reverse engineering controls, then the debugger can be detected and stopped.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0083

---
masvs_v1_id:
- MSTG-CODE-3
masvs_v2_id:
- MASVS-RESILIENCE-3
platform: ios
title: Testing for Debugging Symbols
masvs_v1_levels:
- R
profiles: [R]
covered_by: [MASTG-TEST-0219]
status: deprecated
deprecation_note: New version available in MASTG V2
---

## Overview

## Static Analysis

To verify the existence of debug symbols you can use objdump from [binutils](https://www.gnu.org/s/binutils/ "Binutils") or [llvm-objdump](https://llvm.org/docs/CommandGuide/llvm-objdump.html "llvm-objdump") to inspect all of the app binaries.

In the following snippet we run objdump over `TargetApp` (the iOS main app executable) to show the typical output of a binary containing debug symbols which are marked with the `d` (debug) flag. Check the [objdump man page](https://www.unix.com/man-page/osx/1/objdump/ "objdump man page") for information about various other symbol flag characters.

```bash
$ objdump --syms TargetApp
[PII_REDACTED]007dc8 l    d  *UND* -[ViewController handleSubmitButton:][PII_REDACTED]00809c l    d  *UND* -[ViewController touchesBegan:withEvent:]
[PII_REDACTED] l    d  *UND* -[ViewController viewDidLoad]
...[PII_REDACTED]00916c l    d  *UND* _disable_gdb[PII_REDACTED]0091d8 l    d  *UND* _detect_injected_dylds[PII_REDACTED]0092a4 l    d  *UND* _isDebugged
...
```

To prevent the inclusion of debug symbols, set `Strip Debug Symbols During Copy` to `YES` via the XCode project's build settings. Stripping debugging symbols will not only reduce the size of the binary but also increase the difficulty of reverse engineering.

## Dynamic Analysis

Dynamic analysis is not applicable for finding debugging symbols.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0066

---
masvs_v1_id:
- MSTG-NETWORK-2
masvs_v2_id:
- MASVS-NETWORK-1
platform: ios
title: Testing the TLS Settings
masvs_v1_levels:
- L1
- L2
profiles: [L1, L2]
---

## Overview

Remember to [inspect the corresponding justifications](https://developer.apple.com/documentation/security/preventing_insecure_network_connections#3138036) to discard that it might be part of the app intended purpose.

It is possible to verify which ATS settings can be used when communicating to a certain endpoint. On macOS the command line utility `nscurl` can be used. A permutation of different settings will be executed and verified against the specified endpoint. If the default ATS secure connection test is passing, ATS can be used in its default secure configuration. If there are any fails in the nscurl output, please change the server side configuration of TLS to make the server side more secure, rather than weakening the configuration in ATS on the client. See the article "Identifying the Source of Blocked Connections" in the [Apple Developer Documentation](https://developer.apple.com/documentation/security/preventing_insecure_network_connections/identifying_the_source_of_blocked_connections) for more details.

Refer to section "Verifying the TLS Settings" in chapter [Testing Network Communication](../../../Document/0x04f-Testing-Network-Communication.md#verifying-the-tls-settings) for details.
OWASP Mobile Application Security Testing Guide: MASTG TEST 0057

---
masvs_v1_id:
- MSTG-STORAGE-7
masvs_v2_id:
- MASVS-PLATFORM-3
platform: ios
title: Checking for Sensitive Data Disclosed Through the User Interface
masvs_v1_levels:
- L1
- L2
profiles: [L2]
---

## Overview

## Static Analysis

A text field that masks its input can be configured in two ways:

**Storyboard**
In the iOS project's storyboard, navigate to the configuration options for the text field that takes sensitive data. Make sure that the option "Secure Text Entry" is selected. If this option is activated, dots are shown in the text field in place of the text input.

**Source Code**
If the text field is defined in the source code, make sure that the option [`isSecureTextEntry`](https://developer.apple.com/documentation/uikit/uitextinputtraits/1624427-issecuretextentry "isSecureTextEntry in Text Field") is set to "true". This option obscures the text input by showing dots.

```swift
sensitiveTextField.isSecureTextEntry = true
```

## Dynamic Analysis

To determine whether the application leaks any sensitive information to the user interface, run the application and identify components that either show such information or take it as input.

If the information is masked by, for example, asterisks or dots, the app isn't leaking data to the user interface.