CORS Background slides

[Maciej Stachowiak]

These are the slides I showed at today's CORS session.

Keynote version:






PDF version:






The flow diagram I made for OAuth has at least one known bug, and I  
believe it probably oversimplifies other details.

Regards,
Maciej

[Tyler Close]

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

This email completes ACTION-442:

http://www.w3.org/2008/webapps/track/actions/442

--Tyler

On Tue, Nov 3, 2009 at 4:34 PM, Maciej Stachowiak <mjs@...> wrote:
> These are the slides I showed at today's CORS session.
>
> The flow diagram I made for OAuth has at least one known bug, and I believe
> it probably oversimplifies other details.

[Maciej Stachowiak]

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

[Maciej Stachowiak]

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

[Maciej Stachowiak]

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

[Maciej Stachowiak]

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

[Tyler Close]

Hi Maciej,

Thanks for the many responses. I'll try to get to them all shortly,
but I'd like to start by clarifying one point...

On Wed, Nov 4, 2009 at 5:57 PM, Maciej Stachowiak <mjs@...> wrote:
> On Nov 4, 2009, at 4:51 PM, Tyler Close wrote:
> 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.

How does Server B get the URL if not from Server A? The URL is
supposed to refer to a resource on Server A, so only Server A can
provide its value. Somehow, Server B must get the URL from Server A.
That communication, however it is done, is vulnerable to a CSRF-like
attack.

--Tyler

[Maciej Stachowiak]

On Nov 4, 2009, at 8:20 PM, Tyler Close wrote:

> Hi Maciej,
>
> Thanks for the many responses. I'll try to get to them all shortly,
> but I'd like to start by clarifying one point...

Sorry that there were so many - I thought of a number of additional  
points after sending my initial response. I also discussed your  
protocol and my comments with Adam Barth.

>
> On Wed, Nov 4, 2009 at 5:57 PM, Maciej Stachowiak <mjs@...>  
> wrote:
>> On Nov 4, 2009, at 4:51 PM, Tyler Close wrote:
>> 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.
>
> How does Server B get the URL if not from Server A? The URL is
> supposed to refer to a resource on Server A, so only Server A can
> provide its value. Somehow, Server B must get the URL from Server A.
> That communication, however it is done, is vulnerable to a CSRF-like
> attack.

1) Server B can have a list of URLs for the most popular servers that  
provide Server-A-like services (this is what happens most commonly in  
practice). In this case the URL is provided by the operator of Server B.

2) Server B can allow the user to input an additional URL that's not  
on its list. This can be as simple as accepting a domain name and  
having a convention for where on that host the service lives. In this  
case, the URL is provided by the user (possibly in abbreviated form).  
Server B could in addition sanity check this URL to verify that it  
doesn't refer to itself.

I don't believe these methods are vulnerable to a CSRF-like attack.  
Certainly not method 1. Method 2 could be if the user has to copy a  
full URL from Server A and does not take note of the host in this URL.  
But even that could be avoided if the user only types a hostname.

Regards,
Maciej

[Jonas Sicking-2]

On Wed, Nov 4, 2009 at 5:57 PM, Maciej Stachowiak <mjs@...> wrote:

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

One simple way of allowing websites to do B would be to provide a
GuestXHR object (I'm not exited about the name, but I won't suggest
alternatives right now in order to avoid bikeshed discussions). I.e.
if browsers provided a GuestXHR object, then sites could use that
whenever they acted as a deputy. This would be my recommendation at
this stage.

This would also allow sites to choose between two security models, one
based on principal information being added to the request, one based
on secret tokens passed around.

The requirements on the GuestXHR object would be:
1. Never include any information identifying either the user or the
site making the request. I.e. no Origin, referrer, cookies, http-auth,
client side certs, etc.
2. If the request is cross site, the target site has to opt in to
allowing the result to be returned to the requester. This is in order
to protect data behind firewalls.

/ Jonas

[Jonas Sicking-2]

On Wed, Nov 4, 2009 at 6:04 PM, Maciej Stachowiak <mjs@...> 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.

What about headers? We could allocate a specific header which is
allowed to be set for cross site requests.

/ Jonas

[Maciej Stachowiak]

On Nov 4, 2009, at 9:05 PM, Jonas Sicking wrote:

> On Wed, Nov 4, 2009 at 6:04 PM, Maciej Stachowiak <mjs@...>  
> 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.
>
> What about headers? We could allocate a specific header which is
> allowed to be set for cross site requests.

Sending headers in cross-site requests would not help in the case  
where the proposed protocol sends the secret in the URI of a GET  
request. It's sending that as a redirect from an ordinary page load,  
and the page targeted by the redirect has no access to its own headers.

Regards,
Maciej

[Maciej Stachowiak]

On Nov 4, 2009, at 9:01 PM, Jonas Sicking wrote:

> On Wed, Nov 4, 2009 at 5:57 PM, Maciej Stachowiak <mjs@...>  
> wrote:
>> [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.)
>
> One simple way of allowing websites to do B would be to provide a
> GuestXHR object (I'm not exited about the name, but I won't suggest
> alternatives right now in order to avoid bikeshed discussions). I.e.
> if browsers provided a GuestXHR object, then sites could use that
> whenever they acted as a deputy. This would be my recommendation at
> this stage.
>
> This would also allow sites to choose between two security models, one
> based on principal information being added to the request, one based
> on secret tokens passed around.
>
> The requirements on the GuestXHR object would be:
> 1. Never include any information identifying either the user or the
> site making the request. I.e. no Origin, referrer, cookies, http-auth,
> client side certs, etc.
> 2. If the request is cross site, the target site has to opt in to
> allowing the result to be returned to the requester. This is in order
> to protect data behind firewalls.

I do think that a way to do an anonymous XHR is justified (I think  
AnonXMLHttpRequest would be a better name than GuestXMLHttpRequest).  
At the very least it is useful for a page hosting untrusted guest code  
that's been processed with a tool like Caja.

It's not required to do (B), and I'm not sure it's always the best way  
to do (B). It depends on the particulars of the situation. In some  
cases, you can simply name the commands for cross-domain access  
differently and then the Origin and Cookie are useful additional  
information to help provide defense in depth. This email includes a  
worked example: <http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0491.html 
 >. I believe in the example I gave, Origin+Cookie provide defense in  
depth because they simplify the process of obtaining one-time secret  
tokens, and mitigate the risk inherent to maintaining a long-term  
shared secret.

I don't think we need to debate whether to provide anonymous cross-
site XHR (with sufficient defenses). I think the question is whether  
we should also abandon CORS and remove the existing implementations. I  
continue to think the answer to that latter question is "no".

Regards,
Maciej

[Tyler Close]

On Wed, Nov 4, 2009 at 5:57 PM, Maciej Stachowiak <mjs@...> wrote:

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

Just to clarify the terminology, if the shared secret leaked, the
resulting attack would not be CSRF-like, but rather would be a direct
use of a stolen secret key. The situation is analogous to an attacker
somehow reading the victim site's cookies in solution a), and then
making direct use of them. In a CSRF-like attack, the attacker never
obtains direct knowledge of a secret key, but instead causes a deputy
to issue requests on behalf of the attacker.

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

I'm still unclear on how you intend to provide defense in depth by
using Origin. You are right that there's more that can be done to
reduce the risk of programming with shared-secrets though. A lot can
be done without any browser support. For example, see the security
model for my web_send JavaScript library:

http://waterken.sourceforge.net/web_send/#securityModel

In this library, shared secrets are held in URLs, which are in turn
only exposed to JavaScript code as opaque objects. Since the
JavaScript code never gets direct access to the shared secrets, it is
unable to accidentally, or even maliciously, leak the secrets. There's
no need to study this library for the purposes of this discussion. It
just provides an example of how programming with shared secrets can be
made pleasant and safe.

--Tyler

--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

[Tyler Close]

I've updated the web page that describes the calendar access grant. See:

http://sites.google.com/site/guestxhr/maciej-challenge

More comments inline below...

On Wed, Nov 4, 2009 at 6:14 PM, Maciej Stachowiak <mjs@...> wrote:

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

Personally, I think including a secret in a URL is a fine technique,
but if you want to avoid it, you could instead return a 200 response
in step 4 and have JavaScript in the page do an automated form
submission with the secret in the body of the POST request.

For those interested, I've argued in favor of secret token in the URL at:

http://waterken.sf.net/web-key

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

.. assuming Server B is willing to silently overwrite its current
state with the new invalid secret. That would be a poor choice. For
clarity, I've expanded the description of what Server B could do to
avoid such attack scenarios.

--Tyler

--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html