[cors] TAG request concerning CORS & Next Step(s)

[Arthur Barstow]

Members of the Web Apps WG,

Below is an email from Henry Thompson (forwarded with his  
permission), on behalf of the TAG [1], re the CORS spec [2].

Two things:

1. Please respond to at least this part of Henry's mail:

[[
It appeared to us that a number of significant criticisms of the
appropriateness of CORS have been submitted to the Working Group, from
respected members of the Web Security community among others. These
convinced us that there is a real possibility either that server-side
deployment won't happen, or that even if it did the new functionality
provided would, on the one hand, be insufficiently secure while, on the
other, discouraging the provision of something more satisfactory.
]]

2. For those that have been active in defining the CORS model and/or  
CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE  
guys (whomever replaced Sunava) - please indicate:

a) their level of interest in continuing to push the current CORS model;

b) their implementation plans for CORS.

Henry - regarding how the WG will address comments re CORS, I expect  
us to continue to use public-webapps for related discussions and to  
track issues using Tracker (see [3] for a list of open Issues related  
to CORS).

-Regards, Art Barstow

[1] http://www.w3.org/2001/tag/
[2] http://dev.w3.org/2006/waf/access-control/
[3] http://www.w3.org/2008/webapps/track/products/7


Begin forwarded message:

> From: "ext Henry S. Thompson" <ht@...>
> Date: June 23, 2009 5:18:51 PM EDT
> To: "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@...>,  
> Charles McCathieNevile <chaals@...>
> Subject: TAG request concerning CORS
>
> In the course of exploring a range of issues around the general
> question of JavaScript security [1] at our face-to-face meeting, the
> TAG reviewed the same-origin restriction policy in user agents,
> and the Cross-Origin Resource Sharing (CORS) WD [2] under development
> in the WebApps WG.
>
> It appeared to us that a number of significant criticisms of the
> appropriateness of CORS have been submitted to the Working Group, from
> respected members of the Web Security community among others. These
> convinced us that there is a real possibility either that server-side
> deployment won't happen, or that even if it did the new functionality
> provided would, on the one hand, be insufficiently secure while, on  
> the
> other, discouraging the provision of something more satisfactory.
>
> Please get back to us with some details of how those criticisms will
> be addressed, so that widespread server-side deployment will not only
> occur but also be beneficial.
>
> Henry S. Thompson, on behalf of the TAG
>
> [1] http://www.w3.org/2001/tag/2009/06/23-agenda#security
> [2] http://www.w3.org/TR/access-control/
> - --
>        Henry S. Thompson, School of Informatics, University of  
> Edinburgh

[Anne van Kesteren-2]

On Wed, 24 Jun 2009 13:29:38 +0200, Arthur Barstow <Art.Barstow@...>  
wrote:

> 1. Please respond to at least this part of Henry's mail:
>
> [[
> It appeared to us that a number of significant criticisms of the
> appropriateness of CORS have been submitted to the Working Group, from
> respected members of the Web Security community among others. These
> convinced us that there is a real possibility either that server-side
> deployment won't happen, or that even if it did the new functionality
> provided would, on the one hand, be insufficiently secure while, on the
> other, discouraging the provision of something more satisfactory.
> ]]

I think the potential for security issues has been pointed out in the  
alternate proposals, not CORS itself. CORS has certainly not been found to  
be ideal, but something more satisfactory to all parties involved has not  
been proposed either. I would also classify the outstanding issues against  
CORS as minor.

Having said that, if there is something in particular you are thinking of  
it would be nice to explicitly point that out (and in case that email  
received a reply it would be good to point out why that reply did not  
address the point in question).


> 2. For those that have been active in defining the CORS model and/or  
> CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE  
> guys (whomever replaced Sunava) - please indicate:
>
> a) their level of interest in continuing to push the current CORS model;

I'm happy to continue as editor.


> b) their implementation plans for CORS.

I cannot comment on behalf of Opera on this. I can point out that Safari 4  
and Chrome 2 ship with it and that Firefox 3.5 will too. (No  
implementation will support redirects yet though, as I understand things.)  
Internet Explorer 8 supports a subset of the protocol.


--
Anne van Kesteren
http://annevankesteren.nl/

[Jonas Sicking-2]

First of all, I know of only one outstanding security issue, which is
around redirects. If there are others, it would be great to get
detailed feedback, we're not hard to reach :)

> 2. For those that have been active in defining the CORS model and/or CORS
> implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE guys
> (whomever replaced Sunava) - please indicate:
>
> a) their level of interest in continuing to push the current CORS model;

I am very interested. And I know others are mozilla are too.

> b) their implementation plans for CORS.

Firefox 3.5 will be out in a matter of days (RC available already) and
it supports the majority of CORS (everything but redirects of
preflighted requests).

Firefox 3.5 also uses CORS as security model for @font-face in order
to support cross-site loading of fonts.

As Anne pointed out, others have also deployed partial support. In
fact, relatively speaking, CORS has seen an extraordinary amount of
browser deployment already.

/ Jonas

[Henry S. Thompson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonas Sicking writes:

> As Anne pointed out, others have also deployed partial support. In
> fact, relatively speaking, CORS has seen an extraordinary amount of
> browser deployment already.

One point of clarification: my (admittedly imperfect) understanding
was that the most important parts of CORS have to be implemented
_server_-side for the proposal to achieve its goals.  If that's true,
browser deployment alone is insufficient.  Is that a misunderstanding
on my part?

ht
- --
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: [phone], e-mail: ht@...
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFKQmDbkjnJixAXWBoRAswcAJwMj30AeprY747BbWJk51fwCaK+LQCePhom
VC9i2zuQFC8Fu9PuSN8nEZc=
=QIzs
-----END PGP SIGNATURE-----

[Michael(tm) Smith-4]

"Henry S. Thompson" <ht@...>, 2009-06-24 18:22 +0100:

> Jonas Sicking writes:
>
> > As Anne pointed out, others have also deployed partial support. In
> > fact, relatively speaking, CORS has seen an extraordinary amount of
> > browser deployment already.
>
> One point of clarification: my (admittedly imperfect) understanding
> was that the most important parts of CORS have to be implemented
> _server_-side for the proposal to achieve its goals.  If that's true,
> browser deployment alone is insufficient.  Is that a misunderstanding
> on my part?

It's not true.

The spec was explicitly designed with a goal of minimizing any
server-side changes that would need to be made to enable it.

Some of the relevant requirements:

  - Must be deployable to IIS and Apache without requiring actions
    by the server administrator in a configuration where the user
    can upload static files, run serverside scripts (such as PHP,
    ASP, and CGI), control headers, and control authorization, but
    only do this for URLs under a given set of subdirectories on
    the server.

  - Must be able to deploy support for cross-origin GET requests
    without having to use server-side scripting (such as PHP, ASP,
    or CGI) on IIS and Apache.

  - Must not require that the server filters the entity body of
    the resource in order to deny cross-origin access to all
    resources on the server.

--
Michael(tm) Smith
http://people.w3.org/mike/

[Tyler Close]

On Wed, Jun 24, 2009 at 10:16 AM, Jonas Sicking<jonas@...> wrote:
> Firefox 3.5 will be out in a matter of days (RC available already) and
> it supports the majority of CORS (everything but redirects of
> preflighted requests).

What is the behavior of the Origin header on other kinds of redirects?
For example:

1. page from Site A does: POST text/plain to a URL at Site B

2. Site B responds with a redirect to a URL at Site A

3. User clicks through any presented redirect confirmation dialog

4. Browser sends the POST from step 1 to the specified URL at Site A.

What is the value of the Origin header in step 4?

--Tyler

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

[Arun Ranganathan-4]

Arthur Barstow wrote:

> Members of the Web Apps WG,
>
> Below is an email from Henry Thompson (forwarded with his permission),
> on behalf of the TAG [1], re the CORS spec [2].
>
> Two things:
>
> 1. Please respond to at least this part of Henry's mail:
>
> [[
> It appeared to us that a number of significant criticisms of the
> appropriateness of CORS have been submitted to the Working Group, from
> respected members of the Web Security community among others. These
> convinced us that there is a real possibility either that server-side
> deployment won't happen, or that even if it did the new functionality
> provided would, on the one hand, be insufficiently secure while, on the
> other, discouraging the provision of something more satisfactory.
> ]]
>
> 2. For those that have been active in defining the CORS model and/or
> CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE
> guys (whomever replaced Sunava) - please indicate:
>
> a) their level of interest in continuing to push the current CORS model;

I've documented what Firefox 3.5 will do here:

https://developer.mozilla.org/En/HTTP_access_control

Also see:

https://developer.mozilla.org/En/Server-Side_Access_Control

Now, note that this documentation is dated (it still uses the term
"Access Control" which should change).  But it is a reflection of what
will go live in Fx3.5 (Jonas has already commented on redirects on
preflighted requests, which won't be supported).

A simple test of Fx 3.5 functionality might be:

http://arunranga.com/examples/access-control/

We continue to have discussion about the "number of significant
criticisms."  I'm keen to see this result in tangible proposals.
>
> b) their implementation plans for CORS.
See above (and see email from Jonas Sicking).

-- A*

[Jonas Sicking-2]

On Wed, Jun 24, 2009 at 10:22 AM, Henry S. Thompson<ht@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jonas Sicking writes:
>
>> As Anne pointed out, others have also deployed partial support. In
>> fact, relatively speaking, CORS has seen an extraordinary amount of
>> browser deployment already.
>
> One point of clarification: my (admittedly imperfect) understanding
> was that the most important parts of CORS have to be implemented
> _server_-side for the proposal to achieve its goals.  If that's true,
> browser deployment alone is insufficient.  Is that a misunderstanding
> on my part?

I'm not sure how to measure what parts are more important than others?

But both server support and browser support is needed yes. In order to
support the most simple use cases (and what we at mozilla have
perceived to be the most requested use cases) the server needs to add
one header:

Access-Control-Allow-Origin: *

to their responses. In the technologies I have looked at or used this
has always been quite simple. It is also safe to do for any server
connected to the public internet as it won't expose any more data than
can be retrived using a simple request from any HTTP client.

Generally with web technologies server support tends to lag since many
developers aren't interested in writing code that only works for part
of their user base. So basically the first step to get cross browser
support in new releases, second is to wait for old releases to loose
market share, third is when you'll start seeing wide website usage.

That said, we should of course ensure that the current spec is
something that servers are interested in deploying, once the
marketshare is there. If there are security issues they of course
won't be. So if you know of security problems (other than the one we
already know about), or have other reasons to believe that servers
aren't interested in deploying, definitely speak up as soon as
possible.

/ Jonas

[Jonas Sicking-2]

On Wed, Jun 24, 2009 at 11:45 AM, Tyler Close<tyler.close@...> wrote:

> On Wed, Jun 24, 2009 at 10:16 AM, Jonas Sicking<jonas@...> wrote:
>> Firefox 3.5 will be out in a matter of days (RC available already) and
>> it supports the majority of CORS (everything but redirects of
>> preflighted requests).
>
> What is the behavior of the Origin header on other kinds of redirects?
> For example:
>
> 1. page from Site A does: POST text/plain to a URL at Site B
>
> 2. Site B responds with a redirect to a URL at Site A
>
> 3. User clicks through any presented redirect confirmation dialog
>
> 4. Browser sends the POST from step 1 to the specified URL at Site A.
>
> What is the value of the Origin header in step 4?

Which "Origin" are you referring to here?

The "Origin" header defined by the CORS spec is known to be bad and is
being worked on.  So I'm not sure it's interesting to discuss what the
CORS spec says here. (At least that was the status last I looked, I'm
a bit behind on the last few rounds of emails though).

As for the "Origin" spec that Adam Barth is working on, I'm not sure
that the last draft is published yet, but I believe that the idea is
to append the full redirect chain in the Origin header. (hence
possibly making it incompatible with the CORS "Origin" meaning that
we'll have to use another name).

So again, we do know there is a problem with the Origin header in the
CORS spec when it comes to redirects. It's a known outstanding issue
that we believe is fixable and not a reason to abandon the whole spec.

/ Jonas

[Tyler Close]

Hi Jonas,

I'm just asking what Origin header behavior will be shipped in Firefox
3.5. You've said redirects of preflighted requests aren't supported,
so I'm wondering about the non-preflighted requests.

Another question, since Firefox doesn't support redirects of
preflighted requests, what does it do when it encounters a redirect?

--Tyler

On Wed, Jun 24, 2009 at 12:43 PM, Jonas Sicking<jonas@...> wrote:

> On Wed, Jun 24, 2009 at 11:45 AM, Tyler Close<tyler.close@...> wrote:
>> On Wed, Jun 24, 2009 at 10:16 AM, Jonas Sicking<jonas@...> wrote:
>>> Firefox 3.5 will be out in a matter of days (RC available already) and
>>> it supports the majority of CORS (everything but redirects of
>>> preflighted requests).
>>
>> What is the behavior of the Origin header on other kinds of redirects?
>> For example:
>>
>> 1. page from Site A does: POST text/plain to a URL at Site B
>>
>> 2. Site B responds with a redirect to a URL at Site A
>>
>> 3. User clicks through any presented redirect confirmation dialog
>>
>> 4. Browser sends the POST from step 1 to the specified URL at Site A.
>>
>> What is the value of the Origin header in step 4?
>
> Which "Origin" are you referring to here?
>
> The "Origin" header defined by the CORS spec is known to be bad and is
> being worked on.  So I'm not sure it's interesting to discuss what the
> CORS spec says here. (At least that was the status last I looked, I'm
> a bit behind on the last few rounds of emails though).
>
> As for the "Origin" spec that Adam Barth is working on, I'm not sure
> that the last draft is published yet, but I believe that the idea is
> to append the full redirect chain in the Origin header. (hence
> possibly making it incompatible with the CORS "Origin" meaning that
> we'll have to use another name).
>
> So again, we do know there is a problem with the Origin header in the
> CORS spec when it comes to redirects. It's a known outstanding issue
> that we believe is fixable and not a reason to abandon the whole spec.
>
> / Jonas
>

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

[Jonas Sicking-2]

On Wed, Jun 24, 2009 at 12:52 PM, Tyler Close<tyler.close@...> wrote:
> Hi Jonas,
>
> I'm just asking what Origin header behavior will be shipped in Firefox
> 3.5. You've said redirects of preflighted requests aren't supported,
> so I'm wondering about the non-preflighted requests.

It will have the Origin header of the original request. We're
considering blocking the request entirely for now though.

> Another question, since Firefox doesn't support redirects of
> preflighted requests, what does it do when it encounters a redirect?

It aborts and denies the original request. For XHR that means raising
an error event.

/ Jonas

[Adrian Bateman]

On Wednesday, June 24, 2009 8:14 AM, Anne van Kesteren wrote:
> To: Arthur Barstow; public-webapps; Henry Thompson
> Subject: Re: [cors] TAG request concerning CORS & Next Step(s)
>
> On Wed, 24 Jun 2009 13:29:38 +0200, Arthur Barstow
> <Art.Barstow@...> wrote:
> > 2. For those that have been active in defining the CORS model and/or
> > CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE
> > guys (whomever replaced Sunava) - please indicate:

> > b) their implementation plans for CORS.
>
> I cannot comment on behalf of Opera on this. I can point out that
> Safari 4
> and Chrome 2 ship with it and that Firefox 3.5 will too. (No
> implementation will support redirects yet though, as I understand
> things.)
> Internet Explorer 8 supports a subset of the protocol.

As Anne says, IE8 ships with a profile of CORS that deals with public (non-authenticated) requests. For this subset, we are interoperable with Firefox 3.5 and presumably Safari 4 and Chrome 2. In addition to the versions for XP, Vista, and Windows Server, IE8 will ship as a component of Windows 7 later in the year tied to Microsoft's standard support policy, which currently provides for 10 years of support.

Clearly, adoption requires browsers and web applications to implement and utilize the feature and there is coverage in many desktop browsers and likely some mobile devices to address part of the story. We haven't made any decisions yet about whether we will implement more of the CORS spec in a future release.

Cheers,

Adrian.

[Tyler Close]

On Wed, Jun 24, 2009 at 1:37 PM, Jonas Sicking<jonas@...> wrote:
> On Wed, Jun 24, 2009 at 12:52 PM, Tyler Close<tyler.close@...> wrote:
>> Hi Jonas,
>>
>> I'm just asking what Origin header behavior will be shipped in Firefox
>> 3.5. You've said redirects of preflighted requests aren't supported,
>> so I'm wondering about the non-preflighted requests.
>
> It will have the Origin header of the original request. We're
> considering blocking the request entirely for now though.

Meaning the POST request is delivered to Site A, with an Origin header
also identifying Site A, but with a Request-URI chosen by Site B. So
Site B can cause the POST request to be sent to any resource on Site A
and be processed under Site A's authority. I recommend against
shipping that algorithm.

Note that this scenario is just a special case of a more general
problem with the Origin proposal. Whenever a page issues a request
that includes data provided by a third site, that page is applying its
own authority to identifiers provided by the third site. This is the
essence of a CSRF attack (Confused Deputy). For example, if a page
from Site A does a GET to Site B and then includes a received
identifier in a subsequent POST to a site other than Site B, Site A is
vulnerable to a Confused Deputy attack by Site B. Since the whole
point of cross-origin requests is to enable this kind of passing of
information between sites, the Origin proposal is poorly suited for
access-control in these scenarios.

Again, see my paper "ACLs don't" <http://waterken.sf.net/aclsdont/>
for an in-depth explanation of why ACL model solutions, such as
Origin, can't solve this problem. The section on stack introspection
is especially relevant, as Origin is a degenerate form of stack
introspection.

>> Another question, since Firefox doesn't support redirects of
>> preflighted requests, what does it do when it encounters a redirect?
>
> It aborts and denies the original request. For XHR that means raising
> an error event.

It's worth wondering whether web pages will come to rely on these
requests being aborted and so be vulnerable should a future release
not abort the requests.

--Tyler

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

[Maciej Stachowiak]

On Jun 24, 2009, at 4:29 AM, Arthur Barstow wrote:

> Members of the Web Apps WG,
>
> Below is an email from Henry Thompson (forwarded with his  
> permission), on behalf of the TAG [1], re the CORS spec [2].
>
> Two things:
>
> 1. Please respond to at least this part of Henry's mail:
>
> [[
> It appeared to us that a number of significant criticisms of the
> appropriateness of CORS have been submitted to the Working Group, from
> respected members of the Web Security community among others. These
> convinced us that there is a real possibility either that server-side
> deployment won't happen, or that even if it did the new functionality
> provided would, on the one hand, be insufficiently secure while, on  
> the
> other, discouraging the provision of something more satisfactory.
> ]]
>
> 2. For those that have been active in defining the CORS model and/or  
> CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej,  
> IE guys (whomever replaced Sunava) - please indicate:
>
> a) their level of interest in continuing to push the current CORS  
> model;

Apple and the WebKit project would be reluctant to make major changes  
to the model at this point unless its security was broken in ways that  
could not reasonably be patched with minor changes.

> b) their implementation plans for CORS.

We have shipped what I believe is an essentially complete  
implementation of CORS as of Safari 4. I believe it is also present or  
soon will be in other WebKt-based browsers, such as Google Chrome.

Regards,
Maciej

[bilcorry]

Tyler Close wrote on 6/24/2009 4:26 PM:

> On Wed, Jun 24, 2009 at 1:37 PM, Jonas Sicking<jonas@...> wrote:
>> On Wed, Jun 24, 2009 at 12:52 PM, Tyler Close<tyler.close@...> wrote:
>>> Hi Jonas,
>>>
>>> I'm just asking what Origin header behavior will be shipped in Firefox
>>> 3.5. You've said redirects of preflighted requests aren't supported,
>>> so I'm wondering about the non-preflighted requests.
>> It will have the Origin header of the original request. We're
>> considering blocking the request entirely for now though.
>
> Meaning the POST request is delivered to Site A, with an Origin header
> also identifying Site A, but with a Request-URI chosen by Site B. So
> Site B can cause the POST request to be sent to any resource on Site A
> and be processed under Site A's authority. I recommend against
> shipping that algorithm.

When this came up before, it was dismissed because "the practice of Site A submitting a form to untrusted site B is likely to be quite rare and easily avoidable":

        http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0108.html


- Bil

[Adam Barth-5]

On Wed, Jun 24, 2009 at 12:43 PM, Jonas Sicking<jonas@...> wrote:
> As for the "Origin" spec that Adam Barth is working on, I'm not sure
> that the last draft is published yet, but I believe that the idea is
> to append the full redirect chain in the Origin header. (hence
> possibly making it incompatible with the CORS "Origin" meaning that
> we'll have to use another name).

I've uploaded the latest draft just now:

http://www.ietf.org/internet-drafts/draft-abarth-origin-01.txt

The draft now uses a different header name to avoid conflicting with
CORS and behaves as Jonas describes.

Adam

[bilcorry]

Adam Barth wrote on 6/24/2009 6:16 PM:

> On Wed, Jun 24, 2009 at 12:43 PM, Jonas Sicking<jonas@...> wrote:
>> As for the "Origin" spec that Adam Barth is working on, I'm not sure
>> that the last draft is published yet, but I believe that the idea is
>> to append the full redirect chain in the Origin header. (hence
>> possibly making it incompatible with the CORS "Origin" meaning that
>> we'll have to use another name).
>
> I've uploaded the latest draft just now:
>
> http://www.ietf.org/internet-drafts/draft-abarth-origin-01.txt
>
> The draft now uses a different header name to avoid conflicting with
> CORS and behaves as Jonas describes.

Why is the spec providing a choice for how to handle redirects?

-----
Whenever a user agent issues an HTTP request to URI /A/ as a result
   of an HTTP redirect from URI /B/, the user agent MUST either:

   1.  set the value of the Sec-From header in the HTTP request to /A/
       to "null" (i.e., the character sequence U+006E, U+0075, U+006C,
       U+006C),

   2.  set the value of the Sec-From header in the /A/ request to the
       value of the Sec-From header in the /B/ request extended with a
       space and the ASCII serialization of the origin of /B/, unless
       this would result in the header containing the origin
       serialization "null".
-----

Or is it saying that if #2 doesn't apply, then #1?


- Bil

[Mark S. Miller-2]

On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren <annevk@...> wrote:

On Wed, 24 Jun 2009 13:29:38 +0200, Arthur Barstow <Art.Barstow@...> wrote:

1. Please respond to at least this part of Henry's mail:

[[
It appeared to us that a number of significant criticisms of the
appropriateness of CORS have been submitted to the Working Group, from
respected members of the Web Security community among others. These
convinced us that there is a real possibility either that server-side
deployment won't happen, or that even if it did the new functionality
provided would, on the one hand, be insufficiently secure while, on the
other, discouraging the provision of something more satisfactory.
]]

I think the potential for security issues has been pointed out in the alternate proposals, not CORS itself. CORS has certainly not been found to be ideal, but something more satisfactory to all parties involved has not been proposed either. I would also classify the outstanding issues against CORS as minor.

Having said that, if there is something in particular you are thinking of it would be nice to explicitly point that out (and in case that email received a reply it would be good to point out why that reply did not address the point in question).

As is widely recognized, CSRF is a form of confused deputy attack <http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html>. >From the beginning, the diagnosis of the underlying problem leading to confused deputies is the use of ambient authority rather than designated authority[1].   The introduction of the CORS identified Origin header mechanism is justified as a way to mitigate confused deputies. This not only fails to address the underlying problem, it amplifies it by introducing yet another form of ambient authority -- identified Origins which servers are expected to use to make access control decisions.

The current prevelent practice for avoid CSRF problems is the "secret token" defense. This is a form of designated authority, and can be used correctly to avoid confused deputies. The main (only?) argument against it seems to be that it is accident prone -- that it can be and has been used badly, thereby failing to protect against confused deputies. This criticism is correct. It would be wonderful if a sound safer alternative were known. However, what we are offered in its place -- identified Origins -- can only be used correctly by not using it to make access control decisions.

Adam is aware of this problem. When pressed, he agrees that identified Origin only reduces the frequency of confused deputy problems, without providing the developer any clear line between patterns that are safe and those that are not. Is it progress to reduce the frequency of holes while leaving these holes undiagnosable?

Adam, if I have not summarized your position accurately, please correct. Thanks.

2. For those that have been active in defining the CORS model and/or CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE guys (whomever replaced Sunava) - please indicate:

a) their level of interest in continuing to push the current CORS model;

I'm happy to continue as editor.

b) their implementation plans for CORS.

I cannot comment on behalf of Opera on this. I can point out that Safari 4 and Chrome 2 ship with it and that Firefox 3.5 will too. (No implementation will support redirects yet though, as I understand things.) Internet Explorer 8 supports a subset of the protocol.

IIUC, the XDR subset IE8 supports does not include identified Origin or preflight, and so avoids most of the problems created by full CORS. However, it still presents user credentials (http auth, cookies, client-side certs, referer), and so still has many of the same remaining ambient authority problems. Nevertheless, it remains a more plausible starting point than identified Origin.

An earlier proposal, JSONRequest <http://www.json.org/JSONRequest.html>, which IIRC you dismissed for being non-RESTful, presents no user credentials or preflight by design. Like CORS, it was originally speced to present the originating page's Origin. But JSONRequest has since dropped that explicitly in order to avoid introducing new sources of ambient authority. Given that CORS makes RESTful programming too expensive to remain practical, it is ironic that JSONRequest was dropped for being non-RESTful.

[1] See for example the section on confused deputy in <http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf>. I thought David Wagner's Google techtalk explained "ambient authority" especially clearly <David Wagner's Google techtalk>. Tyler's "ACLs Don't" <David Wagner's Google techtalk> explains well how these problems translate into a web context. Kragen Sitaker's <http://lists.canonical.org/pipermail/kragen-tol/2000-August/000619.html> is still worth reading for more than historic interest. Nine years later, we are still discussing "defenses" that don't address the original problem.

--
   Cheers,
   --MarkM

[Mark S. Miller-2]

On Wed, Jun 24, 2009 at 6:39 PM, Mark S. Miller <erights@...> wrote:

[1] See for example the section on confused deputy in <http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf>. I thought David Wagner's Google techtalk explained "ambient authority" especially clearly <David Wagner's Google techtalk>. Tyler's "ACLs Don't" <David Wagner's Google techtalk> explains well how these problems translate into a web context. Kragen Sitaker's <http://lists.canonical.org/pipermail/kragen-tol/2000-August/000619.html> is still worth reading for more than historic interest. Nine years later, we are still discussing "defenses" that don't address the original problem.

Oops. Weird copy-paste error. 

David Wagner's Google techtalk is at <http://www.youtube.com/watch?v=EGX2I31OhBE>.
Tyler's "ACLs Don't" is at <http://waterken.sourceforge.net/aclsdont/>.

--
   Cheers,
   --MarkM

[Adam Barth-5]

On Wed, Jun 24, 2009 at 5:42 PM, Bil Corry<bil@...> wrote:
> Adam Barth wrote on 6/24/2009 6:16 PM:
>> I've uploaded the latest draft just now:
>>
>> http://www.ietf.org/internet-drafts/draft-abarth-origin-01.txt
>>
>> The draft now uses a different header name to avoid conflicting with
>> CORS and behaves as Jonas describes.
>
> Why is the spec providing a choice for how to handle redirects?

It's always secure to send null in the header.  In some cases, you
might have a really long redirect chain and the UA might want to bound
the header to some length.

> Or is it saying that if #2 doesn't apply, then #1?

It says precisely what it says.  The UA MUST either do (1) or (2).
Sometimes it can't do (2).  In those cases it MUST do (1).  Sometimes
the UA might be able to do (2) but choose to do (1) anyway.

Adam