- From: Brian Smith <brian@briansmith.org>
- Date: Wed, 25 Feb 2015 17:20:52 -0800
- To: David Ross <drx@google.com>
- Cc: "Eduardo' Vela <Nava>" <evn@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Deian Stefan <deian@cs.stanford.edu>, Martin Thomson <martin.thomson@gmail.com>, Brad Hill <hillbrad@gmail.com>, Jeffrey Yasskin <jyasskin@google.com>, Mike West <mkwst@google.com>, Wendy Seltzer <wseltzer@w3.org>, Dan Veditz <dveditz@mozilla.com>, Mounir Lamouri <mlamouri@google.com>, David Baron <dbaron@dbaron.org>, Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>
David Ross <drx@google.com> wrote: > CSP might be the answer to > this problem one day, but for now it's hard to get bulletproof CSP policies > deployed for practical reasons. EPR provides a complementary approach that > is useful and justified in some (not all) applications. Could people from Google, particularly the people working on server-side stuff, write something to help the subscribers of this mailing list understand the problems deploying CSP that Google is running into? I had thought that nonce-source and hash-source were the "good enough" thing, which is why they were put into CSP 1.1 (now CSP 2) right away. I think understanding and resolving these kinds of issues should be a high priority for this group, assuming CSP is going to continue to be a thing. > For every example we might find that looks like: > > https://news-site.foo/an-article-we-all-should-be-able-to-deep-link.html A better example would be http://www.tomshardware.com/print/samsung-galaxy-s5-smartphone,reviews-3908.html Note that this is the single-page printer-friendly version of an otherwise 15-web-page paginated article. > ...I can give a counter-example... > > https://admin-control-panel.ImportantCorp.foo/apis/internal.api > > ...that is intended as internal to the site and should not be exposed to > outside callers. This endpoint is only exposed to external callers today as > an artifact of the existing web development model. A huge factor of the success of the existing web development model is being able to navigate and "view source" on stuff that websites didn't intend to be seen. > I want to make EPR more compatible with the priority of constituents HTML > principle as long as we don't subvert the basic purpose of EPR, which is to > protect users from XSS / XSRF. Although I know you're well-intentioned, even that statement isn't in line with the priority of constituents design principle. EPR is very much like DRM for web pages: The website is asking the browser to add an artificial restriction on the user to prevent them from navigating to a resource based on the website's preferences. No doubt you only want it to be used for good, but that doesn't mean it will only be used for good things. Ultimately the solution to XSS and XSRF is better development tools and better development practices. CSP, EPR, X-XSS-Protection, etc. are all things that wallpaper over the fundamental problem that websites prone to XSS and XSRF are broken. In the long run, it seems like we're mostly encouraging bad development practices with unsafe development tools to continue. Cheers, Brian
Received on Thursday, 26 February 2015 01:21:19 UTC