Update 0x05h-Testing-Platform-Interaction.md

[bagipro]

Thank you for submitting a Pull Request to the Mobile Security Testing Guide. Please make sure that:

• [x] Your contribution is written in the 2nd person (e.g. you)
• [x] Your contribution is written in an active present form for as much as possible.
• [x] 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)
• [x] Your contribution has proper formatted markdown and/or code
• [x] Any references to website have been formatted as [TEXT](URL “NAME”)
• [x] 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 #< insert number here >.

[anantshri]

my only concern: the person in last 48 hours or so have pushing this article in so many places it feels like promotion.

[bagipro]

@anantshri Just check the articles’ contents! It contains so many techniques that are missing on OWASP

[bagipro]

@sushi2k Thanks for your feedback. I've made changes.

Regarding the techniques:

1. OWASP docs don't say anything about intent redirection bugs (https://blog.oversecured.com/Android-Access-to-app-protected-components/) and gaining access to content providers with android:grantUriPermissions="true" flag set (https://blog.oversecured.com/Gaining-access-to-arbitrary-Content-Providers/). Those vectors are scary because, in combination with dynamic code loading, it leads to persistent LCEs very often (check out bugs in Google and TikTok)
2. OWASP section related to implicit intents doesn't say about startActivityForResult(...) that can return values via setResult(...). If content pickers are used (such as android.intent.action.GET_CONTENT or android.intent.action.PICK), it leads to theft and/or overwrite of arbitrary files (in the first case, if the URI's content is saved to a public directory; in the second case if the attacker can control output path via, e.g. Uri.getLastPathSegments() or _display_name when a vulnerable app queries it from the attacker-controlled content provider)
3. Activities that handle android.intent.action.SEND accept a Uri to share. They cache the contents somewhere and then process it as a file. The attacks are the same as in the previous item.
4. Android apps use dynamic code loading too often, and that's an issue. I would be happy if you encourage developers to don't do that.
5. OWASP also doesn't say anything about exposed binders via exported services.
6. From https://blog.oversecured.com/Android-security-checklist-webview/, OWASP doesn't report about UXSS (which is a popular issue too), bypassable URL checks (50/50 that the app validates the URL, but only 10% they are doing it securely) and WebResourceResponse
7. https://blog.oversecured.com/Android-arbitrary-code-execution-via-third-party-package-contexts/ this is not covered. But some mostly Chinese apps allow developing plugins for it (such as themes, built-in wallpapers, some action handles). They scan installed apps and automatically invoke some calls to their sources, leading to LCE.

[bagipro]

@sushi2k Also, look for https://www.blackhat.com/eu-21/briefings/schedule/index.html#re-route-your-intent-for-privilege-escalation-an-universal-way-to-exploit-android-pendingintents-in-high-profile-and-system-apps-24340. They will report a new vector on how to get access to providers via PendingIntents (a lot of apps are vulnerable to that right now!)