W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2014

Re: CSP Transition Tools

From: Yoav Weiss <yoav@yoav.ws>
Date: Fri, 17 Jan 2014 17:31:04 +0100
Message-ID: <CACj=BEjD=4cVmcFW0i2FKOLhRjJNRi80EOLTaNDwyKzfjcmHKw@mail.gmail.com>
To: qll <qll@iceqll.eu>
Cc: Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Fri, Jan 17, 2014 at 12:51 PM, qll <qll@iceqll.eu> wrote:

>  On 17.01.2014 08:58, Yoav Weiss wrote:
>  On Wed, Jan 15, 2014 at 10:25 AM, Frederik Braun <fbraun@mozilla.com>wrote:
>> There was a very good bachelor's thesis at the Ruhr University of
>> Bochum, in which the author also wrote a reverse proxy that collects
>> inline items and generates external files for them (using a learning & a
>> production mode).
>> The tool is available at https://github.com/qll/autoCSP, and I can
>> surely find the thesis PDF if this is interesting enough and I start
>> some additional digging ;)
> I was thinking about something (very) similar that would integrate into
> current development frameworks (e.g. a Django/RoR app), and would add CSP
> auto-magically. Rather than externalizing inlined scripts (which can cause
> issues, at least in theory), such a plugin could use hashes/nonces to
> enable all the scripts that are present in the initial templates.
> Hey Yoav,
> You might find the conclusion of my thesis useful. The thesis itself is
> linked on the github page now (sorry for the self-promotion). Your
> possibilities definitely grow, the more "specific" you get (e.g. build
> something for one framework or CMS only).

I think that getting "specific" might be necessary. Once you can
differentiate between "static" <script>/<style> tags (in the templates) and
"dynamic" ones, you can avoid adding a CSP hash on inline code that was
added from the database. A generic proxy of a badly sanitized site may add
hashes/nonces to injected code, at least in some scenarios.

> However, keep in mind that there still are scenarios which will be very
> hard to fix with a hash or nonce.

I agree, but my anecdotal experience from living among authors tells me
that 80-90% of the problem is <script>/<style> tags that are specific to
the page.

Markup-mixed event handlers are probably a secondary source of problems,
and are trickier to resolve in a generic way (although it's possible). I'd
probably leave them for a later phase. Did you resolve event handlers in
your proxy?

What is with eval-like statements?

I would ignore eval statements and let the author deal with it.

> What if the initial templates output dynamic data into scripts (as can
> often be seen with CSRF tokens and similar).

That's easy to solve once the solution is integrated into the framework and
has knowledge of the templating system.

> There are solutions to the latter problem but rewriting (or allowing
> "safe"? How would we know automatically?) eval-like statements will most
> likely persist to be a hard problem.

I agree.

> Also: You should be careful with nonces since an injection in front of an
> allowed element may steal the nonce with a dangling markup attack easily
> (verified with Chrome).


> If you want to build something like you've proposed, hashes seem to be the
> way to go IMO.

The difference between "want to build" and "have actual time to build and
maintain" is pretty big for me ATM. :)

> Regards,
> Nicolas Golubovic
Received on Friday, 17 January 2014 16:31:33 UTC

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