Re: Processing of meta element

We might be talking past each other a bit. Let's leave GWT entirely to the
side for the moment, and I'll make my case based on the example at the end
of my last email, as I think it's interesting. We can come back to GWT in
the future if no one's convinced by this use case:

Let's say I deliver `example.com` with an HTTP header setting a policy of
`script-src 'self' sketchycdn.com`. I load script from `example.com` and `
sketchycdn.com` to boot up my app. After doing so, I don't actually need to
be able to load any more script from `sketchycdn.com` anymore (they're
cheap and fast, but kinda sketchy, you see...). It would be useful to
_tighten_ the page's effective policy at runtime, and ideally via an
imperative JavaScript API (strawman:
`document.securityPolicy.scriptSrc.remove("sketchycdn.com")`).

Would you agree that removing possible sources of script at runtime might
be valuable?

In the absence of such an API (I'd like to come back to a DOM API in CSP
1.2), injecting a <meta> element that composes with the HTTP header in such
a way as to allow only origins in the intersection of the two policies (as
outlined in [1]) seems like a pretty reasonable way of offering this
ability.

If you'd agree that the above use case is reasonable, then I think it
follows naturally that it would be equally helpful to be able to tighten a
nonexistent policy (the GWT case). *shrug* Makes sense to me, anyway. :)

[1]:
http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#enforcing-multiple-policies.x

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Tue, Feb 11, 2014 at 10:57 PM, David Bruant <bruant.d@gmail.com> wrote:

>  Le 10/02/2014 12:12, Mike West a écrit :
>
>  On Fri, Feb 7, 2014 at 4:50 PM, David Bruant <bruant.d@gmail.com> wrote:
>
>>  Le 07/02/2014 15:31, Mike West a écrit :
>>
>>  Hi David, sorry for the delayed response. It's been a rough week...
>>
>>  No problem. No rush until it's shipped anyway ;-)
>>
>
>  I want to ship yesterday. :)
>
>  Before diving back into the line-by-line, let's step back for a moment.
> My understanding of your claim is that allowing injection of policy at
> runtime is dangerous because:
>
>  a) Authors might imagine they have more protection than they do.
> b) Clever attackers might use policy injection to attack a site/user.
>
>  Is that an accurate summary?
>
> b) was a bit of bad faith on my part.
> There is also that adding this will create unnecessary confusions to
> non-experts.
>
>
>   If so, my general response is:
>
>  a) I agree 100% that injecting a policy after "boot" is strictly less
> effective than delivery in <head>, or as an HTTP header. I hope you'd agree
> that it is also strictly more effective than having no policy whatsoever.
> I'd much rather see authors who can't (yet)
>
> this "yet" is key to my disagreement. When they'll be able, this
> transition method will become fully useless and only create confusion. To
> our grand-kids we'll say "I remember, in 2013, it helped one framework for
> a year until they did a refactor to emit the HTTP header".
>
>
>   directly support HTTP-based delivery have JS-based delivery as a
> stepping-stone to a more complete implementation, than to see those same
> authors reject CSP completely because it doesn't work with their framework
> out of the box.
>
> How many such frameworks are there? What proportion of websites is based
> on them?
>
>
>   With that in mind, I'd place the risk of JS-based injection quite close
> to zero, and the benefit somewhere quite a bit above zero.
>
> "quite a bit above zero"... for a temporary period. How long isn't clear
> to me. I guess it depends on GWT willingness to emit an HTTP header instead
> of JS code doing the work.
> The benefit is also only to security-aware people. It's not clear how
> other people will react. I claim it will only create confusion
>
>
>          This is use-case #2 above. It's something I explicitly intended
>>> to support (dumb or not :) ), based on feedback from GWT developers here at
>>> Google.
>>>
>>>  IIUC GWT serves as server-side code and generates the client side. How
>>> come it can generate the client code to create a meta element in JS, but
>>> not the server-side part outputting a <meta> in HTML? This doesn't make
>>> sense to me. Improving GWT seems like the proper course of action.
>>>
>>
>>  The use case is something like this: the application spins itself up,
>> loading a variety of JavaScript from a variety of sources.
>>
>>  These sources are known ahead of time. Why can't it emit a <meta> or
>> send the HTTP header before loading the JS? I can't see a good reason. Only
>> ephemeral reasons like "it's hard to retrofit in GWT given the current
>> design and assumptions". And I'm not sure current (!) GWT limitations
>> should influence the design of CSP.
>> Moving forward, new frameworks will (hopefully) make room to customize
>> the CSP header and the header will be the only needed thing.
>>
>
>  Frameworks that make use of 'eval()' and 'new Function' will have a hard
> time doing this without whitelisting 'unsafe-eval'.
>
> They can whitelist it until they're able to remove it. From a security
> standpoint, this isn't worse than "no protection to begin with and inject a
> policy in JS afterward", is it?
>
>
>       Some (much!) of this JavaScript is loaded outside the document's
>> <head> for performance reasons. Writing a <meta> element directly,
>> therefore, isn't an option. The element must be injected into the
>> document's <head> once the "dangerous" JavaScript has executed.
>>
>>  I'm surprised by the last sentence. Inject potentially harmful JS and
>> protect afterwards? Isn't this providing a false sense of security? Is it
>> really doing a favor to GWT? ("I use CSP, I'm immune against XSS! ...
>> woops, no I'm not")
>>
>
>  1. We very explicitly position CSP as defense-in-depth. Using CSP does
> not mean that you're immune to XSS. It is a powerful mitigation, but only
> one of several you should be considering when structuring your application.
>
>  2. Obviously, we'd love for every developer to deliver a strong CSP
> policy via an HTTP header. That would be ideal. There's a large distance,
> however, between the ideal, and nothing. Missing the ideal shouldn't mean
> that we offer nothing. We can and should support use cases that bring
> developers up above zero protection.
>
> I agree and the (inline) <meta> is here to play this role.
>
>
>
>
>>  Again, maybe the way GWT starts the application is the thing to
>> question. The design you describe to load the application is insecure. It's
>> insecure in a way CSP is supposed to protect against. This really feels
>> like a step backward.
>>
>
>  If I could redesign GWT by fiat (and knew enough about the framework to
> do so), I would. I cannot.
>
> I wasn't asking you to personally of course :-)
> But I find strange for GWT to say "we care about CSP, but not enough to do
> the work to emit an HTTP header or emit an inline <meta>"
>
>
>
>
>>  <meta> already comes with the reserve that it should be placed as early
>> as possible. I feel adding a JS way of doing things blurs the lines and the
>> use cases outside GWT are still unclear.
>>
>
>  Pulling back again, what do you think about this use case (that the spec
> doesn't currently support)?
>
>  * I, as an author, want to lock down my page to the greatest extent
> possible. Once I've loaded all the script I care about, I'd like to ensure
> that no other script can run at all, even if it comes from an origin I
> trust. I deliver my page with "script-src 'self' *.googleapis.com", and
> the last script I load ends with an injection of "script-src 'none'".
>
>  Does that use case make sense? I think it does, though it's
> significantly more paranoid than I'd expect most authors to be. Authors
> with reason to be paranoid (banks?) might see it as worthwhile.
>
> Authors with reason to be paranoid already send the CSP 1.0 HTTP header.
> Or at least, they're working hard to get to that point (probably including
> ditching a framework that prevent them from doing so).
>
> What you're targetting is authors with reason to be paranoid, but who
> don't have control over their HTTP headers or enough control to add an
> inline <meta>. I'm skeptical of whether this population exists at all and
> even if, how big it is.
>
>
> At this point it looks like I can't be convinced with the current
> elements. So far, it's only been brought to the list that it's a problem
> for GWT.
> Is it a problem (require more than 6 months of work to either send the
> HTTP header or emit the <meta> inline) for one of the followings :
> Wordpress? Joomla? Drupal? RubyOnRails? J2EE? Django? Magento? Prestashop?
> (sorry, mixing everything indifferently)
> I'll be convinced if one of these (or other popular systems to make
> website/webapp) present difficulty with deploying CSP. I believe it'd be
> wise to hold off JS-based CSP until one of these (besides GWT) expresses
> they need it.
> Obviously, I'm just sending emails. If no one else cares and you think
> it's important, move on.
>
> David
>

Received on Wednesday, 12 February 2014 10:38:35 UTC