786276 - Don't autofill logins in frames that are not same-origin with top-level page

Status: VERIFIED FIXED

(Toolkit :: Password Manager, defect, P2)

Description

[causeless]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1

Steps to reproduce:

In some SNS, click-jacking is not prevented on login form if the user is logged out.
If you saved password, click-jacking may lead users into logging in unintentionally by autofilled passwords.
Its a sort of click-jacking vulnerability on server side. but affect all users of the insecure SNS.

I've already found foursquare.com as one of such SNSs.
https://ja.foursquare.com/login or their other locales are not prevented from CSRF/clickjacking.


Actual results:

Some of SNSs are display users status like their realtime location to worldwide if logged in.  So unintentional login may cause a serious user information leakage.



Expected results:

the password autofiller must be allowed only if the url displayed on the location bar match the origin of password form to be autofilled.

Comment 1

[causeless]

https://bugzilla.mozilla.org/show_bug.cgi?id=610997
seems same attack. but i think the resolution suggested by Daniel Veditz is inappropriate.
Require users manually fill username will also prevent this attack but same-origin policy i wrote above allows automatic prevention.

and for 2 years, more SNS may leak sensitive information if the user log in unintentionally.

Comment 2

[Al Billings [:abillings - ex-MoCo]]

Matt, can you look at this to confirm it?

Comment 3

[Daniel Veditz [:dveditz]]

I suspect the password manager folks will reject this approach since some sites host their generic "account" login on a sub-domain that differs (e.g. google.com sites sometimes (used to?) frame accounts.google.com). We could take an eTLD+1 approach, but then other folks will point out this leaves sites with mutually hostile sibling domains unprotected (e.g. livejournal).

Comment 4

[causeless]

I think "semi-automatic" autofill would be better implement. If the iframe is not same-origin, password manager should confirm before autofill password. This approach requires one additional click to users only if the website is clickjackable. It will make incentive to think about clickjacking.

Example:
1. Autofill if iframe.src is same-origin with location.href.
2, If not, confirm "Your password of login.example.com will be autofilled. (Y/n)"
3, If yes, fill saved password.
will not lose any saved passwords but protect users properly.

Comment 7

[Steven Englehardt [:englehardt]]

To fix the dFPI tracking vulnerability described in Bug 1658078 we'd need to ensure that no part of credentials are autofilled (not just password).

Comment 8

[Bianca Danforth [:bdanforth]]

Attachment: Bug 786276 - Don't autofill logins in frames that are not same-origin with top-level page

Comment 9

[Bianca Danforth [:bdanforth]]

Attachment: Bug 786276 - Rename formsProcessed test helpers to accurately reflect when they can be used.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4a2a0128e6ec
Don't autofill logins in frames that are not same-origin with top-level page r=sfoster

Comment 11

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/4a2a0128e6ec

Comment 12

[Bianca Danforth [:bdanforth]]

QA Test Instructions
Note: If the second patch has not landed yet, you can still QA this feature, as the second patch contains test-only changes. Hopefully it will land in the next few days.

1. In a new profile in Firefox 83, go to about:logins.
2. Click Create New Login and create a login for:

• Enter https://bugs.mattn.ca for the website address field.
• Enter a fake username for the username field.
• Enter a fake password for the password field.
• Click Save.

3. Go to https://bugs.mattn.ca/pwmgr/login_and_change_form.html.
4. Observe that the login you created for the origin https://bugs.mattn.ca is autofilled into the form in the "Login form:" section, among others.
5. Go to https://mozilla.github.io/form-fill-examples/password_manager/form_with_iframe.html.
6. Observe that the login you created for the origin https://bugs.mattn.ca is not autofilled into the https://bugs.mattn.ca/pwmgr/login_and_change_form.html page loaded into the iframe (in the "Login form:" section or anywhere else).
7. To the extent that you can find other login pages that allow being loaded in iframes (i.e. their X-Frame-Options header is not set), you can change the src attribute for the iframe in the page using Firefox's DevTools.

• The src value can be edited by selecting the <iframe> in the Inspector and entering e.g. $0.src = "https://example.com" in the Console.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/da72198eabd0
Rename formsProcessed test helpers to accurately reflect when they can be used. r=sfoster

Comment 14

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/da72198eabd0

Comment 15

[Timea Cernea [:tbabos][inactive]]

Reproduced the issue on affected Release 81.0.2 on Windows 10 x64.
Verified-fixed on latest Nightly 83.0a1 (2020-10-18) (64-bit) on Windows 10, MacOS 10.15 and Ubuntu 16.04 with the following expected result:
The login you created for the origin https://bugs.mattn.ca is not autofilled into the https://bugs.mattn.ca/pwmgr/login_and_change_form.html page loaded into the iframe (in the "Login form:" section or anywhere else).

However, would like to clear things up a bit before marking this as verified.
On the https://bugs.mattn.ca/pwmgr/login_and_change_form.html all the "Login form:" section should be auto-filled in ALL the areas involving Shadow Root? We have:

1. Inside a single Shadow Root -> this gets autofilled only on Windows 10 (on macOS and Ubuntu is no longer autofilled in Nightly, works on Beta and Release, could this be a regression?)
2. Form contents inside a Shadow Root -> is never auto-filled on any of the OS and Firefox versions

Please take a look at this when you have the time Bianca, will do mozregression in the meantime on MacOS and see what exactly introduced the different behavior.

Comment 16

[Timea Cernea [:tbabos][inactive]]

Apparently, there were some caching issues going on for me, mozregression didn't reproduce this at all. A couple of page refreshes solved this and it is no longer reproducible with new Firefox profiles either. So ignore point 1, but do let me know about point 2.
Sorry for all the fuzz Bianca

Comment 17

[Bianca Danforth [:bdanforth]]

Hi Timea; thanks for testing this.

I should have mentioned that this patch is unrelated to the Shadow DOM work, and consequently, Shadow DOM scenarios are out of scope for this bug.

In general, most Password Manager features do not work at all with Shadow DOM; fixing that is being tracked by Bug 1629226.

The test page is a general purpose test page that I am borrowing for convenience. Ideally I could have used a simple login form page (with a single form, like the one in the "Login form" section) to load into the iframe to avoid confusion, but this is the only page I found that didn't have the prohibitive X-Frame-Options header.

Comment 18

[Timea Cernea [:tbabos][inactive]]

Thanks for clearing things out Bianca! Marking this as verified-fixed as per Comment 15 and Comment 17.

Comment 19

[Tom Ritter [:tjr]]

Attachment: advisory.txt