Re: ACTION-340: CORS, UMP and XHR2

On Thu, May 20, 2010 at 9:10 AM, John Kemp <john@jkemp.net> wrote:

> Hi Mark,
>
> On May 20, 2010, at 12:00 PM, Mark S. Miller wrote:
>
> > On Thu, May 20, 2010 at 7:57 AM, John Kemp <john@jkemp.net> wrote:
> >
> >
> > It should be noted that because UMP suggests a new model, it does not
> > yet support the same set of use-cases supported by CORS.
> >
> >
> > UMP does support the use cases listed in the CORS doc, and virtually all
> use cases anyone has thrown at us. Also, CORS does not support many of the
> use cases supported by UMP. This pair of facts seem worth mentioning.
>
> My statement comes from reading the requirements section of the UMP
> specification: http://www.w3.org/TR/UMP/#requirements where it says:
>
> "Note: These requirements are taken from the CORS specification. A note
> indicates those requirements that could not be fully satisfied."
>
> and, for requirement 10 in that list:
>
> "Note: To retain compatibility with deployed implementations, support for
> POSTs of arbitrary media types is deferred to a future Uniform Messaging
> Policy, Level Two specification."
>
> Requirements 12, 16 and 17 have similar notes.
>

Hi John, thanks, that helps clarify.

For #10, #12, and #16, we refer here to "a future [UMP] Level Two" as you
note. The level one vs level two issues are mostly orthogonal to the UMP vs
CORS controversy. Level one is corresponds to the subset of either that
needs no preflight. Level two corresponds to the remainder of either that
does require preflight. The CORS document includes both levels in one
document. In writing UMP, we felt it more tasteful to place these in
separate documents, especially as the already-widely-deployed XDR has no
preflight.

If you see the lack of level two (preflight) as the gating issue impeding
the progress of UMP, we will happily write it up. Please let us know. If so,
we would still like to keep level two in a distinct document.

The conflict in our Note on the remaining issue #17 applies to CORS as well.
The difference is that UMP resolves the conflict in favor of #18 while CORS
sacrifices #18 in favor of #17. (Without acknowledging this in the current
CORS text.)


> I believe that UMP also supports use-cases, and meets requirements _not_
> listed in the CORS spec.
>
> >
> >
> > In summary, both CORS and UMP support cross-domain requests. CORS
> > utilizes existing origin- and cookie-based approaches for access
> > control, but doesn't completely prevent XSRF/Clickjacking. UMP allows
> > the complete prevention of such attacks, but relies upon
> > relatively non-standard mechanisms for authenticating cross-site requests
> in
> > order to do so.
> >
> > As we explain in the "Security Considerations" of UMP, websites must
> already use some kind of unguessable token (i.e., the CSRF token) to protect
> themselves from CSRF anyway. So UMP does not rely on "relatively
> non-standard mechanisms". Am I missing something?
>
> Are any of the "unguessable token" mechanisms you mention widely supported
> by websites? If so, which one(s), and by whom are they supported?
>

Adam Barth et al's "Robust Defenses.." paper at <
http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf>, often
cited in support of CORS, says:

"The most popular CSRF defense is to include a secret
token with each request and to validate that the re-
ceived token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token."


That is our impression as well. <
http://www.google.com/search?q=%22csrf+token%22> gives 93K results. Note
that most prominent pages about CSRF tokens, as with most security
mechanisms, are about cases where buggy implementations failed to protect,
rather than the less newsworthy successful cases.

Section 4.1 of "Robust Defenses.." discusses some systems that used csrf
tokens incorrectly, including Ruby on Rails. <
http://news.softpedia.com/news/Facebook-Bug-Exposes-Users-to-Dangerous-CSRF-Attacks-142488.shtml>
discusses a flaw in Facebook's CSRF token defense:

"In order to protect users against such authorization abuse, which can have
serious consequences, websites commonly implement solutions that require
unique tokens to accompany requests for source verification. The Facebook
bug discovered by Mr. Keith is embarrassingly a failure to check if
Facebook's requests contain the anti-CSRF token."


Please let us know if you'd like us to enumerate other examples. There are
plenty.


> >
> > UMP and CORS differ in the use-cases they support.
> >
> > The only differences I know of, and that has withstood any scrutiny, are
> that UMP supports some use cases that CORS does not.
>
> I agree that this is the case, but I also believe that CORS supports some
> mechanisms that UMP does not, as described above, related to the CORS
> requirements which are reproduced in the UMP requirements. Please let me
> know if I have misrepresented the statements in the specification.
>

As explained above, #10, #12, and #16 are level one (no preflight) vs level
two (preflight) issues, and so orthogonal to UMP vs CORS. #17 vs #18 is an
inescapable conflict, which CORS resolves in favor of #17 (without
acknowledging the sacrifice of #18) and UMP resolves in favor of #18 (and
acknowledges the sacrifice of #17).



>
> Regards,
>
> - johnk
>
> >
> >
> >
> > Regards,
> >
> > - johnk
> >
> > [CORS] http://www.w3.org/TR/access-control/
> > [UMP] http://www.w3.org/TR/UMP/
> > [XHR2] http://www.w3.org/TR/XMLHttpRequest2/
> > [SOP] http://en.wikipedia.org/wiki/Same_origin_policy
> > [AmbientAuthority] http://en.wikipedia.org/wiki/Ambient_authority
> > [CORSChallenge]
> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0479.html
> > [CORS/UMP] Begins with:
> http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP
> > [UMP/CORS:Implementor Interest] Begins with:
> http://www.mail-archive.com/public-webapps@w3.org/msg08280.html
> > [[UMP] Request for Last Call]
> http://www.mail-archive.com/public-webapps@w3.org/msg08135.html
> > [CrockScript] http://javascript.crockford.com/script.html
> >
> >
> >
> >
> >
> > --
> >     Cheers,
> >     --MarkM
>
>


-- 
    Cheers,
    --MarkM