Port MASTG-TEST-0080: Testing Enforced Updating (ios) and MASTG-TEST-0036: Testing Enforced Updating (android) #3048

TheDauntless · 2024-11-06T16:26:29Z

Thank you for submitting a Pull Request to the OWASP MASTG. Please make sure that:

Your contribution is written in the 2nd person (e.g. you)
Your contribution is written in an active present form for as much as possible.
You have made sure that the reference section is up to date (e.g. please add sources you have used, make sure that the references to MITRE/MASVS/etc. are up to date)
Your contribution has proper formatted markdown and/or code
Any references to website have been formatted as [TEXT](URL “NAME”)
You verified/tested the effectiveness of your contribution (e.g.: is the code really an effective remediation? Please verify it works!)

If your PR is related to an issue. Please end your PR test with the following line:
This PR closes #2988 and closes #2994

TheDauntless · 2024-11-06T16:27:28Z

The Evaluation doesn't give 100% certainty, so I don't know how to write this down. Do we add a disclaimer?

sydseter · 2024-11-06T17:12:52Z

tests-beta/android/MASVS-CODE/MASTG-TEST-0x80.md

+## Steps
+
+1. Examine the startup flow of the application. Identify if the application calls out to a backend with the application's version information included.
+2. Examine if the application can handle a specific response from the backend indicating that the application must be updated. For example, the application might evaluate the response from the backend and show a specific error message. Note that the error message can also come from the backend, so the lack of a custom error message in the application does not mean that the feature isn't implemented.


Perhaps this part should be clarified? Perhaps it could be written like this:

Examine if the application can handle a specific response from the backend indicating that the application must be updated. For example by showing or evaluating an error message retrieved from an API or the mobile application.

tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md

sydseter · 2024-11-06T17:17:14Z

tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md

+
+## Evaluation
+
+The test case fails if the application does not contain any logic to handle a forced application update. Additionally, the test case fails if the application informs the user that they must update, but the user can ignore the prompt and still use the application.


I feel the evaluation contradict the observation a bit.

ScreaMy7 · 2025-08-26T11:33:10Z

@cpholguera i can review the pull request, pls assign.

tests-beta/android/MASVS-CODE/MASTG-TEST-0x80-1.md

ScreaMy7 · 2025-09-30T13:02:31Z

tests-beta/android/MASVS-CODE/MASTG-TEST-0x80-1.md

+
+## Overview
+
+When a vulnerability is found in the app, it should be possible to force the user to update the application to continue using it.


The overview is not matching the testcase description.

ScreaMy7 · 2025-09-30T13:07:31Z

tests-beta/android/MASVS-CODE/MASTG-TEST-0x80-1.md

+## Steps
+
+1. Obtain a MitM position between the application and its backend (see @MASTG-TECH-0011).
+2. Identify if version information is sent to the backend. This can be as part of a header, the URL, a URL parameter or the HTTP body.


Test to verify if user can bypass or circumevent the update prompt by cancelling the update is missing. Also add to use older version of application.

ScreaMy7 · 2025-09-30T13:11:10Z

tests-beta/android/MASVS-CODE/MASTG-TEST-0x80-1.md

+
+## Observation
+
+The server responds differently to older versions.


Observation should be based on the demo output.

The definition of the Observation has nothing to do with the demo/s. The demos may not yet exist as is the case here.

See https://docs.google.com/document/d/1EMsVdfrDBAu0gmjWAUEs60q-fWaOmDB5oecY9d9pOlg/edit?usp=drivesdk

Observation This is the output you get after executing all steps. It serves as evidence. Examples: method trace for specific APIs, network traffic trace filtered in some way, hooking events containing sensitive data (indicating which APIs handle that data). It should start with “The output should contain …”. Example: ## Observation The output should contain a **list of locations where insecure random APIs are used**.

ScreaMy7 · 2025-09-30T13:33:48Z

tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md

+## Steps
+
+1. Examine the startup flow of the application. Identify if the application calls out to a backend with the application's version information included.
+2. Examine if the application can handle a specific response from the backend indicating that the application must be updated. For example, the application might evaluate the response from the backend and show a specific error message. Note that the error message can also come from the backend, so the lack of a custom error message in the application does not mean that the feature isn't implemented.


The described test case is a dynamic test, for static test it should be using r2.

Tests do not use any specific tools. They must link to techniques. Demos do use specific tools.

ScreaMy7 · 2025-09-30T13:36:33Z

tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md

+
+## Evaluation
+
+The test case fails if the application does not contain any logic to handle a forced application update. Additionally, the test case fails if the application informs the user that they must update, but the user can ignore the prompt and still use the application.


The evaluation should be based on demo and the result from its observations.

Not correct, see other related comments.

tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md

ScreaMy7 · 2025-09-30T13:38:52Z

tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md

+
+## Observation
+
+The application contains specific logic to handle a force-update event. The user may be able to ignore the prompt and continue using the application, or they may be unable to use the application without updating.


As explained above the observation should be based on result from demo app using decomplied binary.

Not correct, see other related comments.

tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md

…STG-TEST-0080

cpholguera · 2025-11-01T12:07:22Z

@ScreaMy7 This applies to all current and future PR reviews.

Please use the suggestions when reviewing, unless it isn't possible for some reason (for example, if a file is missing and needs to be added). This speeds up the review process for both parties.

In this case, since I have access, I went ahead and made the necessary changes myself to speed up the process even more, but the regular procedure would be to make suggestions and allow the author to review and incorporate them (unless they disagree, of course).

Thank you.

- Clarify Overview sections: include Play In-App Updates details for Android and CFBundle/version retrieval for iOS. - Expand and standardize Steps: add specific static and dynamic analysis guidance (MITM, dynamic instrumentation, tech refs). - Improve Observation: list expected artifacts (network trace, method trace), - Improve Evaluation: spell out failure criteria, and add "Additional Verification" steps for manual checks. - Normalize wording, fix typos, and align examples across Android and iOS test files.

…and StoreKit - Add iTunes Search API lookup checks and parsing (resultCount, results[0].version, results[0].trackViewUrl) to dynamic and static tests - Expand instrumentation guidance to include parsing logic, UIApplication.open, and SKStoreProductViewController - Improve observations and verification steps (include lookup stubbing/replay and iTunes lookup-related evaluation)

…okup / StoreKit details - Rewrote guidance to explain iOS has no built-in enforced-update API and outline developer responsibilities - Added App Store Lookup API example endpoint and description of how to compare versions - Documented SKStoreProductViewController and App Store URL alternatives for update UX - Mentioned common open-source libraries and linked to App Store Connect / Review Guidelines - Emphasized backend/API lifecycle considerations and testing of older app versions

…tes API; add AppUpdateManager, update modes, usage, and backend-gated flow recommendations

cpholguera · 2025-11-02T10:24:08Z

tests-beta/android/MASVS-CODE/MASTG-TEST-0x80.md

This test is also being added in https://github.com/OWASP/mastg/pull/3462/files#diff-a9d53408e3663c96701c37c093b01bd6f1a167e734915d13c6f1cdc2a6a02bf0

Let's make sure that any final content from here is added as suggestions to that PR or the test is removed from that PR and only added in this one.

cpholguera · 2025-11-02T10:35:28Z

knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0023.md

+
+Keep in mind that updating the app does not resolve vulnerabilities residing on backend systems. A secure update mechanism should complement proper API and service lifecycle management. Similarly, if users are not forced to update, test older app versions against your backend and apply API versioning and deprecation policies to maintain security and stability across all supported releases.
+
+## Google Play In‑App Updates API


Also add https://support.google.com/googleplay/android-developer/answer/13812041

First try

e6d9bfc

sydseter reviewed Nov 6, 2024

View reviewed changes

tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md Outdated Show resolved Hide resolved

sydseter reviewed Nov 6, 2024

View reviewed changes

cpholguera changed the title ~~MASTG-TEST-0080~~ Port MASTG-TEST-0080: Testing Enforced Updating (ios) Feb 24, 2025

cpholguera changed the title ~~Port MASTG-TEST-0080: Testing Enforced Updating (ios)~~ Port MASTG-TEST-0080: Testing Enforced Updating (ios) and MASTG-TEST-0036: Testing Enforced Updating (android) Feb 24, 2025

cpholguera added Android iOS MASVS-CODE MASTG Refactor labels Feb 24, 2025

cpholguera assigned ScreaMy7 Aug 26, 2025

ScreaMy7 reviewed Sep 30, 2025

View reviewed changes

TheDauntless and others added 5 commits October 1, 2025 08:07

Process some comments

31d64dc

add deprecation notes

7220338

fix new tests metadata

7d41c6c

Merge branch 'master' of https://github.com/OWASP/owasp-mastg into MA…

83e5433

…STG-TEST-0080

add L2 profile metadata

e782b90

cpholguera added 4 commits November 1, 2025 19:08

[COPILOT] Expand Enforced Updating guidance — prefer Play In‑App Upda…

087c243

…tes API; add AppUpdateManager, update modes, usage, and backend-gated flow recommendations

cpholguera reviewed Nov 2, 2025

View reviewed changes


		## Evaluation

		The test case fails if the application does not contain any logic to handle a forced application update. Additionally, the test case fails if the application informs the user that they must update, but the user can ignore the prompt and still use the application.


		## Overview

		When a vulnerability is found in the app, it should be possible to force the user to update the application to continue using it.


		## Observation

		The server responds differently to older versions.


		## Observation

		The application contains specific logic to handle a force-update event. The user may be able to ignore the prompt and continue using the application, or they may be unable to use the application without updating.


		Keep in mind that updating the app does not resolve vulnerabilities residing on backend systems. A secure update mechanism should complement proper API and service lifecycle management. Similarly, if users are not forced to update, test older app versions against your backend and apply API versioning and deprecation policies to maintain security and stability across all supported releases.

		## Google Play In‑App Updates API

Uh oh!

Port MASTG-TEST-0080: Testing Enforced Updating (ios) and MASTG-TEST-0036: Testing Enforced Updating (android) #3048

Are you sure you want to change the base?

Port MASTG-TEST-0080: Testing Enforced Updating (ios) and MASTG-TEST-0036: Testing Enforced Updating (android) #3048

Uh oh!

Conversation

TheDauntless commented Nov 6, 2024 • edited by cpholguera Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheDauntless commented Nov 6, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ScreaMy7 commented Aug 26, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cpholguera commented Nov 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

TheDauntless commented Nov 6, 2024 •

edited by cpholguera

Loading