On Jan 10, 2008, at 1:21 PM, Ian Hickson wrote:
On Thu, 10 Jan 2008, Collin Jackson wrote:
As I understand it, that kind of attack would be mitigated by the
browser not doing a DNS query for the second one -- it's the reason
browsers tend to have built-in DNS caches (with TTLs in the order
of a
minute).
The problem is that browser caches can have TTLs on the order of
hours
or days, while it is not realistic to cache DNS entries for that
long.
This leads to the following attack:
1) http://www.attacker.com/foo/attack.html is served from attacker,
includes lib.js
2) http://www.attacker.com/foo/lib.js is served from attacker with an
"Expires" header 24 hours in the future
3) Attacker waits for browser DNS cache to expire.
4) User is redirected to http://www.attacker.com/foo/baz.html, which
is served from target
5) http://www.attacker.com/foo/lib.js is served from the browser's
cache and is now in the target's origin
Yeah, I don't know of a good solution to that when the victim site
uses
HTTP/1.0. (With 1.1, you can mitigate it by checking Host headers.)
Actually, checking that the "Host" header value is as expected is
pretty much a complete server-side defense to DNS rebinding. (HTTP 1.0
requests don't matter since user agents in common use don't send
them.) Sites on the public internet are generally not vulnerable,
since the only vulnerability created by DNS rebinding is access to
resources where position on the network is the sole authentication
credential (i.e. intranet sites). And intranet sites rarely use
virtual hosting, so there's only one correct Host value.
A form of client-side mitigation that would be highly effective would
be to pin hostname to IP mappings so long as any resource from a
hostname is live in any cache (including disk caches). But this would
prevent DNS-based load balancers from doing their job and would create
problems if a site changes its IP address permanently but previously
handed out resources with long expiration dates (very common for
scripts).
The idea with origins containing IP addresses is to avoid attacks
like
where a page on attacker.com does a window.open() to another page on
attacker.com where the second page is served from the victim IP, and
scripts in the first page then do cross-window manipulation.
After using the technique above, the attacker can window.open to
another
page on attacker.com and do cross-window manipulation.
After using the technique above, the attacker doesn't need to use
window.open(). The technique above boils down to arbitrary content
injection, at which point the victim has lost and the game is over.
It's not exactly content injection, since the browser thinks the
security origin is attacker.com, not victim.com. So for example
there's no way to get victim.com cookies, stored http or form
passwords, or resources protected by such. All you can do is access
content from the victim.com IP address that the user agent has access
to but your server doesn't.
Regards,
Maciej
