New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 881452 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug



Sign in to add a comment

Payment handler dialog defaults to "Pay" button keyboard focus, potentially bypassing user consent

Project Member Reported by cthomp@chromium.org, Sep 6

Issue description

Chrome Version: 70.0.3534.4 (Official Build) dev (64-bit)
OS: gLinux

What steps will reproduce the problem?
(1) Trigger a payment request/handler dialog
(2) Hit enter (or have been holding enter already when it triggered)
(3) "Pay" button is the default and the dialog will disappear before it can be read by the user

See  Issue 880579  for a POC (ask if you need to be CC'd for access -- for now I'll leave it view restricted).

What is the expected result?

The dialog should not proceed without actual user consent.

What happens instead?

The dialog automatically proceeds without user consent. In the attached screenshot you can see that "Pay" has the default focus.

The default on MacOS appears to be "Cancel".

Default focus issues have bitten us before (for example, see Issue 865202 and a kind of similar bug in  Issue 637098 ).

This is forked from the (security) bug  Issue 880579  which was marked WontFix/WAI. While this may not be a security concern (it was determined that this behavior cannot happen for a payment requests using existing providers or CCs, for example, and a site can install a payment handler in other ways already). Copying over labels/components/owners/ccs from that bug, but feel free to change as appropriate.

Setting OS=Linux since I haven't tested other operating systems and leaving untriaged to let Payments folks figure out priority and assignment.

 
PaymentRequestDefaultButton.png
20.1 KB View Download
Cc: gogerald@chromium.org
Labels: -Pri-3 Pri-1
Owner: rouslan@chromium.org
Status: Assigned (was: Untriaged)
Need to figure out a good way to mitigate this.
I'll admit I don't know how this is implemented so this may not be useful, but for the external protocol handler dialog (which is a Views UI), changing the default was fairly straightforward:

https://chromium-review.googlesource.com/c/chromium/src/+/1142705

However, as this bug appears to have platform-specific differences, which may mean the simple solution won't work :-(
What is the attack scenario? I'm wondering whether I should consider only users that hold down Enter or also users that quickly tap Enter multiple times.
I'm not sure. I think the "holding down enter" case is more pernicious, as it basically guarantees the user won't see the dialog at all to even notice that something happened. Changing the default to "Cancel" on all platforms (not just MacOS) would handle both cases, though. 

Sign in to add a comment