W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: [AC] Hardening against DNS rebinding attacks - proposal

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 28 Jun 2008 14:51:44 -0700
Cc: Webapps WG <public-webapps@w3.org>
Message-Id: <6DA0B8C8-0326-4022-8641-E20B1F702EC4@apple.com>
To: Jonas Sicking <jonas@sicking.cc>


On Jun 28, 2008, at 2:33 PM, Jonas Sicking wrote:

> Maciej Stachowiak wrote:
>> On Jun 27, 2008, at 2:18 PM, Jonas Sicking wrote:
>> What is the threat model this defends against? Since any server  
>> using Access-Control that does not check HOST is vulnerable to a  
>> conventional XHR DNS rebinding attack. If browsers provide defense  
>> against DNS rebinding through some form of DNS pinning they can  
>> apply it to Access-Control too, but I don't understand the benefit  
>> of pinning only for Access-Control.
>
> To some extent I agree.
>
> It does provide protection for Access-Control implementations  
> outside of
> the web-platform. And for vendors that have expressed concern about
> deploying the spec without DNS protection (such as microsoft) this  
> could
> be an alternative.

Vendors that wanted to do an IP-based restriction already can (unless  
the spec language somehow makes using the cached OPTIONS result  
mandatory, which it should not).

I'm not sure what you mean by "Access-Control implementations outside  
of the web-platform". Can you describe a specific scenario where this  
mechanism would actually be an effective defense?

>
>> Also, there may be future client-side defenses based on something  
>> other than DNS pinning, in which case this pinning requirement  
>> could be problematic.
>
> This is technically not DNS pinning. But one possibility would be to  
> add
> language to say that if a client deploys some other type of defense
> against DNS rebinding attacks, then this section of the spec is  
> optional.

I think it should be optional in any case. Since, as you admit, it is  
an ineffective defense in the browser context (I assume this is what  
you mean by "outside of the web-platform"), I don't want to waste  
engineering time and security review time implementing it. I would  
rather save that for effective defenses. I think it would be wrong for  
the spec to mandate a security policy that does not provide any actual  
protection.

In general I am concerned that we are adding a lot of complexity to  
the spec to supposedly improve security but the measures in question  
seem ineffective. This will significantly increase cost of deployment  
and the risk of implementation error, and that may end up harming  
security instead of helping.

I think any security measure added to the spec must be justified with  
a real threat model and an explanation of how it would defend against  
the threat.

>
>> Since this is a lot of client implementation complexity and may  
>> generate extra traffic in the face of DNS-based load balancers, I'd  
>> like to understand the benefit we get for this cost.
>>> This requires no changes on the server side. It does call for a  
>>> somewhat
>>> more complex solution on the client side.
>>>
>>> Also note that a server can (and should for reasons other than  
>>> Access-Control) protect itself from DNS rebinding attacks by  
>>> checking the 'Host' header.
>> Given this very simple total server-side defense, I am leery of  
>> adding a complex (and ultimately ineffective) client-side mitigation.
>
> This unfortunately only works for servers that are accessed through a
> DNS name, this is commonly not the case for for example personal  
> routers
> with builtin firewalls.

How are such servers accessed instead? By IP address? (If so, wouldn't  
the IP address be in the Host header?)

Regards,
Maciej
Received on Saturday, 28 June 2008 21:52:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:26 GMT