Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Mon, Dec 14, 2009 at 11:35 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Dec 14, 2009, at 10:44 AM, Tyler Close wrote:
>
>> On Mon, Dec 14, 2009 at 10:16 AM, Adam Barth <w3c@adambarth.com> wrote:
>>>
>>> On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees <jar@creativecommons.org>
>>> wrote:
>>>>
>>>> The only complaint I know of regarding UM is that it is so complicated
>>>> to use in practice that it will not be as enabling as CORS
>>>
>>> Actually, Tyler's UM protocol requires the user to confirm message 5
>>> to prevent a CSRF attack.  Maciej's CORS version of the protocol
>>> requires no such user confirmation.  I think it's safe to say that
>>> asking the user to confirm security-critical operations is not a good
>>> approach.
>>
>> For Ian Hickson's challenge problem, I came up with a design that does
>> not require any confirmation, or any other user interaction. See:
>>
>> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/1232.html
>>
>> That same design can be used to solve Maciej's challenge problem.
>
> I see three ways it wouldn't satisfy the requirements given for my CORS
> example:
>
> 1) Fails "AJAX UI" requirement in the grant phase, since a form post is
> required.

I thought "AJAX UI" just meant no full page reload. The grant phase
could be done in an <iframe>.

> 2) The permission grant is intiated and entirely drive by Site B (the
> service consumer). Thus Site A (the service provider in this case) has no
> way to know that the request to grant access is a genuine grant from the
> user.
>
> 3) When Site A receives the request from Site B, there is no indication of
> what site initiated the communication (unless the request from B is expected
> to come with an Origin header). How does it even know it's supposed to
> redirect to B? Is site A expecting that it's only going to get service
> requests from B? That would amount to a prior bilateral arrangement.

Ian's challenge scenario did involve a prior bilateral arrangement. I
forgot that yours instead asked for the user's permission and so is a
semantically different challenge problem.

We could adapt the solution to Ian's problem to fit yours. We precede
the solution to Ian's challenge with a step almost exactly like the
first step of your own solution to your challenge problem. In
particular,

User Consent Phase:
1) On a page served by Server A, user picks Site B as having
permission to add calendar events.
2) Server A records this grant in the user's account. In particular,
the user account could store the relation (<https://B>,
<https://A/user123?s=secretkey>).

Now, when Site B sends its request for the user's unguessable feed
URL, Site A can check the user account to see if the user consents. In
particular:

Grant Phase:
1. User logs into Site B.

2. Site B generates an unguessable token (to be used for CSRF
protection on a subsequent request) and associates it with the user
account.

3. A page from Site B sends a request with the token to Site A, using
a URL like <https://A/getfeed?for=B&csrf=asdf>. The "csrf" query
string parameter holds the unguessable token generated in step 2. The
"for" query string holds the URL <https://B>.

4. Site A receives a request containing the user's login cookies, and
the query string parameters. Using the "for" argument, Site A looks up
the unguessable URL for the user's feed, generated in step 2 of the
User Consent Phase. If there is none, a 404 is returned. If a match is
found, Site A responds with a 303 back to Site B that contains the
feed URL and the csrf token, such as
<https://B/gotfeed?csrf=asdf&feed=xxx>. The "feed" query string
parameter holds the unguessable URL for the user's feed.

5. Site B receives a request containing the user's login cookies,
the csrf token and the feed URL. Site B does a lookup for the expected
csrf token in the user's account. If the csrf token is not the
expected one, Site B stops processing the request. Site B discards the
csrf token. Site B stores the feed URL in the user's account. Site B
responds with the normal, post-login user home page.

Exercise Phase:
1. A page from Site B gets the user feed URL from the user's account
and uses a UniformRequest (XHR-like protocol for uniform requests) to
do a GET request.

2. Site A receives a GET request on a feed URL, looks up the
corresponding feed data and returns it, along with the same-origin
opt-out header.

> I also note that the protocol you describe there uses cookies (and possibly
> origins, if point 3 is addressed) to bootstrap a shared-secret based scheme.

Were I allowed some freedom in the user interface, I could solve all
these challenge problems without resort to cookies. For example, the
User Consent Phase and Grant Phase above could be replaced by a single
copy-paste operation by the user. But in these challenges, I've been
prohibited from using copy-paste. (As a side node, with some changes
to the browser implementation, I could also solve these challenges
using a single-click user gesture, instead of copy-paste.)

> As I've mentioned before, CORS would be a useful tool for that type of
> technique. It can allow such bootstrapping without having to jump through
> hoops with form posts, without disrupting the user's interaction with a full
> page load, and without necessarily having to put secrets in the URL (since
> the URL part of the request is by far the most likely to leak to the outside
> world inadvertantly.

With no secrets in the URL, the solution would also be vulnerable to
CSRF-like attacks. Keep in mind that the solutions I have been
proposing provide greater security under an identical user interface.
That costs me some implementation complexity (the hoops you refer to).
Again, that complexity goes away if I can have some user interface
flexibility.

--Tyler

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

Received on Monday, 14 December 2009 22:14:10 UTC