Re: [cors] TAG request concerning CORS Next Step(s)
On Thu, 22 Oct 2009 20:00:02 +0200, Henry S. Thompson h...@inf.ed.ac.uk wrote: Sorry for the delay -- the discussion has clarified the current relevance of client-side implementations, and as far as that goes the TAG is happy. We do assume that demonstrating interoperable server-side implementation will be a necessary part of your CR exit criteria -- could you please confirm that? I'm not sure how that would work. Demonstrating you can implement this in Python or PHP? -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] TAG request concerning CORS Next Step(s)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anne van Kesteren writes: On Wed, 24 Jun 2009 19:22:35 +0200, Henry S. Thompson h...@inf.ed.ac.uk wrote: 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? As was pointed out elsewhere in this thread it was. I was wondering if the TAG considers this item closed or wishes to know something more, in which case I'd like to hear about it! I'm trying to wrap up email threads and this is one of them. Thanks! Sorry for the delay -- the discussion has clarified the current relevance of client-side implementations, and as far as that goes the TAG is happy. We do assume that demonstrating interoperable server-side implementation will be a necessary part of your CR exit criteria -- could you please confirm that? Thanks, 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: (44) 131 651-1426, e-mail: h...@inf.ed.ac.uk 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) iD8DBQFK4J2ikjnJixAXWBoRAoCzAJsGbrTwREEvYUIB25RbqniCoFC3AACeJCjF Y8YY4y8GJ7LNv6b5hV1qYYI= =zia5 -END PGP SIGNATURE-
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, 24 Jun 2009 19:22:35 +0200, Henry S. Thompson h...@inf.ed.ac.uk wrote: 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? As was pointed out elsewhere in this thread it was. I was wondering if the TAG considers this item closed or wishes to know something more, in which case I'd like to hear about it! I'm trying to wrap up email threads and this is one of them. Thanks! Kind regards, PS: The remainder of this thread about redirects and CSRF is being taken care of by updates to both CORS and the Origin header draft Adam is working on. In short Origin will most likely become a space-separated list revealing the entire request chain. -- Anne van Kesteren http://annevankesteren.nl/
Re: [cors] TAG request concerning CORS Next Step(s)
On Thu, Oct 8, 2009 at 8:06 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 24 Jun 2009 19:22:35 +0200, Henry S. Thompson h...@inf.ed.ac.uk wrote: 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? As was pointed out elsewhere in this thread it was. The core criticism that several of us have raised about CORS has never been addressed -- that it creates further confused deputy problems. Rather than addressing the first order confused deputy problem of CSRF, it merely postpones it one level, creating second order confused deputy problems. See Tyler's example. I was wondering if the TAG considers this item closed or wishes to know something more, in which case I'd like to hear about it! I'm trying to wrap up email threads and this is one of them. Thanks! If the confused deputy problems created by CORS have already been addressed, I'd like to hear about that. Did I miss part of the thread? Kind regards, PS: The remainder of this thread about redirects and CSRF is being taken care of by updates to both CORS and the Origin header draft Adam is working on. In short Origin will most likely become a space-separated list revealing the entire request chain. Please go back and read Origin isn't. The redirect problem Tyler pointed out was merely a symptom of a deeper problem. Tyler was able to identify this symptom because he does not regard the underlying problem as merely theoretical. The Origin list solution is curing the symptom only. -- Anne van Kesteren http://annevankesteren.nl/ -- Cheers, --MarkM
[cors] TAG request concerning CORS Next Step(s)
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 h...@inf.ed.ac.uk Date: June 23, 2009 5:18:51 PM EDT To: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com, Charles McCathieNevile cha...@opera.com 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
Re: [cors] TAG request concerning CORS Next Step(s)
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
Re: [cors] TAG request concerning CORS Next Step(s)
-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: (44) 131 651-1426, e-mail: h...@inf.ed.ac.uk 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-
Re: [cors] TAG request concerning CORS Next Step(s)
Henry S. Thompson h...@inf.ed.ac.uk, 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/
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 10:16 AM, Jonas Sickingjo...@sicking.cc 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
Re: [cors] TAG request concerning CORS Next Step(s)
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*
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 11:45 AM, Tyler Closetyler.cl...@gmail.com wrote: On Wed, Jun 24, 2009 at 10:16 AM, Jonas Sickingjo...@sicking.cc 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
Re: [cors] TAG request concerning CORS Next Step(s)
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 Sickingjo...@sicking.cc wrote: On Wed, Jun 24, 2009 at 11:45 AM, Tyler Closetyler.cl...@gmail.com wrote: On Wed, Jun 24, 2009 at 10:16 AM, Jonas Sickingjo...@sicking.cc 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
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 12:52 PM, Tyler Closetyler.cl...@gmail.com 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
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 1:37 PM, Jonas Sickingjo...@sicking.cc wrote: On Wed, Jun 24, 2009 at 12:52 PM, Tyler Closetyler.cl...@gmail.com 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
Re: [cors] TAG request concerning CORS Next Step(s)
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
Re: [cors] TAG request concerning CORS Next Step(s)
Tyler Close wrote on 6/24/2009 4:26 PM: On Wed, Jun 24, 2009 at 1:37 PM, Jonas Sickingjo...@sicking.cc wrote: On Wed, Jun 24, 2009 at 12:52 PM, Tyler Closetyler.cl...@gmail.com 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
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 12:43 PM, Jonas Sickingjo...@sicking.cc 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
Re: [cors] TAG request concerning CORS Next Step(s)
Adam Barth wrote on 6/24/2009 6:16 PM: On Wed, Jun 24, 2009 at 12:43 PM, Jonas Sickingjo...@sicking.cc 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
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 24 Jun 2009 13:29:38 +0200, Arthur Barstow art.bars...@nokia.com 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,
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 6:39 PM, Mark S. Miller erig...@google.com 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
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 5:42 PM, Bil Corryb...@corry.biz 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
RE: [cors] TAG request concerning CORS Next Step(s)
On Wednesday, June 24, 2009 6:39 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: 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. IE8 strips user credentials such as cookies from XDR requests and supports only GET and POST. It does send the Origin header used for CORS and responds to Access-Control-Allow-Origin. We don't support preflight. Adrian.
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 8:17 PM, Adrian Bateman adria...@microsoft.comwrote: On Wednesday, June 24, 2009 6:39 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: 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. IE8 strips user credentials such as cookies from XDR requests and supports only GET and POST. It does send the Origin header used for CORS and responds to Access-Control-Allow-Origin. We don't support preflight. Hi Adrian, thanks for the clarification. When you say it strips user credentials such as cookies, what about http auth info, client side certs, and referrer? Regarding the Origin header, how does XDR handle redirects? -- Cheers, --MarkM
Re: [cors] TAG request concerning CORS Next Step(s)
Adam Barth wrote on 6/24/2009 10:09 PM: On Wed, Jun 24, 2009 at 5:42 PM, Bil Corryb...@corry.biz 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. As written, a conforming UA could choose to always send NULL for redirects, which would be unfortunate. More concerning though, a conforming UA could choose to always send NULL for *all* HTTP requests. Might it be better to more strictly define the behavior? - Bil
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 6:39 PM, Mark S. Millererig...@google.com wrote: On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: 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. My understanding is that the CORS use of the Origin header is mostly to protect the confientiality of resources on the server. For example, if (1) the server wishes to reveal a particular piece of information to some origins by not to others and (2) the server does not wish to reveal the list of allowed origins to everyone, then the server can use the Origin header to make the access control decision on the server. 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. The Sec-From header (the new name of Origin-for-CSRF-defense) helps servers operators mitigate CSRF vulnerabilities using web application firewall rules. It is progress to reduce to the frequency of CSRF vulnerabilities. Adam
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 8:42 PM, Bil Corryb...@corry.biz wrote: As written, a conforming UA could choose to always send NULL for redirects, which would be unfortunate. That's correct. More concerning though, a conforming UA could choose to always send NULL for *all* HTTP requests. That's correct. Might it be better to more strictly define the behavior? That's why the draft says: Whenever a user agent issues an HTTP request that (1) is *not* the result of an HTTP redirect and (2) is *not* initiated from a privacy-sensitive context, the user agent SHOULD set the value of the Sec-From header to the ASCII serialization of the origin that initiated the HTTP request. Adam
RE: [cors] TAG request concerning CORS Next Step(s)
On Wednesday, June 24, 2009 8:25 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:17 PM, Adrian Bateman adria...@microsoft.com wrote: On Wednesday, June 24, 2009 6:39 PM, Mark S. Miller wrote: On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote: 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. IE8 strips user credentials such as cookies from XDR requests and supports only GET and POST. It does send the Origin header used for CORS and responds to Access-Control-Allow-Origin. We don't support preflight. Hi Adrian, thanks for the clarification. When you say it strips user credentials such as cookies, what about http auth info, client side certs, and referrer? Regarding the Origin header, how does XDR handle redirects? XDR is designed for accessing public resources. It passes no authentication information, requests for client certs are dropped, and since it's a one off request there is no referrer. If I recall correctly, the Origin header is sent for each step of the redirect and each 30x response (and the final response) is expected to include an Access-Control-Allow-Origin header with either the value * or a string match of the value of the Origin header.
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 8:46 PM, Adam Barth w...@adambarth.com wrote:
My understanding is that the CORS use of the Origin header is mostly
to protect the confientiality of resources on the server. For
example, if (1) the server wishes to reveal a particular piece of
information to some origins by not to others and (2) the server does
not wish to reveal the list of allowed origins to everyone, then the
server can use the Origin header to make the access control decision
on the server.
The server can sensibly wish to reveal a particular piece of information to
those parties that it thinks should be authorized to learn that information.
Without assuming your conclusion, why should the server wish to identify
those parties with ambient origins rather than designated secret tokens? As
security architects, shouldn't we promote mechanisms that encourage
securable patterns of use?
It is progress to reduce to the frequency of CSRF vulnerabilities.
// in two threads concurrently
loop {
repeat 100 times {}
//unprotected critical section begins
*p += 1;
//unprotected critical section ends
}
If we change the number of repetitions in the nested loop from 100 to 1000,
we reduce the frequency with which this race condition bug corrupts the
program. Is this progress?
--
Cheers,
--MarkM
Re: [cors] TAG request concerning CORS Next Step(s)
On Wed, Jun 24, 2009 at 10:12 PM, Mark S. Millererig...@google.com wrote:
The server can sensibly wish to reveal a particular piece of information to
those parties that it thinks should be authorized to learn that information.
Without assuming your conclusion, why should the server wish to identify
those parties with ambient origins rather than designated secret tokens?
One reason is to avoid the hassle of sharing secret tokens.
How exactly do you envision secret tokens working? Suppose Google
Finance wants to let Acme Finance XHR for stock ticker information.
How does Acme Finance get the secret tokens? Presumably Acme has to
use a fresh token for each request so that Bob's Finance can't just
grab Acme's token from their home page. Now, for each request, Acme
Finance has to contact Google Finance on the backend and get a token.
Sounds like a pain.
By contrast, CORS makes this use case super easy.
As security architects, shouldn't we promote mechanisms that encourage
securable patterns of use?
I don't consider myself a security architect.
It is progress to reduce to the frequency of CSRF vulnerabilities.
// in two threads concurrently
loop {
repeat 100 times {}
//unprotected critical section begins
*p += 1;
//unprotected critical section ends
}
If we change the number of repetitions in the nested loop from 100 to 1000,
we reduce the frequency with which this race condition bug corrupts the
program. Is this progress?
I don't see the connection to what we're discussing. There's no
randomness in CSRF. In any case, this part of the discussion is a bit
off topic. The TAG asked about CORS, not CSRF.
Adam
