Hi! Thanks for the report. I was unable to confirm the report on Linux or ChromeOS, perhaps it is a Mac specific issue?

@rouslan please assign an owner. Also CC'ing @cthomp as I'm unable to assess severity on this one, hopefully you can assign a label?

I will take a look of this bug

Useless message posted in the comment #4, so removed it.

The phenomenon is because we skipped payment request UI in this case, which is an intended feature.

In worst case, there is a service worker / PH installed in the malicious scope. By our current design, any PH can be installed by opening a web page in the scope silently without user consent. And users can block it in 'chrome://settings/content/paymentHandler' later.

This looks similar to Issue 865202 where having the default button be the "proceed" action is incorrect for sensitive UI flows -- there, we changed the default button to be "Cancel", and it sounds like the same should apply here. We've had this come up in a number of other sensitive UI flows...

This feels slightly higher severity than Issue 865202. In that bug, a user had to click an external protocol link and hold down Enter. Here, a site can trigger the prompt via javascript without any other user interaction. If I understand the payment request flow here correctly, this could allow an attacker to trick a user into making a payment, which sounds fairly severe.

gogerald@ Can you comment on whether this could be used to trick a user into making a request? Your comment in #5 seems to indicate this just installs a service worker / payment handler "in the worst case", but I don't know what the consequences of that are. When I load the PoC page, on keypress I get a payment request popup with the default button being "Pay" (see attached screenshot). This makes me think that holding down Enter would immediately trigger the "Pay" button. This seems like a much worse "worst case".

Re comment #6: 'holding down Enter would immediately trigger the "Pay" button' could happen, but it wouldn't make the 'worst case' much worse, since the malicious website can only install payment handler in its own scope to support its own payment method, and without providing payment information by user, it shouldn't be able to steal anything.

Ah, okay, I think I understand better now. So it gets a new payment handler installed but does not trigger an existing payment handler. Are we sure that a "Pay with existing CC" payment request is not similarly triggerable?

Does this potentially expose a not-super-conscientious user to theft of sensitive payment details in the future? That is, if they go to a legitimate site which requests a payment and they accidentally use this installed malicious hanlder, does the attacker get details about the purchase then? Or does the requestor also have to agree to use the handler?

Re comment #8: That should not happen. Legitimate sites will only legitimate payment methods and malicious payment handler can not claiming support of legitimate payment method since we will verify it against the payment method manifest.

For standard payment method, like "basic-card", which we can not verify payment handler against with, no payment request information will be send to the payment handler only supports standard payment method.

Okay. Per #9, this sounds Severity-Low (similar to Issue 865202). If there were ways for an attacker to use this to direct future payment request data to the attacker or automate a legitimate payment, then this would be much higher severity.

I tested it and the cancel button is the default focused when the payment request pops up. :)

Ahh, it appears to be "Pay" by default on Linux for me, but "Cancel" on MacOS.

This is what I see. I press "R" key and nothing happens, but behind the scene, ServiceWorker is already installed. I could also confirm this in Windows. Is this only happening to me?

In Canary, at least the popups appears. But only with close button (at which point, Service Worker is already installed).

Oh, I missed the comment #5. So is this intended behavior? If so, you can close the case.

This is intended behavior. I will update the doc.

Note this does not present a new attack vector. Any webpage can already embed an iframe from a malicious origin that can install a service worker, but that service worker is not going to have user's payment info regardless of whether it is installed via an iframe or through PaymentRequest.

Closing as WontFix - works as intended.

While it seems we've determined that there is not a security issue here, should we fork a new bug for the default button keyboard focus question? We should consistently not allow dialogs to be bypassable in this way (for UX consistency, even if it does not have any particular security consequences). For other UI, we've wanted to have explicit time delays before actions can be taken (to reduce clickjacking), but here just ensuring that the Cancel button is the default focused button cross-platform seems sufficient.

Sure, please fork that out.

Created Issue 881452 to track the default focus concern.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot