- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 28 Jun 2008 15:32:07 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Webapps WG <public-webapps@w3.org>
Maciej Stachowiak wrote: > > > 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). Reading the letter of the spec I'm not sure that it's currently allowed. However we should loosen this in the conformance criteria section. We should additionally allow for things like refusing to let internet sites connect to private IP addresses (something we hope to implement in future firefox releases), or other general security policies that UAs have. > 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? In a browser that doesn't support the features that are currently prone to DNS rebinding attacks. This includes things like same-site XHR and <iframe>s (and arguably <script>). >>>> 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? Yes. > (If so, wouldn't > the IP address be in the Host header?) Looking at rfc2616 it looks like the Host header is empty when a connection is made using IP addresses. Though I realized that in the DNS-Rebinding scenario the Host header should contain the DNS name of the attacking site, which the firewall could use to detect the attack. Unfortunately it seems that in reality many don't. / Jonas
Received on Saturday, 28 June 2008 22:33:35 UTC