Re: CORS Background slides

On Nov 4, 2009, at 4:51 PM, Tyler Close wrote:

> MarkM and I have put together a solution to the challenge problem
> Maciej presented at the Tuesday afternoon TPAC meeting.  The primary
> goal of this design was to preserve both the user interface and
> network communication pattern used in Maciej's CORS-with-Origin
> implementation. As you'll see, the two solutions are almost identical
> from this perspective. See:
>
> http://sites.google.com/site/guestxhr/maciej-challenge

Thanks for posting this. Just to clarify, my presentation wasn't meant  
to pose a challenge problem but merely to clarify some of the  
requirements that led to the design of CORS. However, I think this  
example of meeting the same requirements with a different model is  
very useful input for the WG, so thanks for putting this together.

So here's some specific comments:

1) I believe this scheme works and meets the stated requirements of  
the calendar event scenario.

2) I strongly disagree with the final sentence on that page: "As  
discussed at Tuesday's TPAC meeting, Maciej's solution is vulnerable  
to a CSRF-like attack by Server A on Server B if the "add event" URL  
provided by Server A actually refers to a resource on Server B." The  
scenario I posted does *not* involve Server A providing a URL to  
Server B and does not have a vulnerability. It is true that if you  
change the scenario in certain ways, you can produce one with a  
vulnerability. I would claim that as long as you follow my proposed  
"Don't Be a Deputy" (DBAD)[1] programming discipline, you will not  
introduce Confused Deputy vulnerabilities.

3) The proposed GuestXHR-based protocol does not rely on ambient  
authority except in the initial permission grant (where presumably  
Cookies are used to identify the user to both servers, although this  
is not spelled out).

4) The GuestXHR-based proposal depends on creating a persistent shared  
secret between sites A and B. This introduces risk in the following  
ways:

      a) Server A has to ensure that the shared secret is distinct per  
user and not guessable. This is not trivial. The experience with  
building secret token defenses against CSRF shows that it's not  
unlikely developers will make subtle errors which lead to the secret  
token being guessable.

      b) Both protocols depend on the confidentiality of the user's  
cookie for Server A being maintained. Server A can guarantee this by  
itself, by ensuring physical and data security of its servers, and by  
making the cookie "Secure" and "HttpOnly", to guarantee it is only  
ever transmitted over SSL. With the shared secret though, Server A  
also has to rely on both itself Server B to avoid revealing the shared  
secret. A flaw in security practices on Server B, or simply a mistake  
in sending the shared secret over a non-SSL channel, or to the wrong  
server, create a vulnerability. Such a vulnerability is not possible  
with an HttpOnly Secure Cookie, since there is no way for Server B to  
cause Server A's cookie to be sent to the wrong server.


5) I would summarize the tradeoff between this mechanism for a simple  
cross-site communication scenario vs. the CORS way to do it as follows:

     a) In the CORS-based protocol, if you change the scenario in a  
way that violates the DBAD discipline, you may introduce a CSRF-like  
vulnerability. In other words, making a programming error that  
violates DBAD can introduce a vulnerability into the system.

     b) In the GuestXHR-based protocol, if you make a programming  
error in generating or maintaining the confidentiality of the shared  
secret, you may introduce a CSRF-like vulnerability.


6) Combining the shared secret mechanism with the Origin/Cookie  
mechanism increases overall security of the solution. Then you have to  
make *both* an error in violating DBAD and in management of the shared  
secret to create a vulnerability. Making only one of these mistakes  
will not introduce a CSRF-like vulnerability. Thus, running the  
proposed protocol over XHR2+CORS provides defense in depth relative to  
the GuextXHR-based solution.


Combining 5 and 6, the risk of programming errors with CORS-only  
solutions has to be weighed against the risk of programming errors in  
shared-secret solutions plus the loss of the ability to create defense  
in depth by combining Origin/Cookie checks with a shared secret.



Regards,
Maciej

[1] To recap the DBAD discipline:

Either:
A) Never make a request to a site on behalf of a different site; OR
B) Guarantee that all requests you make on behalf of a third-party  
site are syntactically different from any request you make on your own  
behalf.

In this discipline, "on behalf of" does not necessary imply that the  
third-party site initiated the deputizing interaction; it may include  
requesting information from a third-party site and then constructing a  
request to a different site based on it without proper checking. (In  
general proper checking may not be possible, but making third-party  
requests look different can always be provided for by the protocol.)

Received on Thursday, 5 November 2009 01:58:19 UTC