Closed Bug 786276 Opened 12 years ago Closed 4 years ago

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

Categories

(Toolkit :: Password Manager, defect, P2)

Product:
Toolkit
Component:
Password Manager
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
83 Branch
Tracking Flags:
Tracking Status
firefox83 --- verified

People

(Reporter: causeless, Assigned: bdanforth)

References

(Blocks 2 open bugs)

Details

(Keywords: privacy, sec-low, Whiteboard: [security:passwords][adv-main83+])

Attachments

(3 files)

Bug 786276 - Don't autofill logins in frames that are not same-origin with top-level page
(deleted), text/x-phabricator-request
Details
Bug 786276 - Rename formsProcessed test helpers to accurately reflect when they can be used.
(deleted), text/x-phabricator-request
Details
advisory.txt
(deleted), text/plain
Details
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.
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.
Component: Untriaged → Security
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=610997
Component: Security → Untriaged
Matt, can you look at this to confirm it?
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).
Group: core-security
Status: UNCONFIRMED → NEW
Component: Untriaged → Password Manager
Depends on: CVE-2020-26962
Ever confirmed: true
Keywords: privacy, sec-low
Product: Firefox → Toolkit
Summary: Password Autofill leaks realtime location of SNS users → Don't autofill passwords in frames that are not same-origin with top-level page
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.
Depends on: 1118400
Blocks: 1118400
No longer depends on: 1118400
Priority: -- → P3
Whiteboard: security:passwords
OS: Windows 7 → All
Hardware: x86_64 → All
See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=610997 →
Version: 18 Branch → Trunk

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).

Flags: needinfo?(MattN+bmo)
Priority: P3 → P2
Summary: Don't autofill passwords in frames that are not same-origin with top-level page → Don't autofill logins in frames that are not same-origin with top-level page
Severity: normal → S3
Assignee: nobody → bdanforth
Status: NEW → ASSIGNED
Depends on: 1664585
Flags: needinfo?(mozilla+bmo)
Fission Milestone: --- → M7
Fission Milestone: M7 → ---
Pushed by dluca@mozilla.com: 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

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

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox83: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

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.
  1. Go to https://bugs.mattn.ca/pwmgr/login_and_change_form.html.
  2. 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.
  3. Go to https://mozilla.github.io/form-fill-examples/password_manager/form_with_iframe.html.
  4. 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).
  5. 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.
Flags: qe-verify+
Pushed by bdanforth@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/da72198eabd0 Rename formsProcessed test helpers to accurately reflect when they can be used. r=sfoster

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.

Flags: needinfo?(bdanforth)

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

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.

Flags: needinfo?(bdanforth)

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

Status: RESOLVED → VERIFIED
status-firefox83: fixed → verified
Flags: qe-verify+
Blocks: CVE-2020-26962
No longer depends on: CVE-2020-26962
Whiteboard: security:passwords → [security:passwords][adv-main83+]
Attached file advisory.txt (deleted) —
Regressions: 1691909
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: