1392944 - [Form Autofill] Invisible fields should be ignored for detecting the fields correctly

Status: RESOLVED FIXED

(Toolkit :: Form Autofill, enhancement, P3)

Description

[Sean Lee [:seanlee][:weilonge]]

AFAIK, only HomeDepot web site has the invisible input elements for cc-exp-month and cc-exp-year but also the select elements for cc-exp-month and cc-exp-year as well.

<input name="expiryMonth" type="tel" autocomplete="cc-exp-month" tabindex="-1">
<input name="expiryYear" type="tel" autocomplete="cc-exp-year" tabindex="-1">

<select id="ccMonth" name="ccMonth" required="">
  <option value="" selected="selected">Month</option>
  <option label="01 - January" value="object:17">01 - January</option>
  ...
</select>
<select id="ccYear" name="ccYear" required="">
  <option value="" selected="selected">Year</option>
  <option label="2017" value="object:29">2017</option>
</select>

The two inputs are invisible, and Form Autofill should fill/select the values in the two select elements.

[1] http://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/browser/extensions/formautofill/test/fixtures/third_party/HomeDepot/Checkout_ShippingPayment.html#195-196

Comment 1

[Sean Lee [:seanlee][:weilonge]]

Since this issue is not in the web site already, this bug is removed from [form autofill:MVP].

Comment 2

[Sean Lee [:seanlee][:weilonge]]

In a Shopify based web site, e.g. https://www.deathwishcoffee.com/, the billing address form in payment page not detected.

There are two sets of billing address form in one form.
Taking the first name fields as an example. The first one first name field is invisible:
<input
  class="visually-hidden"
  autocomplete="billing given-name"
  tabindex="-1"
  data-autocomplete-field="first_name"
  aria-required="true"
  size="30"
  name="checkout[billing_address][first_name]"
  type="text">

and the other is visible:
<input
  placeholder="First name"
  autocomplete="billing given-name"
  data-backup="first_name"
  class="field__input"
  aria-required="true"
  size="30"
  name="checkout[billing_address][first_name]"
  id="checkout_billing_address_first_name"
  type="text">

BTW, offsetHeight and offsetWidth of the invisible one are 2x2.

P.S. The summary is changed to a more general one since it's not a particular issue for cc-exp* only.

Comment 5

[Matthew N. [:MattN]]

Attachment 9145346 [details] has a research paper on this topic in Firefox

Can you share the data on what data type the hidden fields collected?

For mitigating the aforementioned attacks we suggest:
●Detect form elements that use the techniques described above to hide their presence (i.e., transparent, off-screen), and avoid populating them with autofill. Apply the same restrictions to <select> tag menus.

I'm somewhat surprised that you consider this worth pursuing given that there are so many ways to fool such detection… we could constantly be playing whack-a-mole e.g. if we don't autofill into opacity:0 today then the malicious sites change to opacity:0.01 tomorrow and so on…

●Show more fine-grained categories/subcategories for the information that is autofilled in the warning notification.

There are trade-offs of making it too verbose and then people just ignore the warning altogether

• Address - We could call out street address separately I suppose?
• Telephone - I don't think there is much confusion with this one… worst case someone thinks the site only wants the phone country code but actually collects the whole number but that would be quite unusual.
• Name - I guess we could be more explicit about "full name" but are there really websites that ask for a first name but hide a last name field, or vice-versa?

Thank you

Comment 6

[Panagiotis Ilia]

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #5)

Attachment 9145346 [details] has a research paper on this topic in Firefox

Can you share the data on what data type the hidden fields collected?

In our study we found pages that collect the following

• address-level1 1481
• first-name 1345
• last-name 1301
• country 1231
• address-level2 1122
• tel 1006
• organization 1050
• zip-code 803
• address-line1 737
• email 648
• name 534
• address-line2 395
• middle-name 60
• street-address 40

For mitigating the aforementioned attacks we suggest:
●Detect form elements that use the techniques described above to hide their presence (i.e., transparent, off-screen), and avoid populating them with autofill. Apply the same restrictions to <select> tag menus.

I'm somewhat surprised that you consider this worth pursuing given that there are so many ways to fool such detection… we could constantly be playing whack-a-mole e.g. if we don't autofill into opacity:0 today then the malicious sites change to opacity:0.01 tomorrow and so on…

Obviously a reasonable range is implied as opposed to a strict 0 for the opacity. A threshold could be set for the opacity value (e.g., 0.1), to ensure that input fields with opacity above the threshold are visually noticeable by the user

●Show more fine-grained categories/subcategories for the information that is autofilled in the warning notification.

There are trade-offs of making it too verbose and then people just ignore the warning altogether

• Address - We could call out street address separately I suppose?
• Telephone - I don't think there is much confusion with this one… worst case someone thinks the site only wants the phone country code but actually collects the whole number but that would be quite unusual.
• Name - I guess we could be more explicit about "full name" but are there really websites that ask for a first name but hide a last name field, or vice-versa?

See above the number of hidden fields we detected for address-line1, address-level1, street-address etc.

Thank you

Thanks

Comment 7

[Daniel Veditz [:dveditz]]

[looks like Panagiotis supplied the requested information]

Comment 8

[Daniel Veditz [:dveditz]]

Attachment: Testcase

Saving the testcase linked from the paper mentioned by Matt above.

Comment 9

[Janika Neuberger [:janika]]

This will be fixed by Bug 1847687. The patch updates the formautofill logic to only consider focusable elements for address and credit card filling.

Therefore for the home depot page, the two <input> elements are ignored because they have the attribute tabindex set to "-1". And the two <select> elements are considered for filling.