Port MASTG-TEST-0005: Determining Whether Sensitive Data Is Shared with Third Parties via Notifications (android)

[Diolor]

This PR closes #2939

Description

Port mastg test 0005 from v1 to v2 incl. demo

TODO:

• Allocate new TEST ID
• Allocate new DEMO ID
• Profile

Note:
For the demo notification to be visible (doesn't affect test functionality), we need to grant the POST_NOTIFICATIONS permission, i.e. adb shell pm grant org.owasp.mastestapp android.permission.POST_NOTIFICATIONS (or manually). This does not affect testability. Should that be visible? ✅

[sushi2k]

Thank you for the creation of this new test case, that looks really good! The code works in the testing app, I could build it in Android Studio and the semgrep rules work too.

I made a few suggestions, please let me know what you think.

Regarding your note:

Note: For the demo notification to be visible (doesn't affect test functionality), we need to grant the POST_NOTIFICATIONS permission, i.e. adb shell pm grant org.owasp.mastestapp android.permission.POST_NOTIFICATIONS (or manually). This does not affect testability. Should that be visible?

It would make sense to point this out in the steps of the demo, in case someone wants to verify the notifications when running the app.

[sushi2k]

Including changing the file-name of the demo and test

[sushi2k]

This test ID also need to be updated.

[cpholguera]

Thanks! This is intentional. We wait until the PR is about to be merged otherwise we keep having collisions and conflicts.

[Diolor]

@sushi2k thanks for the review! Please check my comments.

@sushi2k + @cpholguera Let's allocate the final ID for both demo + test when all other topics are resolved.

[cpholguera]

This test and the corresponding demo should be in PRIVACY (even though it was in Platform before) and we should give them a "privacy" focus. The fact that the app puts PII in notifications isn't considered a leak, the developer is adding that very much intentionally, right? It's not like they could have done something (e.g., configure something) to prevent a "leak". Therefore, this seems like a privacy concern to me.

We consider sensitive data (this page needs improvement): PII, authenticators and cryptographic material. Many (if not most apps) have a legitimate reason to add PII such as contact names, message content, transaction amounts, etc. to notifications. Please consider this when going through the test and demo again.

Suggestion for the test title "PII Exposure via Notifications"

[Diolor]

@cpholguera, I see your points. There was the suggestion by @sushi2k to move this to PLATFORM, with whom (based on my best knowledge) I tend to agree. But let's analyse it!

Our basis definition is: "sensitive data" = "PIIs" + "other data that a company has defined that should not be public"

I tried to think of a few notification examples for the "2nd category":

• "Your OTP is 12345" (yes, I have seen this 🙃 )
• "You got a deposit of $10,000" / "Your account balance dropped below $50" or other financial info
• "Time to take your insulin dose" or other health-exposing data
• "Your probation period review is scheduled for next week" e.g. from an HR application

All those notifications are not PIIs but should be treated confidentially (depending on the company's policy).
Based on that, I still see the necessity to have a test and demo for "confidential but not PIIs" notifications. However, given that the functionality (e.g. modes of introduction/mitigation) would always be the same (regardless the type of sensitive data), we should keep the "sensitive data" generalisation here.

Now, regarding moving this to PRIVACY, I quote from PLATFORM MASVS:

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 fits exactly with the demo/test. Wdyt?

[sushi2k]

@cpholguera, I see your points. There was the suggestion by @sushi2k to move this to PLATFORM, with whom (based on my best knowledge) I tend to agree. But let's analyse it!

Our basis definition is: "sensitive data" = "PIIs" + "other data that a company has defined that should not be public"

I tried to think of a few notification examples for the "2nd category":

• "Your OTP is 12345" (yes, I have seen this 🙃 )
• "You got a deposit of $10,000" / "Your account balance dropped below $50" or other financial info
• "Time to take your insulin dose" or other health-exposing data
• "Your probation period review is scheduled for next week" e.g. from an HR application

All those notifications are not PIIs but should be treated confidentially (depending on the company's policy). Based on that, I still see the necessity to have a test and demo for "confidential but not PIIs" notifications. However, given that the functionality (e.g. modes of introduction/mitigation) would always be the same (regardless the type of sensitive data), we should keep the "sensitive data" generalisation here.

This means the title could be changed to: "App Exposing Sensitive Data via Notifications", instead of "leaking". As pointed out by Carlos there is no leak as this is purposefully exposed by the developer and is supposed to be read by the user.

Now, regarding moving this to PRIVACY, I quote from PLATFORM MASVS:

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 fits exactly with the demo/test. Wdyt?

But what is the countermeasure against shoulder surfing and showing such data in the UI? You want to mask it, specifically for passwords or credit card data or make an overlay for auto generated screenshots. These are platform mechanisms where a leak would happen if you have no other compensating controls in place.

Such data like passwords wouldn't be in a notification, but an OTP and the information you listed in your examples above would be and that need to be readable in a notification which is the context here. It's not really an accidental exposure, but this information is displayed on purpose. Therefore I agree with Carlos that Platform might not be the right choice here, but Privacy is a better solution for it.