New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users
Status: Fixed
Closed: May 8
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

Sign in to add a comment
Security: Chrome PaymentRequestAPI Payment-Origin Spoof
Reported by, May 2 Back to list
PaymentRequestAPI show the native payment UI with show().In this UI,include the origin of payment.An attacker can change the origin of payment.

Chrome Version: [58.0.3029.83] + [stable]
Operating System: [Android]

(1) Open in android chrome
(2) Click the button "Click me"
(3) Click the button "Pay 9999USD ("

2.2 KB View Download
299 KB View Download
99 KB View Download
251 KB View Download
Components: Blink>Payments UI>Security>UrlFormatting
Status: Untriaged
Labels: Security_Severity-Medium Security_Impact-Stable OS-Android
Status: Assigned
rouslan, could you please take a look, or help with assigning this to the right person? thanks!
Given that the attacker controls the string immediately above the "spoofed" string, this feels more like a Low severity issue. 
Components: -Blink>Payments UI>Browser>Autofill>Payments
Labels: -Security_Severity-Medium Security_Severity-Low
elawrence: Do you think disabling the API on data URLs would help?
+lgarron@, expert on URL display.

(FWIW, the repro here is a blob: URL; top-level navigation to data: URLs will be blocked in Chrome 60 ( Issue 684011 ). Do we allow the API in subframes?)

Having said that, is there a reason that we're showing a full URL here instead of the security origin?
Drive-by: IMO we should disable this API on anything other than https URLs. There is all sorts of weirdness with pseudo URLs that make their display a nightmare (e.g. blob URLs can have null origins if they are opened by data URL iframes).
We allow API in subframes that have "allowpaymentrequest" attribute.

We're showing the output of FormatURLForSecurityDisplay(webContents.getLastCommittedURL()). Let me check the code to see what's happening exactly.
meacer, localhost and file:// scheme origins should also be enabled for testing.
OK, so https, localhost and file only then? 
SGTM. I can make the change.
Status: Started
FYI. I believe this has been fixed in Canary ( via

xisigr: Can you verify?
meacer: Would it be OK to allow the API on all cryptographic schemes? (Along with localhost and file:// scheme origins.)
Labels: Team-Security-UX M-59 Pri-1
#14: That would add only WSS. That seems unlikely to happen in the real world, but also harmless?

Are we sure this bug is present only on Android?
Any reason we can't use IsOriginSecure()?
> Any reason we can't use IsOriginSecure()?

We use IsOriginSecure() since

> Are we sure this bug is present only on Android?

Desktop UI does not show the origin. I'll work with iOS folks on getting this fixed as well. +mahmadi

> That would add only WSS. That seems unlikely to happen in the real world, but also harmless?

Also HTTPS-SO. I'm not sure what WSS and HTTPS-SO are, but they are all considered "cryptographic" in Chrome.

Labels: -OS-Android OS-All
> Also HTTPS-SO. I'm not sure what WSS and HTTPS-SO are

Those are schemes to designate suborigins ( That whole suborigin-encoded-in-the-scheme thing might be going away soon anyway, but for now that seems fine; I don't see any reason to restrict payment requests on suborigins.
> Any reason we can't use IsOriginSecure()?

IsOriginSecure incorrectly considers a bunch of unrelated schemes as secure (file, filesystem, about:blank (bug 696810) and data (bug 684231).
Project Member Comment 23 by, May 3
Labels: -Pri-1 Pri-2
The bug that allows an attacker tamper with trusted origin of Payment UI.Is this SecSeverity-Low? 

rouslan: This bug is not valid in Canary, I think it has been fixed.

Re #24: URL Spoofing in contexts outside of the address box does not have a defined severity ( 

Given that the UI here isn't a surface with which most users will be familiar, and because the spoofable string is immediately adjacent to a string which is deliberately attacker controlled, Low severity seems appropriate to me. 
Project Member Comment 28 by, May 8
The following revision refers to this bug:

commit b28f4539b767b634d9257964f04e72b8987910b5
Author: rouslan <>
Date: Mon May 08 15:41:47 2017

Disable web payments API on blob: and data: schemes.

This patch makes always reject with
NotSupportedError and PaymentRequest.canMakePayments() always return
false on origins that are not either localhost, file://, or
cryptographic scheme.

BUG= 717476 

Cr-Commit-Position: refs/heads/master@{#469991}


Status: Fixed
Project Member Comment 30 by, May 9
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: -M-59 M-60
Components: -UI>Browser>Autofill>Payments UI>Browser>Payments
Labels: Release-0-M60
Labels: CVE-2017-5110
Project Member Comment 35 by, Aug 15
Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Sign in to add a comment