Autofill for payments is disabled for forms within a secure iframe
Reported by
karthikn...@gmail.com,
Nov 29 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36 Steps to reproduce the problem: 1. Ensure autofill details for a payment card have been loaded previously. 2. Navigate to a site where a secure (HTTPS) payment form has been embedded as an iframe within an insecure (HTTP) page (e.g. http://www.glowworm.co.nz/bookings/). 3. Attempt to load the previously saved autofill payment data by clicking in the form text fields. What is the expected behavior? Message: "Automatic credit card filling is disabled because this form does not use a secure connection". What went wrong? The browser is incorrectly identifying the form target as being insecure, because the form is embedded as an iframe in an HTTP site. However the form data would be submitted over an HTTPS connection. The browser should allow the autofill data to populate the form. Did this work before? N/A Chrome version: 54.0.2840.99 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 The error message also implies that the payment gateway is insecure, which could negatively impact customer experience on an eCommerce site.
,
Nov 30 2016
Able to reproduce the issue on windows-7, Mac 10.11.6 and Linux Ubuntu-14.04 using chrome stable version 54.0.2840.99 and latest canary 57.0.2936.0 with the steps mentioned above. This is non-regression issue observed from M-45 # 45.0.2404.0. Hence marking it as Untriaged to get it addressed. Please find the attached screencast for reference. Thanks..
,
Nov 30 2016
,
Nov 30 2016
,
Dec 1 2016
This is WAI per our security policy I believe. The parent frame could still be compromised, which means a nefarious page, even over HTTPS, could be embedded. But mathp can confirm.
,
Dec 1 2016
We currently look for the "secureness" of the main frame. According to this post, this approach is discouraged by PCI rules as well: http://security.stackexchange.com/questions/38317/specific-risks-of-embedding-an-https-iframe-in-an-http-page I'm comfortable with our behavior here.
,
Dec 1 2016
^^ This approach, meaning embedding an HTTPS iframe within an HTTP page. Sorry if I wasn't clear.
,
Jan 31 2017
Yes, this is definitely working as intended. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ligim...@chromium.org
, Nov 29 2016Labels: -Pri-2 M-54 Needs-Bisect Needs-Triage-M54 Pri-1