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

Someone pointed out to me recently that web search indexing / ranking could
conceivably key off of the existence of the EPR HTTP response header.
 (Imagine that setting the response header might have an affect similar to
robots.txt.)  The primary EPR target audience of administration control
panel apps, etc. would likely be OK with this, whereas it would remove the
incentive for the bad actors to misuse EPR to block deep links.

Thoughts on the extent to which this might ameliorate concerns about EPR
w.r.t. deep linking?

Dave

On Thu, Feb 26, 2015 at 3:01 AM, Eduardo' Vela" <Nava> <evn@google.com>
wrote:

> It doesn't make sense to derail the thread to be about CSP. I'll answer
> your question, but I suggest moving that conversation to another thread if
> you want to discuss about CSP deployment issues further.
>
> David and me work on "server-side stuff" on Google. We help product teams
> develop secure products, and teach them how to fix vulnerabilities
> correctly and across their whole product. We ask for large refactorings,
> and work with teams to use browser security features like CSP.
>
> In specific, in many cases we can't use CSP on legacy applications because
> it requires a sufficiently large refactoring that its easier to just
> reimplement the application than retrofitting CSP. Applications written in
> things like GWT, Angular and such are easier to convert, but they bring
> their own CSP problems/bypasses with them (template injection, requirement
> of eval, etc).
>
> Now, implementing CSP on products from scratch also has a lot of
> challenges because many libraries, widgets and services inherently needed
> in a sufficiently complex web app aren't compatible with CSP (they could
> be, but they just aren't today). We try to make them, but its not clear we
> will be able to make enough progress to keep up.
>
> My favorite example (out of many) is www.google.com/jsapi - its a
> JSONP-like endpoint, that makes it "very hard" for other sites to protect
> against XSS via script-src. Another fun thing about jsapi, is that it also
> loads scripts from locations that can change at any time without prior
> notice. Fixing this is hilariously complex and probably not something we
> can go into too much detail anyway.
>
> Other examples are, the impossibility of getting rid of eval, without
> incurring in prohibitive latency costs. For instance the need for people to
> use compact JSON, rather than full JSON. That is, JSON that allows for
> {a:[,,,,{x:!1}]} instead of {"a": [null, null, null, null, {"x": false}]}.
> Since JSON doesn't support serializing undefined, the first and the second
> are technically different (and there is a dubious claim about response size
> being better in the first, although compression should compensate for
> that). In addition, changing behavior here breaks tests and integrations
> out of the control of any given company.
>
> Then eval is also needed for stuff like loading JS via
> XHR/FileSystem/IndexedDB/SharedWorkers/LocalStorage and evaling it. This is
> popular on mobile web apps where devs would do anything to not use the
> network. It also happens often for cases when settings or modules are
> installed locally and the server doesn't keep track of them.
>
> Another example was that applications that cache or asynchronously load
> components aren't always in control from the page serving the HTML. Say,
> your Calendar page uses a component (via html imports or a JS file) from
> your Social Network. Changes on the hostname used to fetch (XHR), frame or
> serve resources (images, styles, scripts) used to not make a difference. It
> does now. Now in order for CSP to be deployable mashups will need to behave
> differently.
>
> There are many other examples, not really worth derailing this thread to
> be about CSP. But we haven't given up on CSP, but its not as easy to deploy
> for sufficiently complex applications developed in large modular little
> pieces that depend on each other (nonces and hashes helped a lot, but there
> are other problems that need to be worked on, as explained above). There is
> an argument to be made that CSP wasn't designed for those types of apps,
> but we anyway want to try (say, "it's the best thing we have").
>
> At the same time, we see we can protect a bunch of services via EPR
> "overnight", and while it won't fix everything, it is simple enough and
> robust enough (security-wise) that we want to protect our users with it. At
> least for highly sensitive applications where an XSS or CSRF would be
> catastrophic for persons or companies.
>
> We also notice that a feature like this would be a lot easier to deploy
> and help us protect users than CSP or first-party cookies. Simply because
> "it just works" on older applications. If we need to, we can just flip a
> flag and fix a whole app, rather than having to redesign our authentication
> framework.
>
> The concerns raised about breaking linking on the web don't seem to take
> into consideration that EPR doesn't bring anything new to the picture in
> that aspect. Sites that wanted to do this before could have already done
> it. Believe me that from all companies in the world, the single most
> concerned on breaking linking on the web would be the search engine company.
>
> What EPR brings, that is new (for good or bad), is the possibility for an
> origin to forbid non-browsable requests (like CSS, JS, XHR, etc) to be made
> from different origins. The other thing it brings, is the possibility to do
> so *without* backwards compatibility problems or changes in application
> code/logic (which the other CSRF solutions lack).
>
> All of that in an easy to deploy format, that even old IIS admin panels
> from the 90s can adopt overnight securely.
>