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.

[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?