Re: [UMP] Feedback on UMP from a quick read

On Sat, Jan 9, 2010 at 10:20 AM, Adam Barth <w3c@adambarth.com> wrote:
> On Sat, Jan 9, 2010 at 7:23 AM, Tyler Close <tyler.close@gmail.com> wrote:
>> Since in general this design cannot be made safe,
>> I think it's better to not support it at all in the security model, by
>> allowing a uniform request to follow a non-uniform redirect. A
>> security model that works for some media-types but not others is just
>> too bizarre to explain to developers.
>
> That's the security model we have.  For example, it's safe to return
> untrusted HTML tags with certain media types but not with others.

Just because the Same Origin Policy is full of bizarre gotchas doesn't
mean the UMP must also be. Using the UMP with permission tokens
eliminates several of the gotchas. I'm taking every opportunity I can
to provide developers with a more reasonable security model. Surely a
security expert must applaud this effort.

>> This choice doesn't endanger
>> existing resources, since CORS also allows a cross-origin request to
>> follow a redirect that has not opted out of the Same Origin Policy.
>
> I'm glad you consider CORS to be the epitome of a secure design.  :)

Does the smiley imply that you don't consider CORS to be a good
example of secure design?

For myself, I was merely citing CORS as the original definition for
the semantics of the "Access-Control-Allow-Origin: *" header.

> (As Maciej says, CORS doesn't appear to have this hole.)

Indeed, I misread the section on simple requests:

http://www.w3.org/TR/access-control/#simple-cross-origin-request0

I didn't realize the algorithm was checking the response headers in
several different places. I guess that's one of the dangers of an
algorithmic specification: you must have the whole thing in mind
before you can make any statements about what it does or does not do.

Given this correction, I'm reconsidering following of non-uniform
redirects. I still don't like that it makes it look like your example
design is safe, when in fact there are several non-confidentiality
problems with it, and using JSON for the final response also breaks
confidentiality.

> As Maciej says, just because the server can screw up it's
> confidentiality doesn't means we should prevent servers from doing the
> secure thing.  By this argument, we should remove the same-origin
> policy entirely because some sites might have XSS vulnerabilities.

Deciding to use a popular and standard media-type in its intended
setting is not at all comparable to filling your site with XSS
vulnerabilities. I did not read Maciej's email as suggesting
otherwise.

--Tyler

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

Received on Saturday, 9 January 2010 21:58:25 UTC