Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: ExternalProtocolDialog uses InputEventActivationProtector to prevent unintended clicks, but does not re-arm it when its window is activated or undergoes z-order changes. An attacker could potentially display the dialog in an opener-controlled popup, occlude it behind an active window during user interaction, and programmatically focus the popup right before a user click lands. This allows the in-flight click to immediately accept the dialog and launch an external application without genuine consent.

Affected files:

• chrome/browser/ui/views/external_protocol_dialog.cc
• chrome/browser/ui/views/external_protocol_dialog.h

Estimated timestamp from git blame: 2025-06-16

Summary

ExternalProtocolDialog (located in chrome/browser/ui/views/external_protocol_dialog.cc) gates launches of external applications through custom URI schemes (e.g., vscode://, zoommtg://, steam://). To protect against clickjacking and accidental clicks, views dialogs utilize InputEventActivationProtector.

However, ExternalProtocolDialog does not observe widget activation or z-order changes. While it re-arms input protection when unoccluded by Picture-in-Picture windows (PictureInPictureWatcher), it does not re-arm when the window itself is brought to the foreground via w2.focus() or OS window activation. This creates a potential clickjacking surface where an attacker can pace user clicks and elevate the dialog under the cursor after its initial protection cooldown has expired.

Root Cause Analysis

1. Protector Arming & Acceptance: DialogClientView installs an InputEventActivationProtector with DefaultInputProtectionPolicy (ui/views/input_protection/default_input_protection_policy.cc). Upon initial display, view_protected_time_stamp_ is set to $T_0$. If no further events reach the dialog and the cooldown period (typically 500ms) elapses, any subsequent click is treated as valid (IsPossiblyUnintendedInteraction returns false).

2. Missing Re-arm on Window Activation: Unlike permission prompts (e.g., chrome/browser/ui/views/permissions/permission_prompt_bubble.cc:95-104 and chrome/browser/ui/views/permissions/chip/chip_controller.cc:228-241), which implement WidgetObserver::OnWidgetActivationChanged and call TriggerInputProtection(/*force_early=*/true) when foregrounded, ExternalProtocolDialog does not implement WidgetObserver for window activation.

3. Stationarity Monitor Scope: The global WindowsStationarityMonitor (ui/views/windows_stationarity_monitor_aura.cc:65-79, ui/views/windows_stationarity_monitor_mac.mm:56-66) only resets protection when windows are destroyed or their bounds change—not on activation or z-order shifts.

4. Opener Focus Carve-Out: In Blink, DOMWindow::focus() explicitly permits an opener window to focus a popup it opened (third_party/blink/renderer/core/frame/dom_window.cc:736-740). If the opener has transient user activation from previous clicks (third_party/blink/renderer/core/frame/frame.cc:669-687), the focus request succeeds and instructs the browser to activate the popup window (WebContentsImpl::Activate() $\to$ BrowserView::Activate() $\to$ Widget::Activate()).

Potential Steps to Trigger

(Note: These are potential steps derived from code analysis; our tooling agent does not currently have the capability to execute live browser code.)

1. Victim visits an attacker-controlled page ($W_1$) presenting a fast-paced clicking interaction (e.g., a mini-game) requiring rhythmic clicks at fixed screen coordinate $P$.
2. On the first click, $W_1$ obtains transient user activation, calls window.open() to spawn popup $W_2$ positioned so that its tab-modal [Open] button aligns with coordinate $P$, and triggers a navigation in $W_2$ to an external URI (e.g., vscode://...).
3. The browser creates and shows ExternalProtocolDialog in $W_2$, arming its input protector at timestamp $T_0$.
4. Subsequent clicks in the game land on $W_1$, natively raising $W_1$ over $W_2$. $W_2$ becomes occluded behind $W_1$, but its dialog remains widget-visible and its input protector timestamp remains $T_0$.
5. After $>500\text{ms}$ has passed since $T_0$, $W_1$ invokes w2.focus() shortly before an anticipated user click.
6. The browser activates and raises $W_2$ directly under the cursor. Because activation triggers no input protection reset, the in-flight click is delivered to DialogClientView::ButtonPressed.
7. IsPossiblyUnintendedInteraction returns false, causing the dialog to accept and invoke ExternalProtocolHandler::LaunchUrlWithoutSecurityCheck(), launching the external application without genuine consent.

Impact

Bypasses user consent for launching registered external application URI handlers. In scenarios where a local application has argument injection or custom handler vulnerabilities, this could lead to untrusted command execution.

Suggested Fix

Implement views::WidgetObserver on ExternalProtocolDialog (or its host window) and override OnWidgetActivationChanged. When the widget or its parent browser window becomes active, invoke TriggerInputProtection(/*force_early=*/true) to re-arm the protection window, mirroring the mitigation in PermissionPromptBubble:

void ExternalProtocolDialog::OnWidgetActivationChanged(views::Widget* widget, bool active) {
  if (active) {
    TriggerInputProtection(/*force_early=*/true);
  }
}

Evaluated with Chrome root at commit: c6718ebbf2c677c6f63691e28c7801c563f6b19c

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.