Re: CORS Background slides

I forgot to mention another shared secret management risk with the  
proposed GuestXHR-based protocol. The protocol involves passing the  
shared secret in URLs, including URLs that will appear in the  
browser's URL field. URLs should not be considered confidential -  
there have a high tendency to get inadvertently exposed to third  
parties. Some of the ways this happens include caching layers, the  
browser history (particularly shared sync of the browser history), and  
users copying URLs out of the URL field without considering whether  
this particular URL contains a secret.

I believe this can be fixed by always transmitting the shared secret  
in the body of an https POST rather than as part of the URL, so this  
risk is not intrinsic to this style of protocol.

Regards,
Maciej

On Nov 4, 2009, at 5:57 PM, Maciej Stachowiak wrote:

>
> 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 02:04:43 UTC