Harden CreateMessageActivity against external navigation injection

[DenBond7]

This change hardens the exported compose entry point against untrusted external intents reaching internal send-only flows.

Problem

CreateMessageActivity is intentionally exported to support normal Android share and mail intents. However, untrusted external intents were able to influence internal navigation behavior more than intended and reach the outgoing-message creation path directly. That flow could then process attacker-controlled attachment URIs using FlowCrypt’s own app identity.

What changed

• sanitize incoming Intent extras before Navigation can treat them as internal deep-link state;
• preserve normal public compose/share entry behavior while preventing external navigation injection;
• Keep outgoing attachment handling restricted to FlowCrypt-managed sources only.

Why

External intents should only initialize the normal compose experience. They must not be able to route directly into internal send logic or supply unsafe attachment locations that are later opened with app privileges.

What verified:

• normal ACTION_SEND, ACTION_SEND_MULTIPLE, and mailto: flows still open compose as expected;
• internal reply/forward/draft flows still work;
• crafted external intents can no longer reach the internal outgoing-message creation dialog;
• unsafe attachment URIs outside FlowCrypt-managed locations are rejected.

close #3227

---

Tests (delete all except exactly one):

• Tests added or updated

---

To be filled by reviewers

I have reviewed that this PR... (tick whichever items you personally focused on during this review):

• addresses the issue it closes (if any)
• code is readable and understandable
• is accompanied with tests, or tests are not needed
• is free of vulnerabilities

[DenBond7]

@martgil Please test this one

[sosnovsky]

looks like current allowlist is too strict - for example, when trying to send email message with attachment from google drive, I received such error message:

got such explanation from Codex:

This allowlist rejects normal user-selected attachments from Android's document picker, whose URIs commonly use authorities such as com.android.providers.media.documents or com.android.externalstorage.documents. addAttachmentInfoFromUri() stores those content:// URIs directly in composeMsgViewModel, and ProcessingOutgoingMessageInfoHelper now calls this validator before opening them, so sending a manually attached file will fail. The sink should reject unsafe file:// paths, but still allow externally granted content:// URIs.

[DenBond7]

Good catch, you are right. Thanks for pointing this out! I’ll fix the issue.

[DenBond7]

@sosnovsky I've fixed it and updated tests

[martgil]

@martgil Please test this one

Will do - I'll keep you posted as soon as possible.

[martgil]

Hi @DenBond7, I have already done testing this PR and the database was no longer be added as an attachment to the secure email through using the malicious actor's application (in this case, the provided poc).

[sosnovsky]

works well now, thanks!