- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 28 Jun 2008 14:33:33 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Webapps WG <public-webapps@w3.org>
Maciej Stachowiak wrote: > > > 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. 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. > 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. > 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. However, like you say, they need to deploy defenses against this anyway in order to protect themselves against the rest of the web platform. / Jonas
Received on Saturday, 28 June 2008 21:35:03 UTC