The Firefox password manager vulnerability

A commonly used convenience feature in Firefox is the password manager (PM) which can keep track of username/password pairs for sites that one visits and fills in when a new login is required. Unfortunately, as a recent bug report shows, PM can be too helpful and provide that information to other sites, invisibly to the user. As of this writing, the underlying browser problem has not been fixed, though MySpace (where the problem was originally discovered in the wild) has changed its filtering of user-supplied HTML to avoid the problem.

When visiting a site with a login form, Firefox checks its list of stored credentials to see if it has a set matching those requested by the page. How it makes that decision is the crux of the vulnerability. Currently, it looks at the domain name portion of the URL and the input field names in the login form to see if there is a match. If there is just one match, it automatically fills in the username and password and the user can just press the "Login" button to authenticate. If there are more matches, the username becomes a drop-down containing all of the possibilities. When a particular username is chosen, the associated password is filled in.

Under normal circumstances, this works fine, but attackers are always willing to alter the underlying assumptions; that is what has occurred here. For sites like MySpace that allow users to put HTML into their pages, someone with malicious intent can mimic the MySpace login page on their own page; Firefox will happily fill in the blanks on the spoofed page. Users might well believe that they had been logged off for some reason and press the login button which will then provide the credentials to whatever URL the ACTION attribute of the form points to. This new kind of attack has been called a Reverse Cross-site Request (RCSR) by Robert Chapin, who reported the Firefox bug.

This mechanism has much in common with standard phishing techniques, in that it tricks the user into sending their passwords to the attacker, but it has a few twists. A typical phishing site will not have a matching entry in the PM and therefore Firefox will not automatically fill in the form. In addition, there is no reason that the username and password fields need be visible for this attack to work; by using CSS or absolute positioning, the attacker may be able to hide the fields from the user but Firefox will happily fill them in anyway. The user will believe they are submitting a benign, unrelated form, when, in fact, they are providing their credentials to an attacker.

Other browsers are susceptible to this attack as well, but because of some user interface differences, the impact is lessened. Opera provides a 'magic wand' icon that a user can press when they want to provide their credentials to a matching site; IE7 requires one to choose the username from a drop-down (even if there is only one choice), unless the URL is exactly the same as the one stored with the password. These differences alleviate the problem with invisible form fields, but could still be used by login form mimics to trap the unwary.

The discussion of possible fixes in the bug report is instructive as there is no real panacea for this problem on the browser side. Several of the comments maintain that it is completely a server-side issue and that sites must take steps to insure that what they serve does not contain this kind of content. Unfortunately for Firefox users and developers, that simplistic approach will not suffice. The root of the problem lies in what portion of a URL is considered significant for identifying a specific site to attach credentials to in the PM.

It is interesting to note, while one is traversing the web, the different ways one can end up on a login page and the different URLs that lead to them. One way to ensure that RCSR cannot occur is to require that the URL stored with the password match exactly with the URL of the requesting page before filling in credentials. This test will break on a wide variety of web sites because they attach various parameters to the URL (navigation information for example) and doing that check would seriously degrade the usefulness of the PM. A less severe check could match the URL up to the start of any parameters, but there are some sites that use different hosts and paths for handling credentials and a user would have to store a password for each of these URLs. Checking the ACTION attribute of the form being submitted has been suggested as a potential solution, but javascript allows changing that attribute on the fly and that capability is used for legitimate reasons.

It is unclear what direction the Firefox team will take in fixing this problem, but it seems likely to require some user interface change (like Opera or IE7) so that some kind of user interaction is required before credentials are filled in. It may also include stricter checking of the page and/or action URLs before deciding to fill in credentials. Pop-up warnings for content that fails these checks has been suggested as a solution, but it is hard to envision users paying any more attention to a new warning than they have to any of the current ones. There is a delicate balance for the developers to maintain between security and convenience, especially when considering the behavior that users have come to expect.

It is hard to imagine that most users, when storing their passwords, would expect Firefox to send them off to phishing sites without any kind of user interaction and without providing any visual indication that it is doing so. Website operators should certainly be doing better filtering, but the browser is the agent that the user has entrusted with their passwords. Claiming that there is no browser issue is a serious misunderstanding of user expectations when they store passwords.

Bear in mind, that if the user has been brought to a "poser" web site, no password manager
client-side bug is gonna matter if he/she is clicking "OK" anyway. The data has been
deliberately sent (ie. exposed). The client maintained list is not, in and of itself,
compromised. The hidden form field phishing is a bit less culpable for the client. Simplest
solution might be to add a "paranoia" setting to the PM that presents a DB exposing the fqdn
about to receive the sensitive submission asking "Are you sure this is a valid authentication
request?<continue><cancel>
The onus is on the user to double check the validity of the transaction one last time.
IMHO, any truly sensitive authentication should be using encrypted transmission with mutual
trust verification anyway, or the user should seriously consider doing business elsewhere.