deardaniel/secdata-raw huggingface dataset:
OWASP Mobile Application Security Testing Guide: MASTG TOOL 0048

---
title: dsdump
platform: ios
source: https://github.com/DerekSelander/dsdump
---

dsdump is a tool to dump Objective-C classes and Swift type descriptors (classes, structs, enums). It only supports Swift version 5 or higher and does not support ARM 32-bit binaries.

The following example shows how you can dump Objective-C classes and Swift type descriptors of an iOS application.

First verify if the app's main binary is a FAT binary containing ARM64:

```bash
$ otool -hv [APP_MAIN_BINARY_FILE]
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
   MH_MAGIC     ARM         V7  0x00     EXECUTE    39       5016   NOUNDEFS DYLDLINK TWOLEVEL PIE
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64   ARM64        ALL  0x00     EXECUTE    38       5728   NOUNDEFS DYLDLINK TWOLEVEL PIE
```

If yes, then we specify the "--arch" parameter to "arm64", otherwise it is not needed if the binary only contains an ARM64 binary.

```bash
# Dump the Objective-C classes to a temporary file
$ dsdump --objc --color --verbose=5 --arch arm64 --defined [APP_MAIN_BINARY_FILE] > /tmp/OBJC.txt

# Dump the Swift type descriptors to a temporary file if the app is implemented in Swift
$ dsdump --swift --color --verbose=5 --arch arm64 --defined [APP_MAIN_BINARY_FILE] > /tmp/SWIFT.txt
```

You can find more information about the inner workings of dsdump and how to programmatically inspect a Mach-O binary to display the compiled Swift types and Objective-C classes in [this article](https://derekselander.github.io/dsdump/ "Building a class-dump in 2020").
OWASP Mobile Application Security Testing Guide: MASTG TOOL 0117

---
title: fastlane
platform: ios
source: https://github.com/fastlane/fastlane
hosts: [macOS, linux, windows]
alternatives:
- MASTG-TOOL-0114
- MASTG-TOOL-0102
---

fastlane is a tool for iOS and Android developers to automate tasks like dealing with provisioning profiles, and releasing mobile apps. On iOS, it's especially useful to resign IPA files with your Xcode provisioning profile.

fastlane can be installed via brew (`brew install fastlane`).
OWASP Mobile Application Security Testing Guide: MASTG TOOL 0127

---
title: AppSync Unified
platform: ios
hosts: [ios]
source: https://github.com/akemin-dayo/AppSync
---

AppSync Unified disables various IPA signature verifications on jailbroken iOS devices, allowing you to install IPA files with missing or incorrect signatures. AppSync Unified does not require any configuration after installation and does not offer a direct way to install IPA files either.

!!! warning

    You can normally install AppSync Unified from the `https://cydia.akemi.ai/` repository by adding it to the package manager on your iOS device. However, as this repository is not always available, you can alternatively download the .deb file from the [releases page](https://github.com/akemin-dayo/AppSync/releases/) and install it using `dpkg -i` on the device.
OWASP Mobile Application Security Testing Guide: MASTG TOOL 0073

---
title: radare2 (iOS)
platform: ios
source: https://github.com/radare/radare2
---

Radare2 is a complete framework for reverse-engineering and analyzing binaries. The installation instructions can be found in the GitHub repository. To learn more on radare2 you may want to read the [official radare2 book](https://book.rada.re/ "Radare2 book").

Learn more:

- [r2wiki](https://r2wiki.readthedocs.io/en/latest/analysis/ios/)
- [Loading iOS binaries to radare2](https://radareorg.github.io/blog/posts/loading-ios-binaries/ "radare2 - Loading iOS Binaries")
- [GitHub radare2 Docs - iOS](https://github.com/radareorg/radare2/blob/master/doc/ios.md "radare2 - iOS")
OWASP Mobile Application Security Verification Standard: 06 MASVS CRYPTO

# MASVS-CRYPTO: Cryptography

Cryptography is essential for mobile apps because mobile devices are highly portable and can be easily lost or stolen. This means that an attacker who gains physical access to a device can potentially access all the sensitive data stored on it, including passwords, financial information, and personally identifiable information. Cryptography provides a means of protecting this sensitive data by encrypting it so that it cannot be easily read or accessed by an unauthorized user.

The purpose of the controls in this category is to ensure that the verified app uses cryptography according to industry best practices, which are typically defined in external standards such as [NIST.SP.800-175B](https://csrc.nist.gov/publications/detail/sp/800-175b/rev-1/final) and [NIST.SP.800-57](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final). This category also focuses on the management of cryptographic keys throughout their lifecycle, including key generation, storage, and protection. Poor key management can compromise even the strongest cryptography, so it is crucial for developers to follow the recommended best practices to ensure the security of their users' sensitive data.
OWASP Mobile Application Security Verification Standard: 05 MASVS STORAGE

# MASVS-STORAGE: Storage

Mobile applications handle a wide variety of sensitive data, such as personally identifiable information (PII), cryptographic material, secrets, and API keys, that often need to be stored locally. This sensitive data may be stored in private locations, such as the app's internal storage, or in public folders that are accessible by the user or other apps installed on the device. However, sensitive data can also be unintentionally stored or exposed to publicly accessible locations, typically as a side-effect of using certain APIs or system capabilities such as backups or logs.

This category is designed to help developers ensure that any sensitive data intentionally stored by the app is properly protected, regardless of the target location. It also covers unintentional leaks that can occur due to improper use of APIs or system capabilities.
OWASP Mobile Application Security Verification Standard: 07 MASVS AUTH

# MASVS-AUTH: Authentication and Authorization

Authentication and authorization are essential components of most mobile apps, especially those that connect to a remote service. These mechanisms provide an added layer of security and help prevent unauthorized access to sensitive user data. Although the enforcement of these mechanisms must be on the remote endpoint, it is equally important for the app to follow relevant best practices to ensure the secure use of the involved protocols.

Mobile apps often use different forms of authentication, such as biometrics, PIN, or multi-factor authentication code generators, to validate user identity. These mechanisms must be implemented correctly to ensure their effectiveness in preventing unauthorized access. Additionally, some apps may rely solely on local app authentication and may not have a remote endpoint. In such cases, it is critical to ensure that local authentication mechanisms are secure and implemented following industry best practices.

The controls in this category aim to ensure that the app implements authentication and authorization mechanisms securely, protecting sensitive user information and preventing unauthorized access. It is important to note that the security of the remote endpoint should also be validated using industry standards such as the [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/).
OWASP Mobile Application Security Verification Standard: 12 MASVS PRIVACY

# MASVS-PRIVACY: Privacy

The main goal of MASVS-PRIVACY is to provide a **baseline for user privacy**. It is not intended to cover all aspects of user privacy, especially when other standards and regulations such as ENISA or the GDPR already do that. We focus on the app itself, looking at what can be tested using information that's publicly available or found within the app through methods like static or dynamic analysis.

While some associated tests can be automated, others necessitate manual intervention due to the nuanced nature of privacy. For example, if an app collects data that it didn't mention in the app store or its privacy policy, it takes careful manual checking to spot this.

> **Note on "Data Collection and Sharing"**:For the MASTG tests, we treat "Collect" and "Share" in a unified manner. This means that whether the app is sending data to another server or transferring it to another app on the device, we view it as data that's potentially leaving the user's control. Validating what happens to the data on remote endpoints is challenging and often not feasible due to access restrictions and the dynamic nature of server-side operations. Therefore, this issue is outside of the scope of the MASVS.

**IMPORTANT DISCLAIMER**:

MASVS-PRIVACY is not intended to serve as an exhaustive or exclusive reference. While it provides valuable guidance on app-centric privacy considerations, it should never replace comprehensive assessments, such as a Data Protection Impact Assessment (DPIA) mandated by the General Data Protection Regulation (GDPR) or other pertinent legal and regulatory frameworks. Stakeholders are strongly advised to undertake a holistic approach to privacy, integrating MASVS-PRIVACY insights with broader assessments to ensure comprehensive data protection compliance. Given the specialized nature of privacy regulations and the complexity of data protection, these assessments are best conducted by privacy experts rather than security experts.
OWASP Mobile Application Security Verification Standard: metadata

---
# This is the main metadata file.
# Variables below can be overwritten by the local metadata
# file (e.g. Document-fr/metadata.md)

# Custom Template variables (cover, first page, etc.)
version: 'SNAPSHOT' # this will overridden at build time
languagetext: ''

mainfont: 'DejaVu Sans'
sansfont: 'DejaVu Sans'
monofont: 'DejaVu Sans Mono'

# General variables
toc: true
toc-depth: 2
# numbersections: true
# secnumdepth: 2
linkcolor: blue

# Language variables
lang: 'en'

# Latex variables

# Eisvogel Latex variables
# https://github.com/Wandmalfarbe/pandoc-latex-template#custom-template-variables
code-block-font-size: '\tiny'

table-use-row-colors: true
geometry: "top=1cm,left=1cm,right=2cm,bottom=4cm"
---
OWASP Mobile Application Security Verification Standard: 10 MASVS CODE

# MASVS-CODE: Code Quality

Mobile apps have many data entry points, including the UI, IPC, network, and file system, which might receive data that has been inadvertently modified by untrusted actors. By treating this data as untrusted input and properly verifying and sanitizing it before use, developers can prevent classical injection attacks, such as SQL injection, XSS, or insecure deserialization. However, other common coding vulnerabilities, such as memory corruption flaws, are hard to detect in penetration testing but easy to prevent with secure architecture and coding practices. Developers should follow best practices such as the [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org/model/) and [NIST.SP.800-218 Secure Software Development Framework (SSDF)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf) to avoid introducing these flaws in the first place.

This category covers coding vulnerabilities that arise from external sources such as app data entry points, the OS, and third-party software components. Developers should verify and sanitize all incoming data to prevent injection attacks and bypass of security checks. They should also enforce app updates and ensure that the app runs up-to-date platforms to protect users from known vulnerabilities.
OWASP Mobile Application Security Verification Standard: index

---
hide:
  - toc
---

# OWASP MASVS

<img src="../assets/masvs_cover.png" align="right" style="border-radius: 3px; margin: 3em; box-shadow: rgba(149, 157, 165, 0.2) 0px 8px 24px;" width="350px" >

<a href="https://github.com/OWASP/masvs/">:material-github: GitHub Repo</a>

The **OWASP MASVS (Mobile Application Security Verification Standard)** is the industry standard for mobile app security. It can be used by mobile software architects and developers seeking to develop secure mobile applications, as well as security testers to ensure completeness and consistency of test results.

To complement the MASVS, the OWASP MAS project also provides the [OWASP Mobile Application Security Testing Guide (MASTG)](https://mas.owasp.org/MASTG), the [OWASP Mobile Application Security Weakness Enumeration (MASWE)](https://mas.owasp.org/MASWE) and the [OWASP MAS Checklist](https://mas.owasp.org/checklists) which together are the perfect companion for verifying the controls listed in the OWASP MASVS and demonstrate compliance.

<br>

<button class="mas-button" onclick="window.location.href='https://github.com/OWASP/masvs/releases/latest/download/OWASP_MASVS.pdf';"> Download the MASVS</button>

<br>

## The MASVS Control Groups

The standard is divided into various groups of controls, labeled **MASVS-XXXXX**, that represent the most critical areas of the mobile attack surface:

- **MASVS-STORAGE**: Secure storage of sensitive data on a device (data-at-rest).
- **MASVS-CRYPTO**: Cryptographic functionality used to protect sensitive data.
- **MASVS-AUTH**: Authentication and authorization mechanisms used by the mobile app.
- **MASVS-NETWORK**: Secure network communication between the mobile app and remote endpoints (data-in-transit).
- **MASVS-PLATFORM**: Secure interaction with the underlying mobile platform and other installed apps.
- **MASVS-CODE**: Security best practices for data processing and keeping the app up-to-date.
- **MASVS-RESILIENCE**: Resilience to reverse engineering and tampering attempts.
- **MASVS-PRIVACY**: Privacy controls to protect user privacy.

!!! warning "MAS Testing Profiles"
    **Starting on v2.0.0 the MASVS does not contain "verification levels"**. The MAS project has traditionally provided three verification levels (L1, L2 and R), which were revisited during the MASVS refactoring in 2023, and have been reworked as ["MAS Testing Profiles"](https://docs.google.com/document/d/1paz7dxKXHzAC9MN7Mnln1JiZwBNyg7Gs364AJ6KudEs/edit?usp=sharing) and moved over to the [OWASP MASWE](https://mas.owasp.org/MASWE/).
    <br><br>
    While we move things around and as a temporary measure, the [OWASP MAS Checklist](https://mas.owasp.org/checklists) will still contain the old verification levels, associated with the current MASTG v1 tests. However, note that the levels will be completely reworked and reassigned to the corresponding MASWE weaknesses.

<br><br>
OWASP Mobile Application Security Verification Standard: 08 MASVS NETWORK

# MASVS-NETWORK: Network Communication

Secure networking is a critical aspect of mobile app security, particularly for apps that communicate over the network. In order to ensure the confidentiality and integrity of data in transit, developers typically rely on encryption and authentication of the remote endpoint, such as through the use of TLS. However, there are numerous ways in which a developer may accidentally disable the platform secure defaults or bypass them entirely by utilizing low-level APIs or third-party libraries.

This category is designed to ensure that the mobile app sets up secure connections under any circumstances. Specifically, it focuses on verifying that the app establishes a secure, encrypted channel for network communication. Additionally, this category covers situations where a developer may choose to trust only specific Certificate Authorities (CAs), which is commonly referred to as certificate pinning or public key pinning.
OWASP Mobile Application Security Verification Standard: 09 MASVS PLATFORM

# MASVS-PLATFORM: Platform Interaction

The security of mobile apps heavily depends on their interaction with the mobile platform, which often involves exposing data or functionality intentionally through the use of platform-provided inter-process communication (IPC) mechanisms and WebViews to enhance the user experience. However, these mechanisms can also be exploited by attackers or other installed apps, potentially compromising the app's security.

Furthermore, sensitive data, such as passwords, credit card details, and one-time passwords in notifications, is often displayed in the app's user interface. It is essential to ensure that this data is not unintentionally leaked through platform mechanisms such as auto-generated screenshots or accidental disclosure through shoulder surfing or device sharing.

This category comprises controls that ensure the app's interactions with the mobile platform occur securely. These controls cover the secure use of platform-provided IPC mechanisms, WebView configurations to prevent sensitive data leakage and functionality exposure, and secure display of sensitive data in the app's user interface. By implementing these controls, mobile app developers can safeguard sensitive user information and prevent unauthorized access by attackers.
OWASP Mobile Application Security Verification Standard: MASVS NETWORK 2

# MASVS-NETWORK-2

## Control

The app performs identity pinning for all remote endpoints under the developer's control.

## Description

Instead of trusting all the default root CAs of the framework or device, this control will make sure that only very specific CAs are trusted. This practice is typically called certificate pinning or public key pinning.
OWASP Mobile Application Security Verification Standard: MASVS AUTH 2

# MASVS-AUTH-2

## Control

The app performs local authentication securely according to the platform best practices.

## Description

Many apps allow users to authenticate via biometrics or a local PIN code. These authentication mechanisms need to be correctly implemented. Additionally, some apps might not have a remote endpoint, and rely fully on local app authentication.
OWASP Mobile Application Security Verification Standard: MASVS NETWORK 1

# MASVS-NETWORK-1

## Control

The app secures all network traffic according to the current best practices.

## Description

Ensuring data privacy and integrity of any data in transit is critical for any app that communicates over the network. This is typically done by encrypting data and authenticating the remote endpoint, as TLS does. However, there are many ways for a developer to disable the platform secure defaults, or bypass them completely by using low-level APIs or third-party libraries. This control ensures that the app is in fact setting up secure connections in any situation.
OWASP Mobile Application Security Verification Standard: MASVS CODE 1

# MASVS-CODE-1

## Control

The app requires an up-to-date platform version.

## Description

Every release of the mobile OS includes security patches and new security features. By supporting older versions, apps stay vulnerable to well-known threats. This control ensures that the app is running on an up-to-date platform version so that users have the latest security protections.
OWASP Mobile Application Security Verification Standard: MASVS STORAGE 2

# MASVS-STORAGE-2

## Control

The app prevents leakage of sensitive data.

## Description

There are cases when sensitive data is unintentionally stored or exposed to publicly accessible locations; typically as a side-effect of using certain APIs, system capabilities such as backups or logs. This control covers this kind of unintentional leaks where the developer actually has a way to prevent it.
OWASP Mobile Application Security Verification Standard: MASVS PRIVACY 1

# MASVS-PRIVACY-1

## Control

The app minimizes access to sensitive data and resources.

## Description

Apps should only request access to the data they absolutely need for their functionality and always with informed consent from the user. This control ensures that apps practice data minimization and restricts access control, reducing the potential impact of data breaches or leaks.

Furthermore, apps should share data with third parties only when necessary, and this should include enforcing that third-party SDKs operate based on user consent, not by default or without it. Apps should prevent third-party SDKs from ignoring consent signals or from collecting data before consent is confirmed.

Additionally, apps should be aware of the 'supply chain' of SDKs they incorporate, ensuring that no data is unnecessarily passed down their chain of dependencies. This end-to-end responsibility for data aligns with recent SBOM regulatory requirements, making apps more accountable for their data practices.
OWASP Mobile Application Security Verification Standard: MASVS RESILIENCE 2

# MASVS-RESILIENCE-2

## Control

The app implements anti-tampering mechanisms.

## Description

Apps run on a user-controlled device, and without proper protections it's relatively easy to run a modified version locally (e.g. to cheat in a game, or enable premium features without paying), or upload a backdoored version of it to third-party app stores. This control tries to ensure the integrity of the app's intended functionality by preventing modifications to the original code and resources.
OWASP Mobile Application Security Verification Standard: MASVS AUTH 3

# MASVS-AUTH-3

## Control

The app secures sensitive operations with additional authentication.

## Description

Some additional form of authentication is often desirable for sensitive actions inside the app. This can be done in different ways (biometric, pin, MFA code generator, email, deep links, etc) and they all need to be implemented securely.
OWASP Mobile Application Security Verification Standard: MASVS PLATFORM 2

# MASVS-PLATFORM-2

## Control

The app uses WebViews securely.

## Description

WebViews are typically used by apps that have a need for increased control over the UI. This control ensures that WebViews are configured securely to prevent sensitive data leakage as well as sensitive functionality exposure (e.g. via JavaScript bridges to native code).
OWASP Mobile Application Security Verification Standard: MASVS CRYPTO 1

# MASVS-CRYPTO-1

## Control

The app employs current strong cryptography and uses it according to industry best practices.

## Description

Cryptography plays an especially important role in securing the user's data - even more so in a mobile environment, where attackers having physical access to the user's device is a likely scenario. This control covers general cryptography best practices, which are typically defined in external standards.
OWASP Mobile Application Security Verification Standard: MASVS CRYPTO 2

# MASVS-CRYPTO-2

## Control

The app performs key management according to industry best practices.

## Description

Even the strongest cryptography would be compromised by poor key management. This control covers the management of cryptographic keys throughout their lifecycle, including key generation, storage and protection.
OWASP Mobile Application Security Verification Standard: MASVS STORAGE 1

# MASVS-STORAGE-1

## Control

The app securely stores sensitive data.

## Description

Apps handle sensitive data coming from many sources such as the user, the backend, system services or other apps on the device and usually need to store it locally. The storage locations may be private to the app (e.g. its internal storage) or be public and therefore accessible by the user or other installed apps (e.g. public folders such as Downloads). This control ensures that any sensitive data that is intentionally stored by the app is properly protected independently of the target location.
OWASP Mobile Application Security Verification Standard: MASVS AUTH 1

# MASVS-AUTH-1

## Control

The app uses secure authentication and authorization protocols and follows the relevant best practices.

## Description

Most apps connecting to a remote endpoint require user authentication and also enforce some kind of authorization. While the enforcement of these mechanisms must be on the remote endpoint, the apps also have to ensure that it follows all the relevant best practices to ensure a secure use of the involved protocols.