CSRF vulnerability in Tyler's GuestXHR protocol?

[Adam Barth-5]

Hi Tyler,

I've been trying to understand the GuestXHR protocol you propose for
replacing CORS:

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

I don't understand the message in step 5.  It seems like it might have
a CSRF vulnerability.  More specifically, what does the server do when
it receives a GET request for https://B/got?A=secret123?

The slides say "Associate user,A with secret123."  That sounds like
server B changes state to associate secret123 with the the pair (user,
A).  What stops an attacker from forging a cross-site request of the
form https://B/got?A=evil123?  Won't that overwrite the association?
There doesn't seem to be anything in the protocol that binds the "A"
in that message to server A.  (Of course, we could use the Origin
header to do that, but we're assuming that the Origin header isn't
present.)

More generally, how does B know the message https://B/got?A=secret123
has anything to do with "user"?  There doesn't seem to be anything in
the message identifying the user.  (Of course, we could use cookies to
do that, but we're assuming the cookie header isn't present.)

Can you help me understand how the protocol works?

Thanks,
Adam

P.S., It also seems that the protocol does not comply with the HTTP
specification because the server changes state in response to a GET
request.  Presumably, you mean to use a 307 redirect and a POST
request.  Unfortunately, that means the protocol will generate a
warning dialog in Firefox and will fail completely in Safari 4.

[Tyler Close]

Hi Adam,

Responses inline below...

On Thu, Nov 5, 2009 at 8:56 AM, Adam Barth <w3c@...> wrote:

> Hi Tyler,
>
> I've been trying to understand the GuestXHR protocol you propose for
> replacing CORS:
>
> http://sites.google.com/site/guestxhr/maciej-challenge
>
> I don't understand the message in step 5.  It seems like it might have
> a CSRF vulnerability.  More specifically, what does the server do when
> it receives a GET request for https://B/got?A=secret123?

Think of the resource at /got as like an Inbox for accepting an "add
event" permission from anyone. The meta-variable "A" in the query
string, along with the secret, is the URL to send events to. So a
concrete request might look like:

GET /got?site=https%3%2F%2Fcalendar.example.com&s=secret123
Host: upcoming.example.net

When upcoming.example.net receives this request, it might:

1) If no association for the site exists, add it
2) If an existing association for the site exists respond with a page
notifying the user of the collision and asking if it should overwrite
or ignore.

Notice that step 6 is a response from Site B back to the user's browser.

Alternatively, the response in step 6 could always be a confirmation
page asking the user to confirm any state change that is about to be
made. So, the page from the upcoming event site might say:

"I just received a request to add a calendar to your profile. Did you
initiate this request? <yes> <no>"

Note that such a page would also be a good place to ask the user for a
petname for the new capability, if you're into such things, but I
digress...

> The slides say "Associate user,A with secret123."  That sounds like
> server B changes state to associate secret123 with the the pair (user,
> A).  What stops an attacker from forging a cross-site request of the
> form https://B/got?A=evil123?

In the design as presented, nothing prevents this. I considered the
mitigation presented above sufficient for Maciej's challenge. If
desired, we could tighten things up, without resorting to an Origin
header, but I'd have to add some more stuff to the explanation.

>  Won't that overwrite the association?

That seems like a bad idea.

> There doesn't seem to be anything in the protocol that binds the "A"
> in that message to server A.

The "A" is just the URL for server A.

> More generally, how does B know the message https://B/got?A=secret123
> has anything to do with "user"?  There doesn't seem to be anything in
> the message identifying the user.  (Of course, we could use cookies to
> do that, but we're assuming the cookie header isn't present.)

This request is just a normal page navigation, so cookies and such
ride along with the request. In the diagrams, all requests are normal
navigation requests unless prefixed with "GXHR:".

We used these normal navigation requests in order to keep the user
interface and network communication diagram as similar to Maciej's
solution as possible. If I were approaching this problem without that
constraint, I might do things differently, but that wasn't the goal of
this exercise.

> Can you help me understand how the protocol works?

My pleasure. Please send along any follow up questions.

(I would have chosen a different Subject field for these questions though)

> P.S., It also seems that the protocol does not comply with the HTTP
> specification because the server changes state in response to a GET
> request.  Presumably, you mean to use a 307 redirect and a POST
> request.  Unfortunately, that means the protocol will generate a
> warning dialog in Firefox and will fail completely in Safari 4.

I just said 303 because it was the most succinct way of expressing the
relevant part of the communication. In deployment, a better solution
would be to send back a normal 200 response with JavaScript code that
does an automated form POST of the same data to Server B.

--Tyler

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

[Adam Barth-5]

You seem to be saying that your description of the protocol is not
complete and that you've left out several security-critical steps,
such as

1) The user interface for confirming transactions.
2) The information the server uses to figure out which users it is talking to.

Can you please provide a complete description of your protocol with
all the steps required?  I don't see how we can evaluate the security
of your protocol without such a description.

Thanks,
Adam


On Thu, Nov 5, 2009 at 12:05 PM, Tyler Close <tyler.close@...> wrote:

> Hi Adam,
>
> Responses inline below...
>
> On Thu, Nov 5, 2009 at 8:56 AM, Adam Barth <w3c@...> wrote:
>> Hi Tyler,
>>
>> I've been trying to understand the GuestXHR protocol you propose for
>> replacing CORS:
>>
>> http://sites.google.com/site/guestxhr/maciej-challenge
>>
>> I don't understand the message in step 5.  It seems like it might have
>> a CSRF vulnerability.  More specifically, what does the server do when
>> it receives a GET request for https://B/got?A=secret123?
>
> Think of the resource at /got as like an Inbox for accepting an "add
> event" permission from anyone. The meta-variable "A" in the query
> string, along with the secret, is the URL to send events to. So a
> concrete request might look like:
>
> GET /got?site=https%3%2F%2Fcalendar.example.com&s=secret123
> Host: upcoming.example.net
>
> When upcoming.example.net receives this request, it might:
>
> 1) If no association for the site exists, add it
> 2) If an existing association for the site exists respond with a page
> notifying the user of the collision and asking if it should overwrite
> or ignore.
>
> Notice that step 6 is a response from Site B back to the user's browser.
>
> Alternatively, the response in step 6 could always be a confirmation
> page asking the user to confirm any state change that is about to be
> made. So, the page from the upcoming event site might say:
>
> "I just received a request to add a calendar to your profile. Did you
> initiate this request? <yes> <no>"
>
> Note that such a page would also be a good place to ask the user for a
> petname for the new capability, if you're into such things, but I
> digress...
>
>> The slides say "Associate user,A with secret123."  That sounds like
>> server B changes state to associate secret123 with the the pair (user,
>> A).  What stops an attacker from forging a cross-site request of the
>> form https://B/got?A=evil123?
>
> In the design as presented, nothing prevents this. I considered the
> mitigation presented above sufficient for Maciej's challenge. If
> desired, we could tighten things up, without resorting to an Origin
> header, but I'd have to add some more stuff to the explanation.
>
>>  Won't that overwrite the association?
>
> That seems like a bad idea.
>
>> There doesn't seem to be anything in the protocol that binds the "A"
>> in that message to server A.
>
> The "A" is just the URL for server A.
>
>> More generally, how does B know the message https://B/got?A=secret123
>> has anything to do with "user"?  There doesn't seem to be anything in
>> the message identifying the user.  (Of course, we could use cookies to
>> do that, but we're assuming the cookie header isn't present.)
>
> This request is just a normal page navigation, so cookies and such
> ride along with the request. In the diagrams, all requests are normal
> navigation requests unless prefixed with "GXHR:".
>
> We used these normal navigation requests in order to keep the user
> interface and network communication diagram as similar to Maciej's
> solution as possible. If I were approaching this problem without that
> constraint, I might do things differently, but that wasn't the goal of
> this exercise.
>
>> Can you help me understand how the protocol works?
>
> My pleasure. Please send along any follow up questions.
>
> (I would have chosen a different Subject field for these questions though)
>
>> P.S., It also seems that the protocol does not comply with the HTTP
>> specification because the server changes state in response to a GET
>> request.  Presumably, you mean to use a 307 redirect and a POST
>> request.  Unfortunately, that means the protocol will generate a
>> warning dialog in Firefox and will fail completely in Safari 4.
>
> I just said 303 because it was the most succinct way of expressing the
> relevant part of the communication. In deployment, a better solution
> would be to send back a normal 200 response with JavaScript code that
> does an automated form POST of the same data to Server B.
>
> --Tyler
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>

[Tyler Close]

I've elaborated on the example at:

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

I've tried to include all the information from our email exchange.
Please let me know what parts of the description remain ambiguous.

Just so that we're on the same page, the prior description was only
meant to give the reader enough information to see that the scenario
is possible to implement under Maciej's stated constraints. I expected
the reader to fill in their favored technique where that choice could
be done safely in many ways. Many of the particulars of the design
(cookies vs URL arguments, 303 vs automated form post, UI for noting
conflicts) can be done in several different ways and the choice isn't
very relevant to the current discussion. All that said, I'm happy to
fill out the scenario with as much detail as you'd like, if that helps
us reach an understanding.

--Tyler

On Thu, Nov 5, 2009 at 8:31 PM, Adam Barth <w3c@...> wrote:

> You seem to be saying that your description of the protocol is not
> complete and that you've left out several security-critical steps,
> such as
>
> 1) The user interface for confirming transactions.
> 2) The information the server uses to figure out which users it is talking to.
>
> Can you please provide a complete description of your protocol with
> all the steps required?  I don't see how we can evaluate the security
> of your protocol without such a description.
>
> Thanks,
> Adam
>
>
> On Thu, Nov 5, 2009 at 12:05 PM, Tyler Close <tyler.close@...> wrote:
>> Hi Adam,
>>
>> Responses inline below...
>>
>> On Thu, Nov 5, 2009 at 8:56 AM, Adam Barth <w3c@...> wrote:
>>> Hi Tyler,
>>>
>>> I've been trying to understand the GuestXHR protocol you propose for
>>> replacing CORS:
>>>
>>> http://sites.google.com/site/guestxhr/maciej-challenge
>>>
>>> I don't understand the message in step 5.  It seems like it might have
>>> a CSRF vulnerability.  More specifically, what does the server do when
>>> it receives a GET request for https://B/got?A=secret123?
>>
>> Think of the resource at /got as like an Inbox for accepting an "add
>> event" permission from anyone. The meta-variable "A" in the query
>> string, along with the secret, is the URL to send events to. So a
>> concrete request might look like:
>>
>> GET /got?site=https%3%2F%2Fcalendar.example.com&s=secret123
>> Host: upcoming.example.net
>>
>> When upcoming.example.net receives this request, it might:
>>
>> 1) If no association for the site exists, add it
>> 2) If an existing association for the site exists respond with a page
>> notifying the user of the collision and asking if it should overwrite
>> or ignore.
>>
>> Notice that step 6 is a response from Site B back to the user's browser.
>>
>> Alternatively, the response in step 6 could always be a confirmation
>> page asking the user to confirm any state change that is about to be
>> made. So, the page from the upcoming event site might say:
>>
>> "I just received a request to add a calendar to your profile. Did you
>> initiate this request? <yes> <no>"
>>
>> Note that such a page would also be a good place to ask the user for a
>> petname for the new capability, if you're into such things, but I
>> digress...
>>
>>> The slides say "Associate user,A with secret123."  That sounds like
>>> server B changes state to associate secret123 with the the pair (user,
>>> A).  What stops an attacker from forging a cross-site request of the
>>> form https://B/got?A=evil123?
>>
>> In the design as presented, nothing prevents this. I considered the
>> mitigation presented above sufficient for Maciej's challenge. If
>> desired, we could tighten things up, without resorting to an Origin
>> header, but I'd have to add some more stuff to the explanation.
>>
>>>  Won't that overwrite the association?
>>
>> That seems like a bad idea.
>>
>>> There doesn't seem to be anything in the protocol that binds the "A"
>>> in that message to server A.
>>
>> The "A" is just the URL for server A.
>>
>>> More generally, how does B know the message https://B/got?A=secret123
>>> has anything to do with "user"?  There doesn't seem to be anything in
>>> the message identifying the user.  (Of course, we could use cookies to
>>> do that, but we're assuming the cookie header isn't present.)
>>
>> This request is just a normal page navigation, so cookies and such
>> ride along with the request. In the diagrams, all requests are normal
>> navigation requests unless prefixed with "GXHR:".
>>
>> We used these normal navigation requests in order to keep the user
>> interface and network communication diagram as similar to Maciej's
>> solution as possible. If I were approaching this problem without that
>> constraint, I might do things differently, but that wasn't the goal of
>> this exercise.
>>
>>> Can you help me understand how the protocol works?
>>
>> My pleasure. Please send along any follow up questions.
>>
>> (I would have chosen a different Subject field for these questions though)
>>
>>> P.S., It also seems that the protocol does not comply with the HTTP
>>> specification because the server changes state in response to a GET
>>> request.  Presumably, you mean to use a 307 redirect and a POST
>>> request.  Unfortunately, that means the protocol will generate a
>>> warning dialog in Firefox and will fail completely in Safari 4.
>>
>> I just said 303 because it was the most succinct way of expressing the
>> relevant part of the communication. In deployment, a better solution
>> would be to send back a normal 200 response with JavaScript code that
>> does an automated form POST of the same data to Server B.
>>
>> --Tyler
>>
>> --
>> "Waterken News: Capability security on the Web"
>> http://waterken.sourceforge.net/recent.html
>>
>

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

[Adam Barth-5]

Thanks for clarifying your protocol.  How does this protocol compare
to OAuth?  The two appear to be solving the same problem with the same
set of constraints.  I ask because OAuth has had a series of subtle
security vulnerabilities that eluded early security folks who analyzed
the protocol.

I'm still concerned about CSRF in Step 5.  In particular, the scenario
I'm worried about is as follows:

1) The user initiates the protocol with an honest site A.
2) The web attacker interrupts the protocol during Step 3 or Step 4
(e.g., by navigating the top-level browser context in which the
protocol is taking place).
3) The web attacker forges a cross-site request to B, altering the
parameters supplied in Step 5.
4) The user doesn't pay that much attention to confirmation page and
approves the request.

We could run a usability study, but I suspect that relying on the user
to properly confirm the transaction is not a good security assumption.
 This protocol has the flavor of user account control (UAC) in Vista,
in which the user is prompted to confirm transactions immediately
after initiating the transaction.

It seems like Maciej's protocol addresses this use case more securely.
 Notice that Maciej's protocol has half the number of messages and
does not require user confirmation.

Adam


On Tue, Nov 10, 2009 at 11:50 AM, Tyler Close <tyler.close@...> wrote:

> I've elaborated on the example at:
>
> http://sites.google.com/site/guestxhr/maciej-challenge
>
> I've tried to include all the information from our email exchange.
> Please let me know what parts of the description remain ambiguous.
>
> Just so that we're on the same page, the prior description was only
> meant to give the reader enough information to see that the scenario
> is possible to implement under Maciej's stated constraints. I expected
> the reader to fill in their favored technique where that choice could
> be done safely in many ways. Many of the particulars of the design
> (cookies vs URL arguments, 303 vs automated form post, UI for noting
> conflicts) can be done in several different ways and the choice isn't
> very relevant to the current discussion. All that said, I'm happy to
> fill out the scenario with as much detail as you'd like, if that helps
> us reach an understanding.
>
> --Tyler
>
> On Thu, Nov 5, 2009 at 8:31 PM, Adam Barth <w3c@...> wrote:
>> You seem to be saying that your description of the protocol is not
>> complete and that you've left out several security-critical steps,
>> such as
>>
>> 1) The user interface for confirming transactions.
>> 2) The information the server uses to figure out which users it is talking to.
>>
>> Can you please provide a complete description of your protocol with
>> all the steps required?  I don't see how we can evaluate the security
>> of your protocol without such a description.
>>
>> Thanks,
>> Adam
>>
>>
>> On Thu, Nov 5, 2009 at 12:05 PM, Tyler Close <tyler.close@...> wrote:
>>> Hi Adam,
>>>
>>> Responses inline below...
>>>
>>> On Thu, Nov 5, 2009 at 8:56 AM, Adam Barth <w3c@...> wrote:
>>>> Hi Tyler,
>>>>
>>>> I've been trying to understand the GuestXHR protocol you propose for
>>>> replacing CORS:
>>>>
>>>> http://sites.google.com/site/guestxhr/maciej-challenge
>>>>
>>>> I don't understand the message in step 5.  It seems like it might have
>>>> a CSRF vulnerability.  More specifically, what does the server do when
>>>> it receives a GET request for https://B/got?A=secret123?
>>>
>>> Think of the resource at /got as like an Inbox for accepting an "add
>>> event" permission from anyone. The meta-variable "A" in the query
>>> string, along with the secret, is the URL to send events to. So a
>>> concrete request might look like:
>>>
>>> GET /got?site=https%3%2F%2Fcalendar.example.com&s=secret123
>>> Host: upcoming.example.net
>>>
>>> When upcoming.example.net receives this request, it might:
>>>
>>> 1) If no association for the site exists, add it
>>> 2) If an existing association for the site exists respond with a page
>>> notifying the user of the collision and asking if it should overwrite
>>> or ignore.
>>>
>>> Notice that step 6 is a response from Site B back to the user's browser.
>>>
>>> Alternatively, the response in step 6 could always be a confirmation
>>> page asking the user to confirm any state change that is about to be
>>> made. So, the page from the upcoming event site might say:
>>>
>>> "I just received a request to add a calendar to your profile. Did you
>>> initiate this request? <yes> <no>"
>>>
>>> Note that such a page would also be a good place to ask the user for a
>>> petname for the new capability, if you're into such things, but I
>>> digress...
>>>
>>>> The slides say "Associate user,A with secret123."  That sounds like
>>>> server B changes state to associate secret123 with the the pair (user,
>>>> A).  What stops an attacker from forging a cross-site request of the
>>>> form https://B/got?A=evil123?
>>>
>>> In the design as presented, nothing prevents this. I considered the
>>> mitigation presented above sufficient for Maciej's challenge. If
>>> desired, we could tighten things up, without resorting to an Origin
>>> header, but I'd have to add some more stuff to the explanation.
>>>
>>>>  Won't that overwrite the association?
>>>
>>> That seems like a bad idea.
>>>
>>>> There doesn't seem to be anything in the protocol that binds the "A"
>>>> in that message to server A.
>>>
>>> The "A" is just the URL for server A.
>>>
>>>> More generally, how does B know the message https://B/got?A=secret123
>>>> has anything to do with "user"?  There doesn't seem to be anything in
>>>> the message identifying the user.  (Of course, we could use cookies to
>>>> do that, but we're assuming the cookie header isn't present.)
>>>
>>> This request is just a normal page navigation, so cookies and such
>>> ride along with the request. In the diagrams, all requests are normal
>>> navigation requests unless prefixed with "GXHR:".
>>>
>>> We used these normal navigation requests in order to keep the user
>>> interface and network communication diagram as similar to Maciej's
>>> solution as possible. If I were approaching this problem without that
>>> constraint, I might do things differently, but that wasn't the goal of
>>> this exercise.
>>>
>>>> Can you help me understand how the protocol works?
>>>
>>> My pleasure. Please send along any follow up questions.
>>>
>>> (I would have chosen a different Subject field for these questions though)
>>>
>>>> P.S., It also seems that the protocol does not comply with the HTTP
>>>> specification because the server changes state in response to a GET
>>>> request.  Presumably, you mean to use a 307 redirect and a POST
>>>> request.  Unfortunately, that means the protocol will generate a
>>>> warning dialog in Firefox and will fail completely in Safari 4.
>>>
>>> I just said 303 because it was the most succinct way of expressing the
>>> relevant part of the communication. In deployment, a better solution
>>> would be to send back a normal 200 response with JavaScript code that
>>> does an automated form POST of the same data to Server B.
>>>
>>> --Tyler
>>>
>>> --
>>> "Waterken News: Capability security on the Web"
>>> http://waterken.sourceforge.net/recent.html
>>>
>>
>
>
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>

[Devdatta]

Hi Tyler,

Some parts of the protocol are not clear to me. Can you please clarify
the following :
1> In msg 1, what script context is the browser running in ? Site A or
Site B ? (in other words who initiates the whole protocol ?)

2> Msg 3 is a form POST or a XHR POST ? If the latter , 5 needs to be
marked as a GuestXHR

3> The 'secret123' token : Does it expire? If yes when/how ? Also, if
it expires, will the user have to again confirm the grant from A ?


Thanks
Devdatta



2009/11/10 Tyler Close <tyler.close@...>:

> I've elaborated on the example at:
>
> http://sites.google.com/site/guestxhr/maciej-challenge
>
> I've tried to include all the information from our email exchange.
> Please let me know what parts of the description remain ambiguous.
>
> Just so that we're on the same page, the prior description was only
> meant to give the reader enough information to see that the scenario
> is possible to implement under Maciej's stated constraints. I expected
> the reader to fill in their favored technique where that choice could
> be done safely in many ways. Many of the particulars of the design
> (cookies vs URL arguments, 303 vs automated form post, UI for noting
> conflicts) can be done in several different ways and the choice isn't
> very relevant to the current discussion. All that said, I'm happy to
> fill out the scenario with as much detail as you'd like, if that helps
> us reach an understanding.
>
> --Tyler
>
> On Thu, Nov 5, 2009 at 8:31 PM, Adam Barth <w3c@...> wrote:
>> You seem to be saying that your description of the protocol is not
>> complete and that you've left out several security-critical steps,
>> such as
>>
>> 1) The user interface for confirming transactions.
>> 2) The information the server uses to figure out which users it is talking to.
>>
>> Can you please provide a complete description of your protocol with
>> all the steps required?  I don't see how we can evaluate the security
>> of your protocol without such a description.
>>
>> Thanks,
>> Adam
>>
>>
>> On Thu, Nov 5, 2009 at 12:05 PM, Tyler Close <tyler.close@...> wrote:
>>> Hi Adam,
>>>
>>> Responses inline below...
>>>
>>> On Thu, Nov 5, 2009 at 8:56 AM, Adam Barth <w3c@...> wrote:
>>>> Hi Tyler,
>>>>
>>>> I've been trying to understand the GuestXHR protocol you propose for
>>>> replacing CORS:
>>>>
>>>> http://sites.google.com/site/guestxhr/maciej-challenge
>>>>
>>>> I don't understand the message in step 5.  It seems like it might have
>>>> a CSRF vulnerability.  More specifically, what does the server do when
>>>> it receives a GET request for https://B/got?A=secret123?
>>>
>>> Think of the resource at /got as like an Inbox for accepting an "add
>>> event" permission from anyone. The meta-variable "A" in the query
>>> string, along with the secret, is the URL to send events to. So a
>>> concrete request might look like:
>>>
>>> GET /got?site=https%3%2F%2Fcalendar.example.com&s=secret123
>>> Host: upcoming.example.net
>>>
>>> When upcoming.example.net receives this request, it might:
>>>
>>> 1) If no association for the site exists, add it
>>> 2) If an existing association for the site exists respond with a page
>>> notifying the user of the collision and asking if it should overwrite
>>> or ignore.
>>>
>>> Notice that step 6 is a response from Site B back to the user's browser.
>>>
>>> Alternatively, the response in step 6 could always be a confirmation
>>> page asking the user to confirm any state change that is about to be
>>> made. So, the page from the upcoming event site might say:
>>>
>>> "I just received a request to add a calendar to your profile. Did you
>>> initiate this request? <yes> <no>"
>>>
>>> Note that such a page would also be a good place to ask the user for a
>>> petname for the new capability, if you're into such things, but I
>>> digress...
>>>
>>>> The slides say "Associate user,A with secret123."  That sounds like
>>>> server B changes state to associate secret123 with the the pair (user,
>>>> A).  What stops an attacker from forging a cross-site request of the
>>>> form https://B/got?A=evil123?
>>>
>>> In the design as presented, nothing prevents this. I considered the
>>> mitigation presented above sufficient for Maciej's challenge. If
>>> desired, we could tighten things up, without resorting to an Origin
>>> header, but I'd have to add some more stuff to the explanation.
>>>
>>>>  Won't that overwrite the association?
>>>
>>> That seems like a bad idea.
>>>
>>>> There doesn't seem to be anything in the protocol that binds the "A"
>>>> in that message to server A.
>>>
>>> The "A" is just the URL for server A.
>>>
>>>> More generally, how does B know the message https://B/got?A=secret123
>>>> has anything to do with "user"?  There doesn't seem to be anything in
>>>> the message identifying the user.  (Of course, we could use cookies to
>>>> do that, but we're assuming the cookie header isn't present.)
>>>
>>> This request is just a normal page navigation, so cookies and such
>>> ride along with the request. In the diagrams, all requests are normal
>>> navigation requests unless prefixed with "GXHR:".
>>>
>>> We used these normal navigation requests in order to keep the user
>>> interface and network communication diagram as similar to Maciej's
>>> solution as possible. If I were approaching this problem without that
>>> constraint, I might do things differently, but that wasn't the goal of
>>> this exercise.
>>>
>>>> Can you help me understand how the protocol works?
>>>
>>> My pleasure. Please send along any follow up questions.
>>>
>>> (I would have chosen a different Subject field for these questions though)
>>>
>>>> P.S., It also seems that the protocol does not comply with the HTTP
>>>> specification because the server changes state in response to a GET
>>>> request.  Presumably, you mean to use a 307 redirect and a POST
>>>> request.  Unfortunately, that means the protocol will generate a
>>>> warning dialog in Firefox and will fail completely in Safari 4.
>>>
>>> I just said 303 because it was the most succinct way of expressing the
>>> relevant part of the communication. In deployment, a better solution
>>> would be to send back a normal 200 response with JavaScript code that
>>> does an automated form POST of the same data to Server B.
>>>
>>> --Tyler
>>>
>>> --
>>> "Waterken News: Capability security on the Web"
>>> http://waterken.sourceforge.net/recent.html
>>>
>>
>
>
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>
>

[Tyler Close]

Hi Devdatta,

On Thu, Nov 12, 2009 at 12:27 AM, Devdatta <dev.akhawe@...> wrote:
> Hi Tyler,
>
> Some parts of the protocol are not clear to me. Can you please clarify
> the following :
> 1> In msg 1, what script context is the browser running in ? Site A or
> Site B ? (in other words who initiates the whole protocol ?)

Server A, or a bookmark.

> 2> Msg 3 is a form POST or a XHR POST ? If the latter , 5 needs to be
> marked as a GuestXHR

Msg 3 is a form POST, so that the response can redirect the browser to Server B.

> 3> The 'secret123' token : Does it expire? If yes when/how ? Also, if
> it expires, will the user have to again confirm the grant from A ?

As presented, the token does not expire. If you want it to expire, the
simplest implementation would be to simply redo the introduction step.
Another alternative is to have Server B ask Server A for a fresh
secret by sending a request containing the previous secret. After the
initial introduction, Server B has Server A's URL and a shared secret
for authorization, so you can use that to bootstrap communication
between the two servers.

> Thanks
> Devdatta

My pleasure,
--Tyler

> 2009/11/10 Tyler Close <tyler.close@...>:
>> I've elaborated on the example at:
>>
>> http://sites.google.com/site/guestxhr/maciej-challenge
>>
>> I've tried to include all the information from our email exchange.
>> Please let me know what parts of the description remain ambiguous.
>>
>> Just so that we're on the same page, the prior description was only
>> meant to give the reader enough information to see that the scenario
>> is possible to implement under Maciej's stated constraints. I expected
>> the reader to fill in their favored technique where that choice could
>> be done safely in many ways. Many of the particulars of the design
>> (cookies vs URL arguments, 303 vs automated form post, UI for noting
>> conflicts) can be done in several different ways and the choice isn't
>> very relevant to the current discussion. All that said, I'm happy to
>> fill out the scenario with as much detail as you'd like, if that helps
>> us reach an understanding.
>>
>> --Tyler
>>
>> On Thu, Nov 5, 2009 at 8:31 PM, Adam Barth <w3c@...> wrote:
>>> You seem to be saying that your description of the protocol is not
>>> complete and that you've left out several security-critical steps,
>>> such as
>>>
>>> 1) The user interface for confirming transactions.
>>> 2) The information the server uses to figure out which users it is talking to.
>>>
>>> Can you please provide a complete description of your protocol with
>>> all the steps required?  I don't see how we can evaluate the security
>>> of your protocol without such a description.
>>>
>>> Thanks,
>>> Adam
>>>
>>>
>>> On Thu, Nov 5, 2009 at 12:05 PM, Tyler Close <tyler.close@...> wrote:
>>>> Hi Adam,
>>>>
>>>> Responses inline below...
>>>>
>>>> On Thu, Nov 5, 2009 at 8:56 AM, Adam Barth <w3c@...> wrote:
>>>>> Hi Tyler,
>>>>>
>>>>> I've been trying to understand the GuestXHR protocol you propose for
>>>>> replacing CORS:
>>>>>
>>>>> http://sites.google.com/site/guestxhr/maciej-challenge
>>>>>
>>>>> I don't understand the message in step 5.  It seems like it might have
>>>>> a CSRF vulnerability.  More specifically, what does the server do when
>>>>> it receives a GET request for https://B/got?A=secret123?
>>>>
>>>> Think of the resource at /got as like an Inbox for accepting an "add
>>>> event" permission from anyone. The meta-variable "A" in the query
>>>> string, along with the secret, is the URL to send events to. So a
>>>> concrete request might look like:
>>>>
>>>> GET /got?site=https%3%2F%2Fcalendar.example.com&s=secret123
>>>> Host: upcoming.example.net
>>>>
>>>> When upcoming.example.net receives this request, it might:
>>>>
>>>> 1) If no association for the site exists, add it
>>>> 2) If an existing association for the site exists respond with a page
>>>> notifying the user of the collision and asking if it should overwrite
>>>> or ignore.
>>>>
>>>> Notice that step 6 is a response from Site B back to the user's browser.
>>>>
>>>> Alternatively, the response in step 6 could always be a confirmation
>>>> page asking the user to confirm any state change that is about to be
>>>> made. So, the page from the upcoming event site might say:
>>>>
>>>> "I just received a request to add a calendar to your profile. Did you
>>>> initiate this request? <yes> <no>"
>>>>
>>>> Note that such a page would also be a good place to ask the user for a
>>>> petname for the new capability, if you're into such things, but I
>>>> digress...
>>>>
>>>>> The slides say "Associate user,A with secret123."  That sounds like
>>>>> server B changes state to associate secret123 with the the pair (user,
>>>>> A).  What stops an attacker from forging a cross-site request of the
>>>>> form https://B/got?A=evil123?
>>>>
>>>> In the design as presented, nothing prevents this. I considered the
>>>> mitigation presented above sufficient for Maciej's challenge. If
>>>> desired, we could tighten things up, without resorting to an Origin
>>>> header, but I'd have to add some more stuff to the explanation.
>>>>
>>>>>  Won't that overwrite the association?
>>>>
>>>> That seems like a bad idea.
>>>>
>>>>> There doesn't seem to be anything in the protocol that binds the "A"
>>>>> in that message to server A.
>>>>
>>>> The "A" is just the URL for server A.
>>>>
>>>>> More generally, how does B know the message https://B/got?A=secret123
>>>>> has anything to do with "user"?  There doesn't seem to be anything in
>>>>> the message identifying the user.  (Of course, we could use cookies to
>>>>> do that, but we're assuming the cookie header isn't present.)
>>>>
>>>> This request is just a normal page navigation, so cookies and such
>>>> ride along with the request. In the diagrams, all requests are normal
>>>> navigation requests unless prefixed with "GXHR:".
>>>>
>>>> We used these normal navigation requests in order to keep the user
>>>> interface and network communication diagram as similar to Maciej's
>>>> solution as possible. If I were approaching this problem without that
>>>> constraint, I might do things differently, but that wasn't the goal of
>>>> this exercise.
>>>>
>>>>> Can you help me understand how the protocol works?
>>>>
>>>> My pleasure. Please send along any follow up questions.
>>>>
>>>> (I would have chosen a different Subject field for these questions though)
>>>>
>>>>> P.S., It also seems that the protocol does not comply with the HTTP
>>>>> specification because the server changes state in response to a GET
>>>>> request.  Presumably, you mean to use a 307 redirect and a POST
>>>>> request.  Unfortunately, that means the protocol will generate a
>>>>> warning dialog in Firefox and will fail completely in Safari 4.
>>>>
>>>> I just said 303 because it was the most succinct way of expressing the
>>>> relevant part of the communication. In deployment, a better solution
>>>> would be to send back a normal 200 response with JavaScript code that
>>>> does an automated form POST of the same data to Server B.
>>>>
>>>> --Tyler
>>>>
>>>> --
>>>> "Waterken News: Capability security on the Web"
>>>> http://waterken.sourceforge.net/recent.html
>>>>
>>>
>>
>>
>>
>> --
>> "Waterken News: Capability security on the Web"
>> http://waterken.sourceforge.net/recent.html
>>
>>
>

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

[Devdatta]

>>
>> Some parts of the protocol are not clear to me. Can you please clarify
>> the following :
>> 1> In msg 1, what script context is the browser running in ? Site A or
>> Site B ? (in other words who initiates the whole protocol ?)
>
> Server A, or a bookmark.

Wasn't Maciej's original scenario that of a user going to Site B (an
event's site) and adding stuff to his calendar at A ? In such a
scenario, the complete protocol should ideally start with B.

Thanks
devdatta

[Tyler Close]

On Fri, Nov 13, 2009 at 6:45 PM, Devdatta <dev.akhawe@...> wrote:

>>>
>>> Some parts of the protocol are not clear to me. Can you please clarify
>>> the following :
>>> 1> In msg 1, what script context is the browser running in ? Site A or
>>> Site B ? (in other words who initiates the whole protocol ?)
>>
>> Server A, or a bookmark.
>
> Wasn't Maciej's original scenario that of a user going to Site B (an
> event's site) and adding stuff to his calendar at A ? In such a
> scenario, the complete protocol should ideally start with B.

There are two parts to Maciej's scenario: the access grant (get
permission to use the calendar) and the use of access (add an event to
the calendar). Maciej starts the first at Server A (the calendar site)
and the second at Server B (the upcoming events site). Our proposed
solution does the same as Maciej's proposal.

See:

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

If you want to try working on a different scenario that starts both
steps at Server B, that's fine. With the same techniques applied in
Maciej's scenario, you should be able to construct a solution to the
new scenario.

--Tyler

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