- From: David Ross <drx@google.com>
- Date: Wed, 6 Aug 2014 13:59:19 -0700
- To: Frederik Braun <fbraun@mozilla.com>
- Cc: public-webappsec@w3.org, Julien Vehent <jvehent@mozilla.com>, Tarek Ziade <tziade@mozilla.com>
- Message-ID: <CAMM+ux4xvc6uKe=sQ5Y+c4PJSJQ=VbuJdDy1Dg=QT6_9C63nCQ@mail.gmail.com>
> Should this become part of the manifest format under development? The only reason it might be inappropriate is if these manifests are downloaded lazily. EPR manifests must be available early in order to effectively block XSS. > Also, how does this relate to suborigins? A suborigin seems like it > might be a more robust way of creating a silo on an origin as it does > not rely on external metadata. I guess you don't get the granularity > there... I was thinking that for EPR on a large site (say google.com), multiple EPR manifests could be supported and identified in the manifests and headers, eg: X-EPR: 1; path=/foobar I think the approach you're pointing out would involve linking EPR manifests to individual suborigins. Off the top of my head that sounds reasonable. What's the issue relating to granularity? Thanks for the info on Videur Freddy. I do think it would be good to merge the manifest formats. Mads Kristensen has just developed a JSON Schema for the EPR manifest, so maybe the next thing to do is to expand that to cover what Videur would need? We've been discussing the JSON Schema over on the EPR list: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/epr-list/sAP61YT2dZw/VHCa4AodCjQJ Dave On Wed, Aug 6, 2014 at 2:46 AM, Frederik Braun <fbraun@mozilla.com> wrote: > Hey Dave, > > This looks really valuable. > My colleagues Julien and Tarek (CCd) have experimented with the same > idea, but enforced on the server: They also use a manifest file that > looks like yours. It's called Videur and is already available on Github: > <https://github.com/mozilla/videur>. > > As far as I undersand your project focus is aiming to protect the users > from being affectd by XSS/XSRF while Videur aims to protect the server > and the webapp by defining entry points, regardless of the client. Of > course the latter approach has less request context (frames, origins, > referers...), but the upside is that a strong policy might also protect > against other typical web attacks. > > Still I think it would be worthwhile to bring the file format in > accordance with both projects. What do you tzink? > > Cheers, > Freddy > > > On 05.08.2014 20:48, David Ross wrote: > > I've been working on a project to address XSRF and reflected XSS by > > enabling web apps to regulate their entry points. > > > > Blog with more details: > > > http://randomdross.blogspot.com/2014/08/entry-point-regulation-for-web-apps.html > > > > Code for a Chrome extension implementing EPR: > > https://github.com/google/epr > > > > Mike West and I have been talking about spec'ing this out with hooks for > > CSP and Fetch. It would be great to get any comments and feedback from > > the webappsec list! > > > > Dave > > > > > > >
Received on Wednesday, 6 August 2014 20:59:48 UTC