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
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
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.
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
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
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
allows changing that attribute on the fly and that capability is used for
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.
to post comments)