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

On Jun 27, 2008, at 2:18 PM, Jonas Sicking wrote:

> Hi All!
> There has been recent discussions about how DNS rebinding attacks  
> affect
> Access-Control.
> As I have said in previous emails [1] Access-Control is currently no
> more prone to DNS rebinding attacks than the rest of the existing web
> platform. However, it would still be good if we could harden
> Access-Control such that it is less susceptible to DNS rebinding
> attacks. Partially in order to not make it harder to in the future
> improve the rest of the web platform, partially for any  
> implementations
> of Access-Control which would exist outside of the web platform.
> So I have the following proposal:
> When a preflight OPTIONS request is made, store in the cache what IP
> address was used to make the request. When a subsequent non-GET is  
> made,
> check what IP address the DNS name resolves to, and if the IP  
> address is
> not the same as the one used for the OPTIONS request, re-do the
> preflight OPTIONS check.

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. Also, there may be future client-side  
defenses based on something other than DNS pinning, in which case this  
pinning requirement could be problematic.

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.


Received on Friday, 27 June 2008 23:10:49 UTC