Re: CSP Transition Tools

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

Interesting.


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