Home / Attacks & tests / Business Logic Vulnerabilities
3 test cases
Business Logic Vulnerabilities
Business logic testing on mobile asks the same question as on the web — whether the application's rules hold when it is used in ways its designers did not picture — with one addition: the client is fully under the attacker's control, so any rule enforced only there is not a rule.
What an attacker is trying to achieve
The attacker wants the outcome the workflow was designed to prevent, reached through steps the application accepts. On mobile they have an advantage the web attacker lacks: they can modify the client itself, so the only constraints that hold are the ones the server applies.
Test cases
3 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
Android
The Android client can be repackaged as well as instrumented, so client-side rules can be removed permanently rather than only at runtime.
AND-BUSL-01 Bypassing Business Logic
Objective — Determine whether the workflow rules the application presents are enforced by the server, or only by the client the attacker controls.
How it is tested — Map each workflow and identify where each rule is applied: sequence, limits, entitlement, validation and pricing. Remove or invert each client-side rule by instrumenting or repackaging the application, and by modifying requests in transit, then complete the workflow. Submit steps out of order, skip steps entirely, and submit values the client would refuse. Establish for each whether the server independently refuses it.
Prerequisites — A proxy with interception; a device permitting instrumentation or repackaging; a non-production environment; the intended rules stated by the operator.
Indicators — A workflow completing with steps skipped or reordered; a value the client refuses accepted by the server; a limit enforced only on the device; pricing or entitlement decided client-side.
Coverage — MASVS-CODE-4MASVS-AUTH-1CWE-602CWE-841
Depth — Manual Requires the intended rules, since a logic defect is only visible against intent.
iOS
The iOS client is harder to repackage but just as instrumentable on a device the attacker controls, and purchase entitlement introduces a second class of client-side decision.
IOS-BUSL-01 Bypassing Business Logic
Objective — Determine whether workflow rules are enforced by the server or only by the client.
How it is tested — Map each workflow and identify where each rule is applied. Instrument the running application to remove or invert client-side checks, and modify requests in transit, then complete the workflow. Submit steps out of order, skip steps, and submit values the interface refuses. For purchase- and subscription-gated workflows, establish whether the entitlement is validated by the server or accepted from the device's own receipt.
Prerequisites — A proxy with interception; a device permitting instrumentation; a non-production environment; the intended rules stated by the operator.
Indicators — A workflow completing with steps skipped; a value the interface refuses accepted by the server; a receipt accepted without server validation; a limit enforced only on the device.
Coverage — MASVS-CODE-4MASVS-AUTH-1CWE-602CWE-841
Depth — Manual Requires the intended rules and a device on which the client can be instrumented.
IOS-BUSL-02 Bypassing Controller Hierarchy
Objective — Determine whether the application's navigation hierarchy is a security boundary, by reaching controllers directly rather than through the sequence that normally presents them.
How it is tested — Recover the controller structure from the decrypted binary and identify which are presented only after a gate — authentication, a purchase, an approval. Instrument the running application to present each directly, and use incoming links where a controller is addressable that way. Establish whether the controller verifies its own preconditions or assumes them from the navigation that normally precedes it.
Prerequisites — The decrypted binary; a device permitting instrumentation; the list of gated controllers; a proxy to observe what the server is asked.
Indicators — A gated controller presented directly and functioning; data loaded into it without the gate being satisfied; the server serving requests the controller issues out of sequence.
Coverage — MASVS-AUTH-2MASVS-PLATFORM-1CWE-841CWE-287
Depth — Manual Requires instrumenting presentation, which is specific to the application's own structure.
What we need from you
A proxy with interception; a device permitting instrumentation of the running application; accounts at each role involved in a workflow; a non-production environment where transactions may be completed and reversed; and the operator's statement of what each workflow is supposed to enforce.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- MASVS-CODE-4 — The app validates and sanitizes all untrusted inputs.
- MASVS-AUTH-1 — The app uses secure authentication and authorization protocols and follows the relevant best practices.
- CWE-602 — Client-Side Enforcement of Server-Side Security
- CWE-841 — Improper Enforcement of Behavioral Workflow
- MASVS-AUTH-2 — The app performs local authentication securely according to the platform best practices.
- MASVS-PLATFORM-1 — The app uses IPC mechanisms securely.
- CWE-287 — Improper Authentication
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.