[whatwg] origin+path namespacing and security

[Mike Wilson]

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