1623256 - Page steals focus from doorhanger while editing details of a newly saved password

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Florian Stascheck]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

• Register new account on a new website (e.g. https://www.cambridge.org/core/register)
• After form submission, a small popup bubble comes on the left side of the URL input, asking you if you want to save the username & password you just entered
• Click into the username field and start typing a different username from the one auto-suggested
• When the form submission leads to a page load, on finished page loading the username & password UI looses focus

Actual results:

When the form submission leads to a page load, on finished page loading the username & password UI looses focus.

This leads to a website having the focus and receiving your keyboard input for username / password combinations that you just want your browser and a (potentially different) website to know.

Expected results:

The focus should've stayed in the username / password fields.

Comment 1

[:Gijs (out for now; he/him)]

I agree this is problematic from a privacy/security perspective, though I'd also be curious whether this reproduces everywhere or just on websites that "grab" focus. Not 100% sure what we could do about this... Obviously users should be able to move focus out of those textboxes, but websites shouldn't, and I don't think the code inside the popup can easily distinguish those. Neil, do you have ideas?

I'm not 100% sure an attacker could exploit this without the victim website having other underlying issues (like injection allowing the next pageload to be attacker-controlled). But I guess things like opener/parent control could potentially be abused for that, though you'd still need to know when to redirect the load to the target page, which the same origin policy would prevent you from doing. Dan, thoughts about whether this needs to be kept hidden?

Comment 2

[Johann Hofmann [:johannh]]

I'm pretty sure there's a public dupe for this, but I don't have time to find it right now...

Comment 3

[Florian Stascheck]

My reasons to hide it are:

• Developers know that login pages, where users enter their password are more security sensitive than other pages of a web application
• For that reason, they are often not delivered with the same amount of external JS dependencies than normal pages of a site
• That means, that on the page loaded after login, there's a higher chance for some malicious JS being loaded (e.g. as part of ad serving networks etc)
  => This JS could now theoretically record user inputs

Oh, and also, the page could draw the focus to some text input that's not masked when the user expects the input they type to be masked in a password input. In a case where other people are sitting next to them and look at the screen, this can also have unwanted consequences.

Definitely not a high security risk or likely to be exploited (the JS part), but nevertheless I think it has some security implications.

Comment 4

[Neil Deakin]

Content shouldn't be able to steal the focus when chrome is focused, (this was bug 125282), but it likely doesn't work as well in e10s.

Comment 5

[Daniel Veditz [:dveditz]]

Tweaked the summary slightly. Neil's right, a web page should not be able to steal focus from chrome. Is this problem unique to the Password Manager doorhanger, doorhangers in general, or all chrome? The testcase in bug 125282 remains fixed for the url and search boxes.

Although some users might leak some data it not a general vulnerability that needs to be fixed in secret. It's also more likely users will be editing the less sensitive name field (which the site can make "wrong", as in this example) than the password.

Comment 6

[Matthew N. [:MattN]]

(In reply to Daniel Veditz [:dveditz] from comment #5)

Tweaked the summary slightly. Neil's right, a web page should not be able to steal focus from chrome. Is this problem unique to the Password Manager doorhanger, doorhangers in general, or all chrome? The testcase in bug 125282 remains fixed for the url and search boxes.

I suspect it applies to all of them but the password manager is the only one with a text box that I know of so the issue of leaking keystrokes is probably specific to it.

Although some users might leak some data it not a general vulnerability that needs to be fixed in secret. It's also more likely users will be editing the less sensitive name field (which the site can make "wrong", as in this example) than the password.

Agreed.