Re: CSRF vulnerability in Tyler's GuestXHR protocol?

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@gmail.com>:
> 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@adambarth.com> 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@gmail.com> wrote:
>>> Hi Adam,
>>>
>>> Responses inline below...
>>>
>>> On Thu, Nov 5, 2009 at 8:56 AM, Adam Barth <w3c@adambarth.com> 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
>
>

Received on Thursday, 12 November 2009 08:28:13 UTC