- From: David Bruant <bruant.d@gmail.com>
- Date: Tue, 11 Feb 2014 22:57:55 +0100
- To: Mike West <mkwst@google.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <52FA9CE3.60402@gmail.com>
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
> <mailto: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 <http://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 Tuesday, 11 February 2014 21:58:27 UTC