Re: CORS Background slides

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@apple.com> 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

Received on Tuesday, 10 November 2009 19:41:45 UTC