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: A potential vulnerability in AccountChooserDialogView allows credential row buttons to bypass the InputEventActivationProtector safety mechanism. An attacker hosting a PSL-matched or affiliated origin can programmatically trigger the credential chooser and harvest an unintended user click. This can result in the unauthorized disclosure of the user’s cleartext credentials to the calling website.

Affected files:

• chrome/browser/ui/views/passwords/account_chooser_dialog_view.cc
• chrome/browser/ui/views/passwords/credentials_item_view.cc

Estimated timestamp from git blame: 2019-07-09

Description / Root Cause

The AccountChooserDialogView is used by the Credential Management API to allow users to select saved credentials when multiple matches exist and the kCredentialManagementUnifiedUi feature is disabled (which is the code default).

To prevent clickjacking and accidental interactions immediately after a dialog is shown, Chromium utilizes InputEventActivationProtector. However, this protector is currently only enforced for standard dialog buttons (like OK and Cancel) handled by DialogClientView::ButtonPressed:

// ui/views/window/dialog_client_view.cc
void DialogClientView::ButtonPressed(ui::mojom::DialogButton type,
                                     const ui::Event& event) {
  DialogDelegate* const delegate = GetDialogDelegate();
  if (!delegate ||
      input_protector_->IsPossiblyUnintendedInteraction(
          event, /*allow_key_events=*/delegate
                     ->ShouldAllowKeyEventsDuringInputProtection())) {
    return;
  }
  ...
}

In AccountChooserDialogView, each credential row is rendered as a custom CredentialsItemView (which inherits from views::Button). These item views are wired directly to AccountChooserDialogView::CredentialsItemPressed:

// chrome/browser/ui/views/passwords/account_chooser_dialog_view.cc
for (const auto& form : controller_->GetLocalForms()) {
  ...
  auto* credential_view =
      list_view->AddChildView(std::make_unique<CredentialsItemView>(
          base::BindRepeating(
              &AccountChooserDialogView::CredentialsItemPressed,
              base::Unretained(this), base::Unretained(form.get())),
          ...));
}

Because interactions with these rows skip the DialogClientView button path, they completely bypass the input event protection check. A user’s click or tap that occurs immediately upon the dialog’s appearance is accepted with zero minimum-display delay.

Potential Trigger Path / Attack Scenario

Note: The following scenario represents potential steps an attacker might follow. Our analysis is based on static code review, and we have not run dynamic proof-of-concept exploits.

1. The attacker controls or compromises a subdomain or affiliated origin (e.g., https://attacker.example.com which PSL-matches the victim’s saved credential origin https://login.example.com).
2. The attacker’s page prompts the user to click at a precise UI location (e.g., a fake CAPTCHA or decoy button) corresponding to where the dialog’s first credential row will appear.
3. Upon user interaction (e.g., a mousedown event), the page calls navigator.credentials.get({password: true, mediation: 'required'}) to trigger the credential chooser.
4. Due to the lack of an input protector on the row button, the subsequent mouse-up or rapid second click immediately registers on the CredentialsItemView row.
5. The browser processes the select click, resolves the API promise, and returns the cleartext password of the affiliated/PSL match back to the attacker’s page.

Impact

An attacker can obtain the user’s cleartext credential for an affiliated/PSL-matched origin through a single clickjacking or interaction-harvesting attempt, bypassing the intended minimum-display-time protections meant to safeguard credential release.

Suggested Fix

Instantiate an InputEventActivationProtector within AccountChooserDialogView itself and update its visibility state appropriately. Modify the CredentialsItemView pressed callback to accept and pass the underlying ui::Event so the protector can validate the interaction timing before executing the credential selection:

void AccountChooserDialogView::CredentialsItemPressed(
    const password_manager::PasswordForm* form,
    const ui::Event& event) {
  if (input_protector_ && input_protector_->IsPossiblyUnintendedInteraction(event)) {
    return;
  }
  if (controller_) {
    controller_->OnChooseCredentials(
        *form, password_manager::CredentialType::CREDENTIAL_TYPE_PASSWORD);
  }
}

Evaluated with Chrome root at commit: 3947e01999a53d4e2382e39736cb79d79c7dffcf

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.