Port MASTG-TEST-0004: App Exposing Sensitive Data to Embedded Libraries #3485
Conversation
There was a problem hiding this comment.
Similar reasoning as in #3464, this is a privacy concern and should be moved to PRIVACY and rescoped / reformulated as such giving emphasis to the privacy concern.
There was a problem hiding this comment.
| - For grey/white-box testing, you can manually review the app's build files (like `build.gradle`) to identify dependencies. | ||
| 2. Shortlist the embedded/3rd-party libraries' APIs which have network functionality and that should not handle sensitive information. Look for permissions like `INTERNET` or `ACCESS_NETWORK_STATE`. | ||
| - For black-box testing, you can research those libraries online or their codebase to see if they have network functionality. | ||
| - For gray/white-box testing, you can manually review the app's merged manifest file in Android Studio or by manually generating with a command like `./gradlew app:processDebugManifest` and then inspecting the file in `app/build/intermediates/merged_manifests/debug/AndroidManifest.xml`. If possible, you can review the app's codebase. |
There was a problem hiding this comment.
We have always focused on black box testing but recently also included some white box tests such as the SBOM related ones which are labeled as “manual” type if I remember properly. If we’re gonna do this we should keep the manual test separate.
For now, let’s focus on black box testing in this PR.
But please create an issue for this manual test and for creating a technique about inspecting the merged manifest in Android Studio which can be very interesting for other tests as well.
There was a problem hiding this comment.
thanks for the direction 👍
Created #3489
| - For gray/white-box testing, you can manually review the app's merged manifest file in Android Studio or by manually generating with a command like `./gradlew app:processDebugManifest` and then inspecting the file in `app/build/intermediates/merged_manifests/debug/AndroidManifest.xml`. If possible, you can review the app's codebase. | ||
| 3. Identify common APIs of those libraries that are used to send data to their servers. | ||
| - Use @MASTG-TECH-0110, potentially with @MASTG-TOOL-0108, to identify sensitive data pass to the APIs. | ||
| - Alternatively use you can perform dynamic analysis by intercepting traffic using @MASTG-TECH-0120 and @MASTG-TECH-0121. Once you route the traffic through the interception proxy, you can try to sniff the traffic that passes between the app and app's known servers. All app requests that aren't sent directly to the app's server on which the main function is hosted should be evaluated. |
There was a problem hiding this comment.
We already have https://mas.owasp.org/MASTG/tests/android/MASVS-PRIVACY/MASTG-TEST-0206/ which should be addressing Could be enhanced with a new title mentioning “undeclared PII” instead of sensitive data.
This test here would focus on the limitation of MASTG-TEST-0206: “Note that this test does not provide any code locations where the sensitive data is being sent over the network”.
We could have two approaches maybe:
- the one you’re proposing (static). We should highlight the “downside” of this approach which is that you need to have some kind of knowledge base of all existing libraries and the relevant functions where they could put PII. We should discuss this, it sounds like a significant downside.
- use Frida to hook all network functions (and try to detect PII in their calls) and use the backtraces to find out which component is sending what PII (this should also include the corresponding network domains). This should provide much greater coverage while staying sufficiently generic. Not 100% perfect but pretty good.
Diolor
changed the title
2 participants
This PR closes #2942
Description
Port MASTG-TEST-0004: Sensitive Data Leaked via Embedded Libraries (android)
As I could not create a generic Semgrep rule for all kinds of libraries, the demo uses Firebase Analytics as an example.
TODOs before merging: