There seems to be some confusion regarding the exact impact of the
location.hostname vulnerability, and the ways to protect against it. I
wanted to offer a quick clarification.
1) Cookie setting (session fixation) attacks can be executed universally
and with no restrictions. This is demonstrated by the originally
provided PoC, and is a serious security threat. A common implication
of such a flaw is that the user can be forced to authenticate within
attacker's session, implanted as a persistent cookie.
WARNING: The attack does not require the browser to interact with
the attacked site in any way. The cookie is set somewhere else and
ahead of the visit. In other words, the fact your site runs IIS does
not make you any more secure. The fact your servers are behind Squid
in a reverse proxy mode has no significance.
Vulnerable *clients* can be protected by a proxy that rejects
requests containing a NUL character; Squid is a good example. A
safer option is to implement the prefs.js workaround recommended on
the test page and in Bugzilla, however... and an updated version of
Firefox should be available tomorrow, anyway.
2) Frame / window manipulation and cookie stealing attacks can be
executed against sites that explicitly set 'document.domain' to an
arbitrary value, even if this occurs only on a single sub-page. Some
high-profile sites do that, others don't. Still, the attack is very
much possible; I prepared a new testcase for non-believers:
http://lcamtuf.dione.cc/ffhostname_cnn.html
3) In my initial advisory, I mistakenly stated that XMLHttpRequest() can
be one of attack vectors. It can't - contrary to some sources, in
Firefox, this mechanism ignores document.domain altogether. You have
to rely on the two methods described above - but that's quite a lot,
anyway.
location.hostname vulnerability, and the ways to protect against it. I
wanted to offer a quick clarification.
1) Cookie setting (session fixation) attacks can be executed universally
and with no restrictions. This is demonstrated by the originally
provided PoC, and is a serious security threat. A common implication
of such a flaw is that the user can be forced to authenticate within
attacker's session, implanted as a persistent cookie.
WARNING: The attack does not require the browser to interact with
the attacked site in any way. The cookie is set somewhere else and
ahead of the visit. In other words, the fact your site runs IIS does
not make you any more secure. The fact your servers are behind Squid
in a reverse proxy mode has no significance.
Vulnerable *clients* can be protected by a proxy that rejects
requests containing a NUL character; Squid is a good example. A
safer option is to implement the prefs.js workaround recommended on
the test page and in Bugzilla, however... and an updated version of
Firefox should be available tomorrow, anyway.
2) Frame / window manipulation and cookie stealing attacks can be
executed against sites that explicitly set 'document.domain' to an
arbitrary value, even if this occurs only on a single sub-page. Some
high-profile sites do that, others don't. Still, the attack is very
much possible; I prepared a new testcase for non-believers:
http://lcamtuf.dione.cc/ffhostname_cnn.html
3) In my initial advisory, I mistakenly stated that XMLHttpRequest() can
be one of attack vectors. It can't - contrary to some sources, in
Firefox, this mechanism ignores document.domain altogether. You have
to rely on the two methods described above - but that's quite a lot,
anyway.
Cheers,
/mz
[ reply ]