W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: Entry Point Regulation vs Simpler Solutions (was Re: WebAppSec re-charter status)

From: Brian Smith <brian@briansmith.org>
Date: Wed, 25 Feb 2015 17:20:52 -0800
Message-ID: <CAFewVt4Czoynbus66Eiir11keLh+TbWej_6g6LUuC4HkUbVwDA@mail.gmail.com>
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

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.

Received on Thursday, 26 February 2015 01:21:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC