- From: Mike Wilson <mikewse@hotmail.com>
- Date: Fri, 28 Aug 2009 10:41:02 +0200
Adam Barth wrote: > Mike Wilson<mikewse at hotmail.com> wrote: > > I see what you mean. The ideal thing would be if we > > could implement path-based security with the same > > construct that adds path-based namespacing. > > > > I realize the problem of backwards-compat, but have > > there been any efforts or definitive conclusions made > > in this area? > > I suspect the scheme+host+port model is too entrenched > at this point to add +path to the origin tuple. Just to be clear, I wasn't suggesting that we'd redefine "origin" to contain path, but rather saying there are cases where we could benefit from namespacing on origin (=scheme/host/port) + path. The namespacing bit is probably not so hard, but making it secure also is non-trivial, due to the by-default unrestricted access between documents from the same origin that Anne mentions: Anne van Kesteren wrote: > Note also that someone on /evilpath/ can simply inject an > <iframe> loading /targetpath/ and extract cookies from > there via ECMAScript or initiate requests from there, etc. > Paths cannot be trusted to provide security. Yes, I guess this is what Ian had in mind in his initial response, and it means cookies are already "lost" for this cause. But maybe we can still save new HTML5 features from this exploit. My chain of thoughts is something like below (this is just a general picture so don't take it too literally): - invent a more restrictive mechanism for script access between documents from the same origin ("host") so it can be limited based on a base path - this mechanism needs a way to specify the blessed path, maybe something along the lines of document.domain or a response header - the default blessed path should probably be as permissive as today to not break existing content on the Web (though maybe some smart algorithm may be developed that adds some restrictions) - if new browsers implement this mechanism, it means it will be possible to secure all new HTML5 features implemented at the same time or later, as authors can depend on that, if a browser has feature X, then it also has path-based security - old browsers will still ignore the new path-based restrictions, but they will not have the new HTML5 features so these can not be exploited - cookies will still be exploitable in old browsers and for legacy content, but as old browsers are phased out application authors can more and more depend on cookies also being "safe" based on configured path security But maybe there has been previous efforts done on this topic? Best regards Mike
Received on Friday, 28 August 2009 01:41:02 UTC