Don't save credentials in iframes that are not same-origin with the top-level page
Categories
(Toolkit :: Password Manager, enhancement, P3)
Tracking
()
People
(Reporter: englehardt, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
46.31 KB,
image/png
|
Details |
In Bug 786276 we stopped autofilling credentials in cross-origin iframes. However, we still prompt users to save credentials that are entered into cross-origin iframes, and autofill them when the origin of the iframe is visited directly.
As an example, you can save credentials on this page and observe them being autofilled on this page. Note that even though we allow the iframe's credentials to be saved on the first page, they will never autofill on the first page because of the changes in Bug 786276. Also note that the autofill prompt is misleading, because we aren't saving these credentials under senglehardt.com and will not autofill them on senglehardt.com (see the attached screenshot).
One of the motivations behind stopping cross-origin iframe autofill was to prevent credential data from leaking across websites (see Bug 1658078). If we continue to save credentials from within cross-origin iframes, we will leak those credentials back to the origin of the iframe if it's ever visited directly.
Reporter | ||
Comment 1•4 years ago
•
|
||
Note that I'm not convinced that we want to completely disable this. Some websites may implement their auth on a separate subdomain or entirely different domain than the top-level page. Bug 786276 has made it so we will never autofill on these websites, but if we were to make this change we would also never prompt to save logins for these sites either.
We could consider only prompting the user to save a login if the iframe is same-site, but that won't support sites like example.com
with an iframe from example-auth.com
.
Reporter | ||
Comment 2•4 years ago
|
||
I chatted with Arthur a bit about this and we arrived at the following, which feels like a good compromise between usability + privacy.
For clarity, we have two possible automatic credential filling mechanisms:
- autofill = “fill credentials without any user interaction” from
- manual selection = “fill credentials automatically after the user clicks on their choice”
We could save credentials double-keyed. One key is the origin of the context from which the credentials have been entered (i.e., the credential origin, or the origin to which we currently associate credentials). The new key is the origin on the top-level frame. We autofill credentials using the full doublekey, but we allow manual selection based only on the credential origin.
We could additionally consider adding an "alternate" top-level key to a credential on any top-level page where the user manually selects the credentials. That is, if a user saves credentials for embedded-frame.com
on example.com
and later manually selects them on other-example.com
, we will autofill embedded-frame.com
's credentials both on example.com
and other-example.com
. This keeps a user from missing out if they happen to first save credentials under a top-level origin they rarely interact with, and then manually select them under a top-level origin they frequently interact with.
Comment 3•4 years ago
|
||
It seems possibly questionable that we display the eTLD in the prompt when we are going to explicitly save the login for the full origin. In this case at least this is misleading.
I don't really understand where the leak is here? We save the login with the origin https://test.senglehardt.com, and then when we visit a page on that origin, hosting an iframe with a form/page on the same origin, we autofill the login. That is expected behavior - nothing has been leaked to senglehardt.com unless I'm misunderstanding?
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #3)
I don't really understand where the leak is here? We save the login with the origin https://test.senglehardt.com, and then when we visit a page on that origin, hosting an iframe with a form/page on the same origin, we autofill the login. That is expected behavior - nothing has been leaked to senglehardt.com unless I'm misunderstanding?
This would be a leak once we ship storage partitioning (https://github.com/privacycg/storage-partitioning). Under storage partitioning we partition all state by the top-level site. So if a user enters a set of credentials on senglehardt.com
, we wouldn't expect those credentials to be automatically available to another top-level site (let's say other-site.com
, since test.senglehardt.com
is same-site). Basically the user should have control as to whether credentials entered into an iframe while visiting senglehardt.com
are visible to the origin from which that iframe was served when they later visit it directly. The user choosing to fill the credentials manually is a signal of intent.
Comment 5•4 years ago
|
||
I think the unsolved problem with some of the suggestions in the initial comments is UI. If A embeds B and I manually select my B credentials in B and then some other day visit A that embeds B again, it does seem reasonable to autofill my B credentials based on the past interaction. However, what if I no longer want to associate with A? Is there a way for the user to undo the autofill action so they have to manually select again? (I suppose we could clean that up when we clean up storage for A in general, but making those things clear seems hard.)
Comment 6•4 years ago
|
||
I'll put this in the backlog for now to get it out of the triage list, and we can keep talking about what the impact of storage partitioning on login autofill will be.
Updated•4 years ago
|
Description
•