Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 31 additions & 6 deletions weaknesses/MASVS-RESILIENCE/MASWE-0100.md
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Original file line number Diff line number Diff line change
Expand Up @@ -19,12 +19,37 @@ refs:
- https://github.com/iansampson/AppAttest
- https://github.com/firebase/firebase-ios-sdk/blob/v8.15.0/FirebaseAppCheck/Sources/AppAttestProvider/DCAppAttestService%2BFIRAppAttestService.h
- https://blog.restlesslabs.com/john/ios-app-attest
draft:
description: The app doesn't use App Attestation APIs, such as Google Play Integrity API, iOS DeviceCheck API,so the backend cannot ensure requests originate from a genuine app binary (CWE-693). This exposes the app to tampering, fraud, replay attacks, and unauthorized use of premium features.
topics:
- detection in place
- Effectiveness Assessment (e.g. bypassing the detection)
status: placeholder
status: new

---

## Overview

Device attestation is a security mechanism that allows a mobile application or backend service to verify the integrity and trustworthiness of the environment in which the application is running. It provides cryptographic proof that the device has not been tampered with.

In this context it need to be differentiated between attestation and assertion:

- **Attestation** - Occurs during the registration phase, when your app initially connects to your server.
- **Assertion** - Is used during subsequent interactions, whenever the app needs to authenticate again or make further requests.

If device attestation is used also app attestation should be considered to confirm that the application instance is genuine. App attestation provides cryptographic proof that the app instance is trustworthy and genuine.

Attestation can be performed locally on the device or remotely through a backend service. Local checks rely on the application itself to verify system integrity, but these can be bypassed by attackers with sufficient control over the environment (e.g., through hooking and modifying the app during runtime). Server-side attestation shifts the verification to a backend service, which can make it harder for attackers to tamper with the verification logic.

To summarize:

- **Device attestation** confirms the environment is trustworthy.
- **App attestation** confirms the app instance is trustworthy.

If the app doesn't use attestation APIs or services the backend cannot ensure requests originate from a genuine app binary and from a trusted platform.
Comment on lines +39 to +44
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd not "summarize" here, prefer to make it more explicit above, e.g., using the bullet points.


## Impact

- **Abuse of Functionality**: Backend systems cannot distinguish between legitimate and tampered apps, enabling abuse such as fake account creation, fraud or unauthorized use of premium features.
- **App Executed in outdated Environment**: Users may run the application on outdated platforms that have no security patches installed.
- **App Executed in untrusted Environment**: Attackers may run the application on rooted or jailbroken devices without detection.

## Modes of Introduction

- **Weak Architecture**: The application does not include device attestation in its security model, assuming the device environment can be trusted.
- **Reliance on Weak Checks**: Instead of proper attestation, the app only performs basic root/jailbreak detection, which is easily bypassed.