Re: CORS Background slides

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

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

Yet another note - the access grant protocol (though not the actual  
request protocol) seems to violate the "AJAX UI" requirement.  
Tentatively, I think this could be fixed by doing the POST and  
subsequent redirect in an iframe. But then Server B can't use frame- 
busting or frame-prevention headers to defend itself against  
clickjacking, at least on the grant success page.

Regards,
Maciej

>
> 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:18:24 UTC