[whatwg] Limitations of IP addresses into the origin tuple

[Maciej Stachowiak]

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