Update: This issue was quietly fixed in IE v11.09 in June 2014.
To improve the user-experience of touch browsing, the
Internet Explorer 11 team made several changes to the password manager feature
of the browser. Internet Explorer 11
fixes several bugs that prevented the browser from properly storing
usernames and passwords for web forms.
By default, Internet Explorer’s autocomplete feature
requires the user undertake an explicit action (typically, clicking into a
username field and selecting a saved username) before the username and password
fields are populated by a stored username and password.
For the further convenience of touch users, IE11 introduces
a new password autofill function,
whereby stored credentials are
automatically inserted into the form fields without user interaction under 5
conditions:
These five restrictions help protect IE11 users from a
variety of
password stealing attacks which have been executed against browsers over the
years.
Unfortunately, the
autofill feature omits an important 6th test:
6.
Credentials must not autofill when the browser is
InPrivate
This omission leads to an Information Disclosure
vulnerability when the user is utilizing the browser’s InPrivate mode. If, while
InPrivate Mode,
a user visits a site for which
they have previously stored a password, that user’s identity is immediately
available to the webpage with no action on the user’s part.
Consider the following scenario:
Begin an InPrivate session and navigate to Google.
After a few privacy-sensitive searches (e.g. "genetic disorder"), click the Images button on the homepage.
But I accidentally clicked twice -- the Images page loaded and replaced the Images button with a You+ button which caught my accidental second click.
At that point, I was navigated to the Google Login page with my information pre-filled:
At this point, Google could associate my private queries with my subsequently autofilled login information, violating my privacy expectations.
1.
Store a password for Google
2.
Launch Internet Explorer in Private Mode and navigate to
https://accounts.google.com/servicelogin?hl=en&continue=https://www.google.com/
3.
Observe: Your credentials are immediately available to the DOM with
no user interaction
Because the IE11 password autofill lacks restriction #6, the user
can be unmasked simply by browsing (intentionally or unwillingly) to any site
for which they have a saved password. Even if the user chooses not to login,
it’s already too late—their credentials have been made available to the script
on the page and thus the user is exposed.
InPrivate’s primary target is “over the shoulder” privacy; the IE
team has declined to address this issue with the explanation that the feature
does not claim to provide any privacy from websites.
However, in practice, over-the-shoulder privacy
is not all Internet
Explorer attempts to provide with InPrivate. That’s why, for instance, InPrivate has
always sent the “DNT” header even though that has nothing to do with “over the
shoulder” scenarios. More importantly, the choices made in the implementation of
InPrivate demonstrate that it was designed to ensure that a user should not
be identifiable when they visit a site InPrivate, even if they’ve visited that
site before. That’s why, when an InPrivate session starts, the session
starts with an empty cookie jar, empty HTML5 storage, and previously cached
responses are not pulled from the WinINET cache. If any of these persistence
behaviors were absent, the user’s privacy would be violated because sites could
use the cookie/storage/cache information as a “token” to associate the InPrivate
instance with a prior, non-private session, and thus potentially “unmask” the
user.
Autofill data acts as a persistent user token which breaks the
isolation between InPrivate traffic and non-private traffic. This isolation came
at a great cost (major development complexity & significant runtime performance
penalty) but it was deemed essential for the feature: it includes isolating the
cache, cookies, and storage. Such isolation isn’t unique to IE; all browsers’
privacy modes enforce such isolation.
It is important to note that InPrivate
intentionally does not prevent the user from reusing
previously-cached AutoComplete data, but that reuse requires an
explicit user action, making it the
equivalent of the user simply reentering the information. Importantly, one of
the security guarantees for AutoComplete is that a site must not be able to
enumerate the user’s AutoComplete history, which prevents an attack whereby such
information could be used to silently or automatically unmask the user.
Microsoft has previously issued patches for MSRC cases when it was discovered
that enumeration-prevention could be bypassed.
Internet Explorer 11 Desktop
Internet Explorer 11 Mobile on WinPhone 8.1 (does not
offer Password Autocomplete while InPrivate)
Internet Explorer 10 (Does not
include autofill feature)
Chrome 32 (Does not autofill while Incognito)
Firefox 28
(Does not autofill in Private Browsing Mode)
if (IEIsInPrivateBrowsing()) return;
March 20 2014 - Reported to MSRC (secure@microsoft.com)
April 11 2014 - MSRC reports that “this will not be patched as a security issue” and
indicates that they have no objection to public release of this report.
June 10 2014- Internet Explorer v11.09 update fixes the issue
(though it's not listed in
the list of
fixes)
©2014 Eric Lawrence. All Rights Reserved.