Duplicate control: 2.6 and 6.4

[TheDauntless]

These controls are very similar:

2.6 - No sensitive data is exposed via IPC mechanisms.

6.4 - The app does not export sensitive functionality through IPC facilities, unless these mechanisms are properly protected.

From the MSTG (iOS), I can see the intended difference, but all of the techniques of 6.4 can also be applied to 2.4:

https://github.com/OWASP/owasp-mstg/blob/d3460bab8bc512b348807830afbb9455acf9a604/Document/0x06h-Testing-Platform-Interaction.md#testing-for-sensitive-functionality-exposure-through-ipc-mstg-platform-4

Do you guys see an inherent difference?

On Android, you could say that there is more of a difference (content providers vs exported activities), but these could also just be grouped in the same control. Especially with the 'activity for result' concept.

[commjoen]

The inherent difference is that one focuses on the data, the other on functionalities. Both should have a different follow up.

[commjoen]

The difference becomes more clear when we talk arguments for intentes/application urls for instance: this funciton by itself is not really sensitive,unless you:

• share sensitive identifiers by it (2.4)
• start sensitive functionalities (6.4) .

To me that brings quiet a difference. But I must admit it requires a bit of explanation if you forget about the contexts of when it was written. For this, a little explanation could help i guess ? so overall definately something we can improve on in terms of explanation.

[sushi2k]

I think it makes sense to see it from two different ankles:

1. What is the attack surface of the app in terms of exported functionality and should all of these be exposed or access restricted? (MSTG-Platform-4)
2. For those that are still available after going through 1., is there sensitive data exposed (MSTG-Storage-6)

I was also going through the test cases for Android:

• Android - MSTG-Storage-6 (https://mobile-security.gitbook.io/mobile-security-testing-guide/android-testing-guide/0x05d-testing-data-storage#determining-whether-sensitive-stored-data-has-been-exposed-via-ipc-mechanisms-mstg-storage-6) - focuses more on how to retrieve data and exploiting a content provider
• Android - MSTG-Platform-4 (https://mobile-security.gitbook.io/mobile-security-testing-guide/android-testing-guide/0x05h-testing-platform-interaction#testing-for-sensitive-functionality-exposure-through-ipc-mstg-platform-4) - focuses more on the IPC mechanisms and enumeration of the same

But you are right and I agree, they are definitely overlapping. We could structure it in a way so that MSTG-Platform-4 could be more about explaining the IPC mechanisms on Android and iOS, how to enumerate them and what the best practices are in terms of restricting access and MSTG-Storage-6 could be things like SQL injection in Content providers as there might still be coding issues in there that cannot be captured by MSTG-Platform-4.

@TheDauntless does that make sense for you?

[TheDauntless]

@sushi2k Your split up makes sense. One is from an architecture point of view, the other about the implementation. But I don't really agree with where you suggest to put them.

Content providers, export activities, services, etc are all part of platform interaction. Without these functionalities, you don't have inter-app communication and together they make up the attack surface of the application. IMO this should all be put in section 6, where it currently is.

The implementation part of your suggestion is already in 6.2:

All inputs from external sources and the user are validated and if necessary sanitized. This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and network sources.

Splitting it up between data vs functionality seems unnecessary. If you can query an exposed contentprovider for sensitive data, then it fits in both since the 'functionality' is 'querying data' and it is of course data as well. If you can extract something through SQLi, then that's because of a 6.2 violation.

[cpholguera]

Marked as the answer since this will be merged into MASVS-PLATFORM.