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
