Re: CORS performance proposal
On 8 June 2015 at 21:30, Nottingham, Mark mnott...@akamai.com wrote: A header denoting site-wide metadata would work for this too, of course, if folks were comfortable with the security properties of doing that (as well as the potential response overhead). The security properties bother me a little. Alt-Svc is showing us that we can't just define a header field like that without some serious analysis.
Re: CORS performance proposal
Picking up an old thread... On 20 Feb 2015, at 12:54 pm, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Martin Thomson wrote: On 20 February 2015 at 11:39, Bjoern Hoehrmann derhoe...@gmx.net wrote: The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`. I missed that. In which case I'd point out that `OPTIONS *` is very poorly supported. Some people (myself included) want it to die a flaming death. Evidence for poorly supported would certainly be helpful (web hosting packages without TLS support, for instance, do not count, though). FWIW, this is old but I think still true, at least regarding OPTIONS *: https://www.mnot.net/blog/2005/04/03/options I wrote up my thoughts about using OPTIONS after looking at it for many years: https://www.mnot.net/blog/2012/10/29/NO_OPTIONS Also - it's becoming more common for content providers to ask CDNs for CORS preflight caching. Since OPTIONS doesn't fit into HTTP caching, something custom has to be designed, which means dealing with all of the corner cases, interop issues, etc. Using a .well-known would avoid all of that, since it can be cached just like any other response. If there's concern about extra requests against origins that don't use this mechanism, I'd suggest defining a default cacheability for 404 responses on the resource (e.g., 3 hours). That said, I suspect that if this were defined, take-up would be good; it's much easier than supporting pre-flights. A header denoting site-wide metadata would work for this too, of course, if folks were comfortable with the security properties of doing that (as well as the potential response overhead). Cheers, -- Mark Nottinghamm...@akamai.comhttps://www.mnot.net/
Re: CORS performance proposal
On Tue, Jun 9, 2015 at 6:42 AM, Martin Thomson martin.thom...@gmail.com wrote: The security properties bother me a little. Alt-Svc is showing us that we can't just define a header field like that without some serious analysis. Same goes for a site-wide file. See crossdomain.xml. However, either coupled with credentials mode = omit seems okayish... Mark, do these CDN requests mention credentials? -- https://annevankesteren.nl/
Re: CORS performance proposal
On 9 Jun 2015, at 2:42 pm, Martin Thomson martin.thom...@gmail.com wrote: On 8 June 2015 at 21:30, Nottingham, Mark mnott...@akamai.com wrote: A header denoting site-wide metadata would work for this too, of course, if folks were comfortable with the security properties of doing that (as well as the potential response overhead). The security properties bother me a little. Alt-Svc is showing us that we can't just define a header field like that without some serious analysis. Indeed. Also, an intermediary cache (whether a proxy or a CDN) would need to monitor all of the headers sent back for a given origin to figure out the applicable policy, and rewrite responses accordingly. It wouldn't just work out of the box like a .well-known would. Cheers, -- Mark Nottinghamm...@akamai.comhttps://www.mnot.net/
Re: CORS performance proposal
On 9 Jun 2015, at 2:54 pm, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jun 9, 2015 at 6:42 AM, Martin Thomson martin.thom...@gmail.com wrote: The security properties bother me a little. Alt-Svc is showing us that we can't just define a header field like that without some serious analysis. Same goes for a site-wide file. See crossdomain.xml. However, either coupled with credentials mode = omit seems okayish... Mark, do these CDN requests mention credentials? Will look into it. Supporting without credentials (and leaving future extensibility for the possibility) would certainly be a good start. Cheers, -- Mark Nottinghamm...@akamai.comhttps://www.mnot.net/
Re: CORS performance proposal
On Sat, Feb 21, 2015 at 11:18 PM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Feb 21, 2015 at 10:17 AM, Martin Thomson martin.thom...@gmail.com wrote: On 21 February 2015 at 20:43, Anne van Kesteren ann...@annevk.nl wrote: High-byte of what? A URL is within ASCII range when it reaches the server. This is the first time I hear of this. Apparently, all sorts of muck floats around the Internet. When we did HTTP/2 we were forced to accept that header field values (URLs in particular) were a sequence of octets. Those are often interpreted as strings in various interesting ways. But in this particular case it must be the browser that generates said muck, no? Other than Internet Explorer (and that's a couple versions ago, so wouldn't support this protocol anyway), there's no browser that does this as far as I know. All browsers support sending %xx stuff to the server. Decoding those is likely more often than not happening in a server-specific way still. Despite specs defining how they should do it. / Jonas
Re: CORS performance proposal
On Fri, Feb 20, 2015 at 11:43 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Feb 20, 2015 at 9:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Feb 20, 2015 at 1:05 AM, Anne van Kesteren ann...@annevk.nl wrote: An alternative is that we attempt to introduce Access-Control-Policy-Path again from 2008. The problems you raised https://lists.w3.org/Archives/Public/public-appformats/2008May/0037.html seem surmountable. URL parsing is defined in more detail these days and we could simply ban URLs containing escaped \ and /. I do remember that another issue that came up back then was that servers would treat more than just '\', or the escaped version thereof, as a /. But also any character whose low-byte was equal to the ascii code for '\' or '/'. I.e. the server would just cut the high-byte when doing some internal 2byte-string to 1byte-string conversion. Potentially this conversion is affected by what character encodings the server is configured for too, but i'm less sure about that. High-byte of what? A URL is within ASCII range when it reaches the server. This is the first time I hear of this. I really don't remember the details. I'd recommend talking to microsoft since I believe they had done most research into this at the time. Keep in mind though that just because URL parsing is defined a particular way, doesn't mean that software implements it that way. / Jonas
Re: CORS performance proposal
On Sat, Feb 21, 2015 at 10:17 AM, Martin Thomson martin.thom...@gmail.com wrote: On 21 February 2015 at 20:43, Anne van Kesteren ann...@annevk.nl wrote: High-byte of what? A URL is within ASCII range when it reaches the server. This is the first time I hear of this. Apparently, all sorts of muck floats around the Internet. When we did HTTP/2 we were forced to accept that header field values (URLs in particular) were a sequence of octets. Those are often interpreted as strings in various interesting ways. But in this particular case it must be the browser that generates said muck, no? Other than Internet Explorer (and that's a couple versions ago, so wouldn't support this protocol anyway), there's no browser that does this as far as I know. I wouldn't *completely* discount the potential for the conversions Jonas mentions here. A Java server might parse UTF-8 into the internal UTF-16 representation and then who knows what happens next. There's no utf-8 either. -- https://annevankesteren.nl/
Re: CORS performance proposal
On 21 February 2015 at 20:43, Anne van Kesteren ann...@annevk.nl wrote: High-byte of what? A URL is within ASCII range when it reaches the server. This is the first time I hear of this. Apparently, all sorts of muck floats around the Internet. When we did HTTP/2 we were forced to accept that header field values (URLs in particular) were a sequence of octets. Those are often interpreted as strings in various interesting ways. I wouldn't *completely* discount the potential for the conversions Jonas mentions here. A Java server might parse UTF-8 into the internal UTF-16 representation and then who knows what happens next.
Re: CORS performance proposal
On Thu, Feb 19, 2015 at 9:22 PM, Jonas Sicking jo...@sicking.cc wrote: Would this be allowed for both requests with credentials and requests without credentials? The security implications of the two are very different. Yes, but the latter requires the Access-Control-Allow-Credentials header to be included in the response. An alternative is that we attempt to introduce Access-Control-Policy-Path again from 2008. The problems you raised https://lists.w3.org/Archives/Public/public-appformats/2008May/0037.html seem surmountable. URL parsing is defined in more detail these days and we could simply ban URLs containing escaped \ and /. -- https://annevankesteren.nl/
Re: CORS performance proposal
On Fri, Feb 20, 2015 at 9:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Feb 20, 2015 at 1:05 AM, Anne van Kesteren ann...@annevk.nl wrote: An alternative is that we attempt to introduce Access-Control-Policy-Path again from 2008. The problems you raised https://lists.w3.org/Archives/Public/public-appformats/2008May/0037.html seem surmountable. URL parsing is defined in more detail these days and we could simply ban URLs containing escaped \ and /. I do remember that another issue that came up back then was that servers would treat more than just '\', or the escaped version thereof, as a /. But also any character whose low-byte was equal to the ascii code for '\' or '/'. I.e. the server would just cut the high-byte when doing some internal 2byte-string to 1byte-string conversion. Potentially this conversion is affected by what character encodings the server is configured for too, but i'm less sure about that. High-byte of what? A URL is within ASCII range when it reaches the server. This is the first time I hear of this. -- https://annevankesteren.nl/
Re: CORS performance proposal
Would this be allowed for both requests with credentials and requests without credentials? The security implications of the two are very different. / Jonas On Thu, Feb 19, 2015 at 5:29 AM, Anne van Kesteren ann...@annevk.nl wrote: When the user agent is about to make its first preflight to an origin (timeout up to the user agent), it first makes a preflight that looks like: OPTIONS * Access-Control-Request-Origin-Wide-Cache: [origin] Access-Control-Request-Method: * Access-Control-Request-Headers: * If the response is 2xx XX Access-Control-Allow-Origin-Wide-Cache: [origin] Access-Control-Allow-Methods: * Access-Control-Allow-Headers: * Access-Control-Max-Age: [max-age] then no more preflights will be made for the duration of [max-age] (or shortened per user agent preference). If the response includes Access-Control-Allow-Credentials: true the cache scope is increased to requests that include credentials. I think this has a reasonable tradeoff between security and opening up all the power of the HTTP APIs on the server without the performance hit. It still makes the developer very conscious about the various features involved. The cache would be on a per requesting origin basis as per the headers above. The Origin and Access-Control-Allow-Origin would not take part in this exchange, to make it very clear what this is about. (This does not affect Access-Control-Expose-Headers or any of the other headers required as part of non-preflight responses.) -- https://annevankesteren.nl/
Re: CORS performance proposal
On 20 February 2015 at 00:29, Anne van Kesteren ann...@annevk.nl wrote: Access-Control-Allow-Origin-Wide-Cache: [origin] This has some pretty implications for server deployments that host mutual distrustful applications. Now, these servers are already pretty well hosed from other directions, but I don't believe that there is any pre-existing case where a header field set in a request to /x could affect future requests to /y. An alternative would be to use /.well-known for site wide policies.
Re: CORS performance proposal
The cache would be on a per requesting origin basis as per the headers above. The Origin and Access-Control-Allow-Origin would not take part in this exchange, to make it very clear what this is about. I dont want to conflate what could be seperate proposals, but they seem closely related, this would improve the situation for easing the number of preflight requests to be made, however still requires servers to follow what is a fairly complicated process of setting up the appropriate headers What if we allowed one of the response fields to denote this url is on the public internet, please dont bother with cors restrictions. This means the process of setting up cors could be to ensure a single response returns with the appropriate headers and servers no longer need to worry about every possible headers clients can send to each particular url. (Clients would have to set a custom header to ensure the preflight optimisation was skipped I believe) This would be very much in line with how it was implemented for flash - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html On 19 February 2015 at 13:29, Anne van Kesteren ann...@annevk.nl wrote: When the user agent is about to make its first preflight to an origin (timeout up to the user agent), it first makes a preflight that looks like: OPTIONS * Access-Control-Request-Origin-Wide-Cache: [origin] Access-Control-Request-Method: * Access-Control-Request-Headers: * If the response is 2xx XX Access-Control-Allow-Origin-Wide-Cache: [origin] Access-Control-Allow-Methods: * Access-Control-Allow-Headers: * Access-Control-Max-Age: [max-age] then no more preflights will be made for the duration of [max-age] (or shortened per user agent preference). If the response includes Access-Control-Allow-Credentials: true the cache scope is increased to requests that include credentials. I think this has a reasonable tradeoff between security and opening up all the power of the HTTP APIs on the server without the performance hit. It still makes the developer very conscious about the various features involved. The cache would be on a per requesting origin basis as per the headers above. The Origin and Access-Control-Allow-Origin would not take part in this exchange, to make it very clear what this is about. (This does not affect Access-Control-Expose-Headers or any of the other headers required as part of non-preflight responses.) -- https://annevankesteren.nl/
Re: CORS performance proposal
On Thu, Feb 19, 2015 at 5:29 AM, Anne van Kesteren ann...@annevk.nl wrote: When the user agent is about to make its first preflight to an origin (timeout up to the user agent), it first makes a preflight that looks like: OPTIONS * Access-Control-Request-Origin-Wide-Cache: [origin] Access-Control-Request-Method: * Access-Control-Request-Headers: * This would make CORS preflight even slower for every server that doesn't implement the new proposal (i.e. every currently-deployed server and probably most servers deployed in the future). Perhaps the OPTIONS * request could be made in parallel with the initial preflight requests. But, then, what happens when the information in the OPTIONS * response conflicts with the information in the normal preflight request? I think this has a reasonable tradeoff between security and opening up all the power of the HTTP APIs on the server without the performance hit. It still makes the developer very conscious about the various features involved. I think developer consciousness is exactly the issue here: 1. Let's say you want to add OPTIONS * preflight support to an existing web application. How do you go about finding all the things that need to change to make that safe to do? It seems very difficult to successfully find every place the app assumes it is protected by the fact that it doesn't do CORS. 2. Similar to #1, let's say that two teams develop two parts of a website. One of the teams follows normal CORS rules and the other depends on the proposed OPTIONS * mechanism. This would be a disaster if/when both apps are deployed on the same origin. 3. Because of these issues, an organization forces its developers to develop every app as though every resource is CORS-enabled, to future-proof against the scenerio where OPTIONS * is deployed in the future. This makes the development of the web app more difficult and slower. 4. In the discussion of Entry Point Regulation (EPR) on WebAppSec, the main argument in favor of it is that it is impossible for developers to do things like #3 correctly and it is unreasonable for us to expect them to. I'm don't buy the EPR argument completely, but I do see some merit in the underlying secure by default argument behind EPR. Because of these concerns, I think that it would be worthwhile to study a concrete example of the problem, to make sure we correctly understand the use case we're trying to solve. As we saw yesterday with the PouchDB/CouchDB example, it is easy to accidentally and unnecessarily force a preflight. It may also be the case that we can find other, safer, ways to avoid preflights and/or optimize how they are done, such as by optimizing CORS for use with HTTP/2 server push mechanisms. But, we need to see real instances of the problem first. Cheers, Brian
Re: CORS performance proposal
* Martin Thomson wrote: On 20 February 2015 at 00:29, Anne van Kesteren ann...@annevk.nl wrote: Access-Control-Allow-Origin-Wide-Cache: [origin] This has some pretty implications for server deployments that host mutual distrustful applications. Now, these servers are already pretty well hosed from other directions, but I don't believe that there is any pre-existing case where a header field set in a request to /x could affect future requests to /y. An alternative would be to use /.well-known for site wide policies. The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/
Re: CORS performance proposal
* Martin Thomson wrote: On 20 February 2015 at 11:39, Bjoern Hoehrmann derhoe...@gmx.net wrote: The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`. I missed that. In which case I'd point out that `OPTIONS *` is very poorly supported. Some people (myself included) want it to die a flaming death. Evidence for poorly supported would certainly be helpful (web hosting packages without TLS support, for instance, do not count, though). -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/
Re: CORS performance proposal
On 20 February 2015 at 11:39, Bjoern Hoehrmann derhoe...@gmx.net wrote: The proposal is to use `OPTIONS * HTTP/1.1` not `OPTIONS /x HTTP/1.1`. I missed that. In which case I'd point out that `OPTIONS *` is very poorly supported. Some people (myself included) want it to die a flaming death.
