Port MASTG-TEST-0024: Testing for App Permissions (android) (by @appknox) #3076
Conversation
|
Could you please include a MASTG-DEMO as well using our app? This greatly helps understanding the test, so we're going to make this a requirement for everyone from now on (unless there's a good reason to schedule it for later, e.g. due to great complexity). Thanks a lot @ScreaMy7! |
|
@cpholguera, I have updated the format and added a demo as well. Please review. |
cpholguera
changed the title
| platform: android | ||
| title: Testing for App Permissions | ||
| id: MASTG-TEST-0x24 | ||
| weakness: MASWE-0116 |
There was a problem hiding this comment.
The new weakness is being created here:
| weakness: MASWE-0116 | |
| weakness: MASWE-0117 |
| platform: android | ||
| title: Application using unsafe permissions. | ||
| id: MASTG-DEMO-0023 | ||
| code: [java] |
There was a problem hiding this comment.
| code: [java] | |
| code: [kotlin] |
|
|
||
| ### Sample | ||
|
|
||
| {{ AndroidManifest.xml }} |
There was a problem hiding this comment.
| {{ AndroidManifest.xml }} | |
| {{ AndroidManifest.xml # AndroidManifest_reversed.xml }} |
| @@ -0,0 +1 @@ | |||
| NO_COLOR=true semgrep -c ../../../../rules/mastg-android-unsafe-app-permissons.yaml ./AndroidManifest.xml --text -o output.txt | |||
There was a problem hiding this comment.
Always use "reversed" code:
| NO_COLOR=true semgrep -c ../../../../rules/mastg-android-unsafe-app-permissons.yaml ./AndroidManifest.xml --text -o output.txt | |
| NO_COLOR=true semgrep -c ../../../../rules/mastg-android-unsafe-app-permissons.yaml ./AndroidManifest_reversed.xml --text -o output.txt |
|
|
||
| ## Evaluation | ||
|
|
||
| Please refer to this [permissions overview](https://developer.android.com/guide/topics/permissions/overview) for descriptions of the listed permissions that are considered dangerous. |
There was a problem hiding this comment.
Using the observation as input, the evaluation tells you how to evaluate it and must explicitly describe what makes the test fail.
It should start with “The test case fails if …”
This one's easy: we compare the permissions we obtained with the list of dangerous ones, right? The test fails if there are any dangerous permissions in the app.
Specify the source to obtain the list of dangerous permissions (<permission> -> android:protectionLevel): https://android.googlesource.com/platform/frameworks/base/%2B/master/core/res/AndroidManifest.xml#886
Please note that this test as-is would produce a lot of false positives. We can add some more text here in the evaluation to explain that.
**Context Considerations**:
To reduce false positives,
|
|
||
| ## Overview | ||
|
|
||
| Testing for app permissions in Android involves evaluating how an application requests, uses, and manages permissions to ensure they do not lead to security vulnerabilities. Proper permission management should protect sensitive user data and ensure that the application complies with Android's security model. The test aims to detect misconfigurations and unnecessary permissions. |
There was a problem hiding this comment.
Testing for app permissions in Android involves evaluating how an application requests, uses, and manages permissions to ensure they do not lead to security vulnerabilities. Proper permission management should protect sensitive user data and ensure that the application complies with Android's security model.
This part feels extremely generic.
- Runtime = dangerous?
- Why are we testing for "Dangerous App Permissions"?
- Why is this important?
- How does a developer add them and why would they do it instead of using other privacy-friendly options?
The test aims to detect misconfigurations and unnecessary permissions.
This doesn't seem to be what this test currently does.
|
|
||
| - Permission Scope: Pay attention to runtime permissions (introduced in Android 6.0) versus manifest-declared permissions. Some permissions require explicit user approval at runtime. | ||
|
|
||
| - Refer to this [listed permissions](https://stackoverflow.com/questions/36936914/list-of-android-permissions-normal-permissions-and-dangerous-permissions-in-api) that are considered dangerous. |
There was a problem hiding this comment.
Such a reference belongs in the test, this is just a technique and does not "evaluate" anything. Please use official sources instead.
|
|
||
| Additional Notes: | ||
|
|
||
| - Permission Scope: Pay attention to runtime permissions (introduced in Android 6.0) versus manifest-declared permissions. Some permissions require explicit user approval at runtime. |
There was a problem hiding this comment.
how do we get the list of runtime permissions?
| ## Using @MASTG-TOOL-0031 | ||
|
|
||
| Apart from enforcing custom permissions via the application manifest file, you can also check permissions using dynamic instrumentation. This is not recommended, however, because it is more error-prone and can be bypassed more easily with, e.g., runtime instrumentation. It is recommended that the ContextCompat.checkSelfPermission method is called to check if an activity has a specified permission. You can use this frida script from the [frida codeshare](https://codeshare.frida.re/@ScreaMy7/hookpermissions/) to check for runtime permissions. | ||
|
|
||
| ```bash | ||
| frida -U -l hookpermissions.js -f org.owasp.mastestapp | ||
| ``` |
There was a problem hiding this comment.
I think this doesn't belong here, it feels like it could be a different technique but I don't see the test using this, so let's get it out for now.
| ## Using @MASTG-TOOL-0018 | ||
|
|
||
| You can use Jadx or Jadx-GUI to decompile APK files and access the AndroidManifest.xml file. This allows you to view the permissions declared in the application and inspect their usage in the code. Jadx is particularly useful for static analysis as it can also decompile application code, helping identify how permissions are utilized within the app logic. | ||
|
|
||
| Steps: | ||
|
|
||
| 1. Open the APK file in Jadx or Jadx-GUI. | ||
| 2. Navigate to the AndroidManifest.xml file to view the declared permissions. | ||
|
|
||
| ## Using @MASTG-TOOL-0011 | ||
|
|
||
| You can also decompile an APK using APKTool to extract the AndroidManifest.xml file. | ||
|
|
||
| ```bash | ||
| apktool d org.owasp.mastestapp.apk | ||
| ``` | ||
|
|
||
| This command decompresses the APK and extracts all resources, including the manifest file, which lists the permissions. | ||
| APKTool is useful for detailed reverse engineering and modifying app resources if needed. |
There was a problem hiding this comment.
It looks like this overlaps with
https://mas.owasp.org/MASTG/techniques/android/MASTG-TECH-0117/
So you could say something like:
## Using the AndroidManifest
Extract the AndroidManifest.xml as explained in @MASTG-TECH-0117 and retrieve all [`<uses-permission>`](https://developer.android.com/guide/topics/manifest/uses-permission-element) elements.And you can extend MASTG-TECH-0117 with jadx.
cpholguera
changed the title
There was a problem hiding this comment.
Please move this test file to the MASVS-PRIVACY folder after addressing the comments below.
|
@ScreaMy7 any news on this? Thanks |
It's almost complete—I made a few changes and applied changes from the review. |
reviewed and fixed.
|
@cpholguera I have made the requested changes. I don't know why the URL link check failed, the link mentioned opens fine. |
closes #2985