W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: CSRF vulnerability in Tyler's GuestXHR protocol?

From: Tyler Close <tyler.close@gmail.com>
Date: Fri, 13 Nov 2009 14:45:42 -0800
Message-ID: <5691356f0911131445s5b83fecai144fc5e95f4675a2@mail.gmail.com>
To: Devdatta <dev.akhawe@gmail.com>
Cc: public-webapps <public-webapps@w3.org>
Hi Devdatta,

On Thu, Nov 12, 2009 at 12:27 AM, Devdatta <dev.akhawe@gmail.com> 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@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
>>
>>
>



-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Friday, 13 November 2009 22:46:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT