Re: Value of Server-Sent Events
On Sat, 24 Oct 2009, Michael Nordman wrote: > On Fri, Oct 23, 2009 at 8:45 PM, Ian Hickson wrote: > > On Fri, 23 Oct 2009, Michael Nordman wrote: > > > > > > An area that may be worth exploring, that would add to the list > > > things that go beyond syntactic sugar, could be for multiple > > > documents to listen in on the same event-stream backed by the same > > > connection to the server. This could reduce the total number of > > > hanging GET style connections used by an application (spread across > > > multiple pages / workers) on a particular client, and by extension > > > the number of connections seen by the server-side. > > > > The spec technically allows this already, though as written it > > requires sending all the same messages again, so it's not really > > practical (and loses the "don't have to hang on to everything" > > advantage). It's not clear to me how we would know which messages are > > skippable -- maybe in v2 we can add a flag that indicates that this > > message block should be remembered, and another flag to indicate that > > all previous remembered messages should be dropped, or something like > > that, and when a new page hooks in, if the event source supports it, > > it would just get the saved messages and then resume with whatever the > > next message is. > > > sending all the same messages again... flag that indicates... remembered "sending all the same messages again" may have been a poor use of words. I meant that all the events already received by the browser on the existing connection would be (re)dispatched to the new EventSource object. I agree that's suboptimal; to get around that we'd need a way for the server to opt-in to a system whereby people can join in half-way and only get new messages. To do that, though, while still supporting the case of some messages being critical (e.g. a message saying how the rest of the messages are to be decompressed), we'd need a mechanism to indicate "critical" messages that are to be stored and dispatched to any new clients when a new EventSource object to that URL is created. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Value of Server-Sent Events
On Fri, Oct 23, 2009 at 8:45 PM, Ian Hickson wrote:
> On Fri, 23 Oct 2009, Michael Nordman wrote:
> >
> > An area that may be worth exploring, that would add to the list things
> > that go beyond syntactic sugar, could be for multiple documents to
> > listen in on the same event-stream backed by the same connection to the
> > server. This could reduce the total number of hanging GET style
> > connections used by an application (spread across multiple pages /
> > workers) on a particular client, and by extension the number of
> > connections seen by the server-side.
>
> The spec technically allows this already, though as written it requires
> sending all the same messages again, so it's not really practical (and
> loses the "don't have to hang on to everything" advantage). It's not clear
> to me how we would know which messages are skippable -- maybe in v2 we can
> add a flag that indicates that this message block should be remembered,
> and another flag to indicate that all previous remembered messages should
> be dropped, or something like that, and when a new page hooks in, if the
> event source supports it, it would just get the saved messages and then
> resume with whatever the next message is.
>
> sending all the same messages again... flag that indicates... remembered
That's certainly not what I had in mind? I'll try to describe more clearly
what I was getting at with a simple contrived use-case. There's nothing
complicated about it.
There's a thermometer somewhere in the world connected to a web application
server. The web application server responds to two HTTP GET requests.
GET /current_temp
A short-lived request that returns a textual response that looks like {
"temp": 22.22, "time": "" }.
GET /temp_stream
This one is intended for use with a long-lived hanging GET (ala
event-stream). It returns a temp/time sample once every 60 seconds in the
same json format.
When a page opens the /temp_stream event-stream, it only receives temp/time
samples that occur after its having joined the party. This model wouldn't
work for all event-stream use cases, but for some it would.
How to distinguish which event-streams were "shareable" or not is an
interesting question? Maybe that's most properly a function of the
Content-Type of the event-stream?
> --
> Ian Hickson U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>
Re: [cors] unaddressed security concerns
Hi, Maciej- Maciej Stachowiak wrote (on 10/24/09 4:42 PM): On Oct 24, 2009, at 10:03 AM, Adam Barth wrote: On Fri, Oct 23, 2009 at 10:34 PM, Doug Schepers mailto:schep...@w3.org>> wrote: Sorry for being dense, but why couldn't the whitehats build toy systems on an open honeynet? I suspect we could do much more for the security of the web by writing up good tutorials and example code for using CORS than we could by tweaking various parts of the specification at this point. I think it would be valuable to put together a secure version of a simple use case. First, for tutorial value, and second, to show that it's possible to write a simple system that uses CORS without immediately creating a CSRF attack, and that you don't have to do anything super tricky to make it work. We don't need a hackathon contest to learn something from the exercise, our own analysis should be sufficient. Here's two potentially interesting simple scenarios: 1) Pure public data. a) Sever A offers a public data API at some URL - the API is accessed with GET and looks at the query part of the URL. b) The data is not user-specific, just public knowledge like a list of search hits or the answer to a math problem. c) The server opts in to public access to this data via "Access-Control-Allow-Origin: *" (on the URL providing the data API only). d) Server B accesses data via this API. Hypothesis: this does not introduce a CSRF vulnerability on Server A. 2) Simple per-user data. a) Server C offers a per-user data API at some per-user URL - the API is accessed with GET and looks at the query part of the URL. b) The data is user-specific (e.g. list of contacts from an address book), determining what user c) Server C allows the user to grant access to this data to a specific other origin on a per-user basis. d) For users that have not opted in, cross-origin access to the data is refused (by not sending any special Access-Control headers). e) For users that have opted in, Server C responds to normal and preflight requests with Access-Control-Allow-Origin including the allowed other servers only, and Access-Control-Allow-Credentials. f) Inside the implementation of the URL, the server checks Origin to determine if the request should be allowed. g) For requests missing Origin, the server rejects the request (in a realistic deployment it might use a secret token mechanism to allow self requests in legacy browsers). h) For requests from an appropriate Origin but missing cookies, the server returns no data, just a token indicating that the user needs to log in to Server C. i) For requests from an appropriate Origin and including cookies, the server returns the per-user data. j) Server D attempts to get per-user data from Server C using XHR+CORS with the credential flag set. k) If server D gets the "need to log in" error back, it gives the user a link to Server C's login page. Hypothesis: this does not introduce a CSRF vulnerability on Server C. Perhaps we could build examples along these lines and host them on Google App Engine or the like. Maybe we could also make versions that don't opt into CORS at all, to check specifically whether the addition of CORS created new vulnerabilities. Excellent concrete suggestions! This is along the lines I was driving at, but you've articulated it much better. If the larger security community has other suggestions for likely scenarios that they have concerns about, we could model those as well. Thanks- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: [cors] unaddressed security concerns
On Oct 24, 2009, at 10:03 AM, Adam Barth wrote: On Fri, Oct 23, 2009 at 10:34 PM, Doug Schepers wrote: Sorry for being dense, but why couldn't the whitehats build toy systems on an open honeynet? They could, but what would we learn from such an experiment? If they build only secure systems, then we'd learn that security experts can build secure systems, which is somewhat unsurprising. If they build insecure systems, then we'd learn that it is possible to build insecure systems, which we know already. The real question hinges around what sorts of systems real developers will build given CORS as a tool and whether we can prod them into building more secure systems by changing the API. There isn't really a way for us to answer that question in our ivory tower because it revolves around who writes blog posts about what, and how good the sample code is that people start copying and pasting. I suspect we could do much more for the security of the web by writing up good tutorials and example code for using CORS than we could by tweaking various parts of the specification at this point. I think it would be valuable to put together a secure version of a simple use case. First, for tutorial value, and second, to show that it's possible to write a simple system that uses CORS without immediately creating a CSRF attack, and that you don't have to do anything super tricky to make it work. We don't need a hackathon contest to learn something from the exercise, our own analysis should be sufficient. Here's two potentially interesting simple scenarios: 1) Pure public data. a) Sever A offers a public data API at some URL - the API is accessed with GET and looks at the query part of the URL. b) The data is not user-specific, just public knowledge like a list of search hits or the answer to a math problem. c) The server opts in to public access to this data via "Access- Control-Allow-Origin: *" (on the URL providing the data API only). d) Server B accesses data via this API. Hypothesis: this does not introduce a CSRF vulnerability on Server A. 2) Simple per-user data. a) Server C offers a per-user data API at some per-user URL - the API is accessed with GET and looks at the query part of the URL. b) The data is user-specific (e.g. list of contacts from an address book), determining what user c) Server C allows the user to grant access to this data to a specific other origin on a per-user basis. d) For users that have not opted in, cross-origin access to the data is refused (by not sending any special Access-Control headers). e) For users that have opted in, Server C responds to normal and preflight requests with Access-Control-Allow-Origin including the allowed other servers only, and Access-Control-Allow-Credentials. f) Inside the implementation of the URL, the server checks Origin to determine if the request should be allowed. g) For requests missing Origin, the server rejects the request (in a realistic deployment it might use a secret token mechanism to allow self requests in legacy browsers). h) For requests from an appropriate Origin but missing cookies, the server returns no data, just a token indicating that the user needs to log in to Server C. i) For requests from an appropriate Origin and including cookies, the server returns the per-user data. j) Server D attempts to get per-user data from Server C using XHR +CORS with the credential flag set. k) If server D gets the "need to log in" error back, it gives the user a link to Server C's login page. Hypothesis: this does not introduce a CSRF vulnerability on Server C. Perhaps we could build examples along these lines and host them on Google App Engine or the like. Maybe we could also make versions that don't opt into CORS at all, to check specifically whether the addition of CORS created new vulnerabilities. Regards, Maciej
CORS Best PRactices (was: [cors] unaddressed security concerns)
Hi, David-Sarah- David-Sarah Hopwood wrote (on 10/24/09 2:07 AM): Currently, the prevalence and impact of CSRF attacks is limited to some extent by the same-origin restrictions. The adoption of CORS will remove part of that limitation. This should be expected to result in more sites that rely on CORS being vulnerable to CSRF, even though the vulnerabilities are dependent on the detailed behaviour of those sites and are not a *direct* consequence of CORS per se. That is, these sites could in principle avoid such attacks, but only by avoiding the use of ambient authority, and we know from experience that some proportion of them won't do that. Okay, so, the complaint isn't that CORS itself is insecure, but that people won't know how to use it properly. This is a different problem, with a different solution. I certainly acknowledge your concern, and this is something we need to take seriously. If I understand you correctly, there doesn't seem to be anything about the CORS specification inherently that would cause it to change, nor to prevent it from progressing along the W3C Recommendation Track... rather, the challenge is to properly educate people on its use. We need to make sure that, as a consequence of CORS being enabled, site authors don't misapply the new power they have, to the extent that that is possible. Perhaps at this point we could work on some easy-to-understand tutorials, best practices, or even sample code show what to do and what not to do with CORS (and cross-site scripting in general), which W3C could host alongside CORS, to get the right messages out there. If the security community is willing to write up articles as well, W3C would be happy to link to or host that material. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: [cors] unaddressed security concerns
On Fri, Oct 23, 2009 at 11:07 PM, David-Sarah Hopwood wrote: > The specific risk is quite clear: it's the risk of CSRF attacks that > are currently prevented (or mitigated) by the same-origin policy. > These won't be prevented or mitigated to the same extent by browsers > that implement CORS. The reason the risk is unclear is because this scenario requires servers to opt-in to this behavior. It's hard for us to know what else server operators will do when they opt in to CORS. What is clear, however, is that in the simple cases, there is no additional CSRF risk because the set of requests an attacker can generate is not expanded by CORS. Adam
Re: [cors] unaddressed security concerns
On Fri, Oct 23, 2009 at 10:34 PM, Doug Schepers wrote: > Sorry for being dense, but why couldn't the whitehats build toy systems on > an open honeynet? They could, but what would we learn from such an experiment? If they build only secure systems, then we'd learn that security experts can build secure systems, which is somewhat unsurprising. If they build insecure systems, then we'd learn that it is possible to build insecure systems, which we know already. The real question hinges around what sorts of systems real developers will build given CORS as a tool and whether we can prod them into building more secure systems by changing the API. There isn't really a way for us to answer that question in our ivory tower because it revolves around who writes blog posts about what, and how good the sample code is that people start copying and pasting. I suspect we could do much more for the security of the web by writing up good tutorials and example code for using CORS than we could by tweaking various parts of the specification at this point. Adam
Re: Web Notifications, do we need a new spec?
On Oct 21, 2009, at 11:04 AM, ext Dominique Hazael-Massieux wrote: (adding the Device APIs Working Group mailing list in CC:) Hi John, Web Apps Le lundi 19 octobre 2009 à 14:12 -0700, John Gregg a écrit : Apologies for the delay, I've been spending the majority of my time completing the initial implementation for Chrome, but I've posted a draft version of a spec for notifications to http://sites.google.com/a/chromium.org/dev/developers/design- documents/desktop-notifications/api-specification I think that's a good starting point for formalizing it. I think this API would likely fit under the “User Interaction API” http://www.w3.org/2009/05/DeviceAPICharter#deliverables of the Device APIs and Policy Working Group — the group has’t had the time to look in details at the proposed work (but is hoping to do that in a week time), but in the event we would agree that the scope matches our charter, would there be any objection (from Google, from WebApps) in taking up that work in the Device APIs and Policy Working Group rather than WebApps? I added Web Notifications to the Agenda Items list for WebApps' API meeting at TPAC: [[ http://www.w3.org/2008/webapps/wiki/TPAC2009APIs#Agenda_Items * Web Notifications o Discuss during a Joint Session with DAP WG o Ownership: DAP or WebApps? - see email by Dom Hazael-Massieux [1] (21-Oct-2009) o Google Proposal [2] submitted by John Gregg [3] (19-Oct-2009) [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0285.html [2] http://sites.google.com/a/chromium.org/dev/developers/design- documents/desktop-notifications/api-specification [3] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0225.html ]] -Regards, Art Barstow
Re: [cors] unaddressed security concerns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David-Sarah Hopwood wrote: > Doug Schepers wrote: >> I'm not at all a security expert, or even particularly >> well-informed on the topic, but it does occur to me that most of >> CORS' opponents seem very much in the capability-based security >> camp [1], and may distrust or dislike something more >> "authentication-based" like CORS. > > The reason for that is that the main issue here is CSRF attacks, > which are a special case of a class of vulnerabilities (confused > deputy attacks) that capability systems are known to prevent, but > that other access control systems are generally vulnerable to. So > it is not surprising that proponents of capability systems would be > more likely to recognize the importance of this issue. If I had to briefly describe CORS it would be a specification for allowing cross site requests will minimizing the transfer of common forms of ambient authority. Isn't that exactly what capability theory would advise? > > Indeed the most common -- and arguably most effective -- defence > against CSRF is to use an unguessable token as an authenticator. > That token is a sparse capability, used in essentially the same way > that a capability system would use it. > With the current design that of defaulting to not sending headers that usually supply ambient authority (Cookie, Authorization that would otherwise be delivered automatically), it seems like we are indeed pushing developers to use more capability style techniques like unguessable tokens. I am totally in favor of capability systems, but the main criticism here seems to be around CORS overall design, and it seems to me that the overall design is a great fit for capability based approaches. - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrjAhIACgkQ9VpNnHc4zAxupgCdFZdZMUqh2iMu4tJHyFa9RpPQ U/AAnR97OGcqev31NS0q7iCsmgA9h3U+ =zeXJ -END PGP SIGNATURE-
Re: [cors] unaddressed security concerns
Hi, David-Sarah- David-Sarah Hopwood wrote (on 10/24/09 2:45 AM): Doug Schepers wrote: I'm not at all a security expert, or even particularly well-informed on the topic, but it does occur to me that most of CORS' opponents seem very much in the capability-based security camp [1], and may distrust or dislike something more "authentication-based" like CORS. The reason for that is that the main issue here is CSRF attacks, which are a special case of a class of vulnerabilities (confused deputy attacks) that capability systems are known to prevent, but that other access control systems are generally vulnerable to. So it is not surprising that proponents of capability systems would be more likely to recognize the importance of this issue. Fair enough. Indeed the most common -- and arguably most effective -- defence against CSRF is to use an unguessable token as an authenticator. That token is a sparse capability, used in essentially the same way that a capability system would use it. Is there an existing capability mechanism that would solve the use cases that CORS enables? If so, what is the rationale for CORS? If not, why not? Could CORS be combined with a capability system to make it more secure (and are you alluding to that, and I was too dense to connect the dots)? I'm not arguing for or against CORS here, just educating myself... sorry if I'm dragging down the dialog here. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
