Re: CORS Background slides

On Nov 4, 2009, at 6:04 PM, Maciej Stachowiak wrote:

>
> 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.

On second thought - I don't see an obvious way to change the access  
grant to avoid sending the shared secret in the URL of a GET request.  
You can't just change the 303 redirect to a 307, since the original  
post body did not contain the shared secret; and there is no way to  
redirect in a way that changes the POST body. Maybe someone else can  
think of a way to do it.

Another issue: how does Server B defend against a CSRF vulnerability  
in receiving the shared secret from Server A? It seems like a page  
from any server could send it an invalid shared secret at any time,  
thus breaking Server B's ability to access Server A. It seems to me  
that defending against CSRF in passing the shared secret requires  
either an Origin check (to verify that the redirect actually came from  
Server B) or a pre-arranged shared secret between A and B (violating  
the original requirements).

Regards,
Maciej

>
> 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:14:46 UTC