Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MASTG-TEST-0080 #3048

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

MASTG-TEST-0080 #3048

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
28 changes: 28 additions & 0 deletions tests-beta/android/MASVS-CODE/MASTG-TEST-0x80-1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
---
Title: Testing Enforced Updating
ID: MASTG-TEST-0x80-1
Link: https://mas.owasp.org/MASTG/tests/android/MASVS-CODE/MASTG-TEST-0080/
Platform: android
MASVS v1: ['MSTG-ARCH-9']
MASVS v2: ['MASVS-CODE-2']
type: [dynamic]
---

## 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.

## 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.
3. Interact with the backend to see if different version numbers trigger different responses.
4. If a different response can be identified, modify an active request with the old version number to examine how the application reacts to the new backend response.

## Observation

The server responds differently to older versions.

## Evaluation

The test case fails if the application does not send its version information to the backend.
26 changes: 26 additions & 0 deletions tests-beta/android/MASVS-CODE/MASTG-TEST-0x80.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
---
Title: Testing Enforced Updating
ID: MASTG-TEST-0x80
Link: https://mas.owasp.org/MASTG/tests/android/MASVS-CODE/MASTG-TEST-0080/
Platform: android
MASVS v1: ['MSTG-ARCH-9']
MASVS v2: ['MASVS-CODE-2']
type: [static]
---

## 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.

## 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.
Copy link

Choose a reason for hiding this comment

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

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

  1. 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.


## 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.

## 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.
28 changes: 28 additions & 0 deletions tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
---
Title: Testing Enforced Updating
ID: MASTG-TEST-0x80
Link: https://mas.owasp.org/MASTG/tests/android/MASVS-CODE/MASTG-TEST-0080/
Platform: ios
MASVS v1: ['MSTG-ARCH-9']
MASVS v2: ['MASVS-CODE-2']
type: [dynamic]
---

## 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.

## Steps

1. Obtain a MitM position between the application and its backend (see @MASTG-TECH-0063).
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.
3. Interact with the backend to see if different version numbers trigger different responses.
4. If a different response can be identified, modify an active request with the old version number to examine how the application reacts to the new backend response.

## Observation

The server responds differently to older versions.

## Evaluation

The test case fails if the application does not send its version information to the backend.
26 changes: 26 additions & 0 deletions tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
---
Title: Testing Enforced Updating
ID: MASTG-TEST-0x80
Link: https://mas.owasp.org/MASTG/tests/android/MASVS-CODE/MASTG-TEST-0080/
Platform: ios
MASVS v1: ['MSTG-ARCH-9']
MASVS v2: ['MASVS-CODE-2']
type: [static]
---

## 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.

## 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.
Copy link

Choose a reason for hiding this comment

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

Same as above. Regardless of my comment, the note you are using is a bit confusing to me. Otherwise, I like very much the rest.


## 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.

## 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.
Copy link

Choose a reason for hiding this comment

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

I feel the evaluation contradict the observation a bit.

Loading