Port MASTG-TEST-0004: App Exposing Sensitive Data to Embedded Libraries

[Diolor]

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:

• Allocate TEST ID
• Allocate DEMO ID
• Link to weakness

[cpholguera]

A couple of things are going on here:

FIrst of all just to clarify scope. The weaknesses we should be targeting are:

• "MASWE-0112: Inadequate Data Collection Declarations"
• "MASWE-0111: Inadequate Privacy Policy"
• We also have "MASWE-0108: Sensitive Data in Network Traffic," but this should be deprecated as it is covered by the two above. In the end, the weakness isn't that the sensitive data can be found (encrypted!) in network traffic. It's only an issue if that's not properly declared.
• Note that for sensitive data in cleartext connections, we have MASWE-0050.

Test

The original test has several parts.

Part 1

To determine whether API calls and functions provided by the third-party library are used according to best practices, review their source code, requested permissions, and check for any known vulnerabilities.

This isn't good, and parts of it actually belong somewhere else.

Your new test addresses the "identification of potentially sensitive data that may have been passed to embedded third-party libraries used by the application."

TODO:

• Let's keep this test but only its "Method 2," point 2.
  • title: App Exposing Sensitive Data to Embedded Libraries -> Update to something like "References to SDK APIs Known to Handle Sensitive Data"
• Let's open an issue to create a new test that uses "Method 2," point 1.
  • title: Use of Third-Party Tracking & Analytics SDKs (something like this)
• Let's open an issue to create a new test that uses "Method 1" with MASTG-TECH-0119: Intercepting HTTP Traffic by Hooking Network APIs at the Application Layer

Part 2

All data that's sent to third-party services should be anonymized to prevent exposure of PII (Personally Identifiable Information) that would allow the third party to identify the user account. No other data (such as IDs that can be mapped to a user account or session) should be sent to a third party.

This seems to be related to MASWE-0109: Lack of Anonymization or Pseudonymisation Measures.

TODO:

• Let's open an issue for this part, which will require additional research work.

Part 3

Check all requests to external services for embedded sensitive information. [...]

This is MASTG-TEST-0206: Undeclared PII in Network Traffic Capture and the new suggested test that uses MASTG-TECH-0119 ("Method 1" in your current test).

Demo

The proposed demo is a bit misleading. When analyzing the issue statically, you won't find the sensitive user data (e.g., email, name, username) in the results. We would need to make this more realistic.

• You can only find the use of third-party SDK APIs that POTENTIALLY will hold sensitive data, e.g., in your example from Firebase (eventBundle.putString, analytics.logEvent, analytics.setUserId, etc.).
• The test should explicitly say that only calls to those methods coming from the main app files and modules are valid. Otherwise, you'll have false positives just because the app contains the SDK, which contains those methods.

TODO: update demo title to "Uses of Firebase Analytics APIs on Potential PII with Semgrep"

New Demo

We need a dynamic demo and test: we hook all those APIs and will find out which ones are actually used and what they contain.

We can then correlate that with the hooks to the network APIs and the traffic capture.

For the data we detect using these tests, the final questions are:

• Does it lack anonymization or pseudonymisation (MASWE-0109)?
• Is it properly declared/disclosed to the app user? (MASWE-0111, MASWE-0112)

Putting it all together

Now we have a pretty solid test strategy:

Static:

• We use static to know which Tracking & Analytics SDKs the app uses (new separate test).
• We use the previous info and use static again to check for use of APIs (this PR's test).

Dynamic:

• We use dynamic on the discovered APIs to learn which ones are used and what sensitive data they handle (new separate test).
• We use dynamic on networking APIs to see what sensitive data is sent over the network and by which SDK (new separate test).

Network:

• We use network analysis (traffic capture-based) as proof for the actual transmission (new separate test).

---

Summary of ## Required Actions for This PR

1. Limit the current test to only “Method 2, point 2.”

   • Update the test title to: “References to SDK APIs Known to Handle Sensitive Data.”

2. Clarify the scope in the demo section.

   • Update the demo title to: “Uses of Firebase Analytics APIs on Potential PII with Semgrep.”
   • Add a note specifying that only calls from the app’s own files/modules are considered valid (to avoid false positives from SDK code).

3. Remove or relocate content that belongs in other tests.

   • Remove any parts related to:
     • identifying third-party SDKs,
     • anonymization requirements,
     • network traffic analysis.
   • Keep the PR focused strictly on detecting potential sensitive-data-handling SDK API usage via static analysis.

4. Clarify the limitations of static analysis in this test.

   • Add text stating that static analysis detects only potential sensitive data handling, not actual user data.

Separate Follow-Up Issues (not part of this PR)

Create issues for:

1. A new test based on Method 2, point 1:
   “Use of Third-Party Tracking & Analytics SDKs.”
2. A new test based on Method 1 using MASTG-TECH-0119 (network API hooking).
3. A new test for anonymization/pseudonymisation (MASWE-0109).
4. A new dynamic test for discovering actual sensitive data passed to SDKs.
5. A new network-analysis test for verifying transmission of sensitive data.

[Diolor]

to be moved in a new issue

[Diolor]

to be moved in a new issue

[Diolor]

@cpholguera

Adjusted the scope of this PR + see point 4 bellow.

1. A new test based on Method 2, point 1: "Use of Third-Party Tracking & Analytics SDKs."
Wrote 02te0. It can be moved to a new issue with a new demo

2. A new test based on Method 1 using MASTG-TECH-0119 (network API hooking).
Wrote 02te4. It can be moved to a new issue with a new demo

3. A new test for anonymization/pseudonymisation (MASWE-0109).
willdo

4. A new dynamic test for discovering actual sensitive data passed to SDKs.
Wrote 02te3 and a demo. Can be reviewed together with currently in main scope test/demo in this PR.

5. A new network-analysis test for verifying transmission of sensitive data.
willdo

[cpholguera]

I'd use a real example, e.g. from Firebase. Also this sounds like it should be a prerequisite and not a step.

[Diolor]

We do not have a Prerequisites section. Move to the overview, then?

[cpholguera]

We do have prerequisites: but I think for this test we can simply move this to the overview for now. This way it mirrors other tests where we describe the problem and the relevant APIs. In this case, it's up to the tester to get that info ready before running the steps.

I'd still use a real example, e.g. from Firebase to make it relatable.

[cpholguera]

I'd say: if the methods are found and the data they handle is sensitive. Since this is static analysis, it'd require additional reverse engineering and ideally running the dynamic version of it.

Maybe we should start using techniques in the evaluation (in this case reverse eng.). I'm seeing a pattern, see the next test.

[Diolor]

I believe this suggestion goes down a consolidation path, and fyi it's contrary to the initial direction:
Keep the PR focused strictly on detecting potential sensitive-data-handling SDK API usage via static analysis. What is suggested is mixing this (2te1) with 2te3, or?

The current format is:

• 02te0: detect analytics SDKs in App (via SBOM)
• 02te1: detect references on the SDK (found in 02te0)
• 02te3: validate that references found in 02te0 are used

Essentially, where one test finishes, the next takes over.

I could see 02te1 and 3 merged, however, I cannot see 02te3 living along with 02te1. 🤔

[cpholguera]

We can discuss this later at the MAS Task Force. This is a consolidation path that we must start immediately. Otherwise, we'll have tests failing when there aren't any real issues.

Imagine we run these tests using an automated tool or as part of a penetration test. We cannot expect the pentester to include a finding/issue in a report that the app uses analytics SDKs. That would be more of an informational note than an actual issue. The question the tool or pentester needs to answer is:

"Is the app sharing user-sensitive data via SDK APIs with third-party services, such as analytics?" without user awareness?"

To answer this, we need to:

• Run all 02te0+1+3+4 in combination.
• Get the privacy policy and data safety section to validate whether the shared data is declared.

[cpholguera]

For this PR, we can leave it as you have it.

[cpholguera]

We're about to unify static and dynamic as much as possible. This is a perfect example of the test purpose being exactly the same and the way of testing (with its pros/cons) being different. I'd keep the same description for these 2 tests for now.

Suggested change

	This test verifies whether an app is sending sensitive data to an embedded SDK (third-party library) via its APIs (methods).
	This test verifies whether an app uses SDK (third-party library) APIs known to handle sensitive data.

[cpholguera]

Very nice but I'd avoid adding anything to the UI unless the test is about anything involving the UI.

[Diolor]

Both Demos have this on purpose: To give the reader a strong understanding of the difference between static and dynamic content. If I had hardcoded a sensitive value here, then why not use Semgrep instead?

This extra UI conveys the point of why we actually use a dynamic test here.

[cpholguera]

Fair enough. then it's time to add proper UI automation. Otherwise these demos won't be testable once we're able to run tests in our pipelines.

I'll push the code so you can test it.

[cpholguera]

Maybe you can just use the code from 00de3 for both demos.

[Diolor]

let's agree on UI topics first :)

[cpholguera]

Let's discuss it in the other comment. For here: this input gives emphasis on potential sensitive data as explained on TEST. The user might write their name, password, or....not. Therefore, I find it critical to convey that "potential" sensitive data message.

I don't think we need to go that far here. Having the same demo code in both works well and can be easily testable (whenever we add the pipeline quality testing). It'll make the test consistently repeatable with automation and also tied to specific values in the data safety and privacy policies.