- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 28 Jun 2008 14:51:44 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Webapps WG <public-webapps@w3.org>
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 UTC