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

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.