Cross-Origin Iframe -> Native Bridge (No Main-Frame/Origin Check)

← Native / WebView Bridge (JS <-> Native)

crossorigin_iframe_to_native_bridge   HARD

Description

The JS-bridge message handler does not verify the message came from the main frame / trusted origin, so a cross-origin iframe reaches the bridge, runs JS in the trusted main-frame origin, and exfiltrates the session/access token (Home Assistant Companion CVE-2026-44698 class; Android addJavascriptInterface + iOS WKUserContentController).

How it works

A WebView JS-bridge message handler (Android addJavascriptInterface / WebMessageListener; iOS WKUserContentController) is registered on the app WebView, but it does not verify that a message came from the main frame or the trusted first-party origin. So a cross-origin ad iframe embedded in the page posts a “getAccessToken” message; the native side honors it as if it were the trusted app UI and returns the session token, which the iframe exfiltrates (Home Assistant Companion CVE-2026-44698 class). This runs in a real WebView: a cross-origin iframe posts the message over a native JS bridge and the native side returns the token (the in-memory panel is the offline contrast). The secure path requires isMainFrame and origin==trusted before returning anything sensitive.

How to exercise it. DVMA is the harness - open this module from the home index and tap the demo action. The screen ships the malicious input and simulates the attacker (e.g. the companion app, crafted intent, or scanned payload) in-process, and the evidence panel prints the proof. The Tools (optional) and Attack inputs below are only needed to reproduce the exploit end-to-end on a real device.

Exploit steps

1. Set up. Build DVMA with a flavor that enables the Native / WebView Bridge (JS <-> Native) category (e.g. --dart-define-from-file=config/flavors/dev.json) and run on an emulator/simulator you control. The demo needs no external tooling; for the optional on-device reproduction the relevant tools are: mitmproxy, r2frida, frida, objection · Android: jadx · iOS: ipsw, class-dump.
2. Locate the target. From the home index, open Cross-Origin Iframe -> Native Bridge (No Main-Frame/Origin Check) (crossorigin_iframe_to_native_bridge). The How it works section above describes this module’s specific weakness; the screen states the intended-secure behavior and exposes the vulnerable action.
3. Exploit. Reach the JS<->native bridge (or the framework/plugin API) from untrusted web content / a cross-origin iframe / a malicious provider, and confirm the privileged native call fires with no main-frame/origin, callback-id, or permission gate in between.
4. Observe the evidence. Trigger the vulnerable action and read the evidence panel - it prints the concrete proof (leaked value, accepted replay, executed payload, or unauthorized result).
5. Contrast with the secure path. Run the module’s secure/hardened action (where provided) and confirm the same attack is rejected - this is what a correct implementation should do.
6. Map it back. Cross-reference the MASTG v2 test(s) MASTG-TEST-0334, MASTG-TEST-0376 for the canonical procedure and remediation.

Tools (optional)

• mitmproxy
• r2frida
• frida
• objection

Android

• jadx

iOS

• ipsw
• class-dump

Real-world references

Concrete public disclosures that match this vulnerability class:

• CVE-2026-44698 / GHSA-7jp2-p2fw-mgvf (Home Assistant iframe->bridge token theft)
• CVE-2024-28895 (Yahoo! JAPAN cross-app WebView XSS)
• CVE-2026-35643 (OpenClaw untrusted WebView origin -> JavascriptInterface injection)