Thanks for the explanation. I would like to come back to my original problem where inline script is only one portion of: We have developed a Cordova app that runs on Android and ios. We specify all the permission the app needs by specifying them in e.g. AndroidManifest.xml and I think this is OK for the user because the user can see the permissions requested and decline to install the app if they think the permissions are excessive. The FirefoxOS app generated by Cordova has a manifest.webapp with permissions and no csp and the type is privileged. In my understanding there is no way that the developer of the app can relax the csp of the privileged app.
I guess "Mozilla" thinks that this protects the user but it restricts me as a developer to implement what I need in my app. I am all in favor to protect the user and prevent developers to shoot themselves in the foot but I wish I could specify the CSP myself. Our app needs to call a privileged API so changing the type is not possible. The documentation is here: https://developer.mozilla.org/en-US/Apps/Build/Manifest#csp " These defaults can't be overridden, only added to, i.e. the CSP policy in the manifest can only make the actual CSP applied more restrictive in the case of privileged/internal apps." In regard to the two arguments below: 1) "too much effort and too complicated to get it right" a) If one searches Bugzilla for "inline script" https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%22inline%20script%22 there are matches like this https://bugzilla.mozilla.org/show_bug.cgi?id=960566 Move inline scripts and styles into separate files for SeaMonkey privileged about: pages Maybe it would have been in total less work for Mozilla to implement the "tagging" once and allow e.g. Thunderbirds about:pages and many other privileged apps to use inline script. b) I think it is even more complicated because I would like to allow "trusted" script to use document.write. 2) "leverage web standards" a) I agree with the first part of that paragraph but not with the part "And it makes it easier for people to borrow code between packaged apps and other contexts that use CSP ". That reuse is not currently possible is exactly my problem. My App runs on Android and ios but not on FirefoxOS. I think reusing the well documented and standardized CSP implementation is excellent engineering but restricting the developer to relax the CSP is not. Would you mind to add your explanations to https://bugzilla.mozilla.org/show_bug.cgi?id=1096854 ? Although I do not agree with your explanation I think I have to live with the facts. Maybe I should file a bug to remove this CSP restriction " These defaults can't be overridden, only added to, i.e. the CSP policy in the manifest can only make the actual CSP applied more restrictive in the case of privileged/internal apps." Although I fear it gets "WONTFIX"-ed on me like 1096854. Kind regards Axel -----Original Message----- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, November 13, 2014 10:32 PM To: Nennker, Axel Cc: dev-b2g@lists.mozilla.org; Frederik Braun Subject: Re: [b2g] Allow inline script in priviledged apps for app html On Nov 13, 2014 6:56 AM, <axel.nenn...@telekom.de> wrote: > > An _unmodified_ index.html is trusted. > Why not allow inline script in this case? > > <script src="definesA.js"/> > <script> > var B = A; > </script> > <script src="usesB.js"/> > <script> > var c = 2; > </script> > <script src="usesc.js"/> You are completely right that this would be safe. There are two reasons that we don't allow it. First of all we currently can't tell for certain that an inline <script> comes directly from the zip package. For example document.write is designed such that the written string is inserted directly into the stream of data that we read from disk. So we would have start tagging parts of that stream with"read from disk" vs "generated from document.write". And be certain that we get that 100% accurate since otherwise we have an XSS vector on our hands. We would also need to ensurew that The second reason is that the current implementation leverage existing CSP web standards. This means that we can reuse the existing well tested and well maintained CSP implementation that Gecko already has. It also means that we have a well documented solution since CSP has both a formal spec and well written documentation. And it makes it easier for people to borrow code between packaged apps and other contexts that use CSP. Of course, many of these advantages may not apply to you. I'm sorry about that. But it does apply to many others. / Jonas > > B2G could treat the above index.html as if it were like this: > <script src="definesA.js"/> > <script src="snippet1.js"/> <!-- <script>var B = A;</script> --> > <script src="usesB.js"/> <script src="snippet2.js"/> <!-- <script> > var c = 2; </script> <script src="usesc.js"/> > > I don't see how harm can be done in this case and think that closing > https://bugzilla.mozilla.org/show_bug.cgi?id=1096854 should be reconsidered. > > -----Original Message----- > From: Frederik Braun [mailto:fbr...@mozilla.com] > Sent: Wednesday, November 12, 2014 2:59 PM > To: Nennker, Axel; dev-b2g@lists.mozilla.org > Subject: Re: [b2g] Allow inline script in priviledged apps for app > html > > > I fail to see the difference between code that is inlined in a html file > > that is part of the app and code that is loaded from a js file. > > > > Would it work if I move all inline script snippets into files? > > Instead of "<p><script>alert("XSS");</script></p>" I would write > > "<p><script src='alert.js"/></p>" > > With alert.js containing "alert('XSS');" > > > > If this works than how does it improve security? > > > > An attacker can never create a file within your packaged app. > But an attacker *may* be able to create a script tag within a vulnerable > application by injecting script tags into calls to innerHTML. > > > My feedback with the Cordova people is btw. pending, you can follow the > conversation online[1] - It also contains some interesting suggestions on how > to automatically externalize all your inline scripts[2]. > > > > [0] > http://callback.markmail.org/search/?q=#query:%20list%3Aorg.apache.inc > ubator.callback-dev+page:1+mid:xmy6it4tkokcfktc+state:results > [1] > http://callback.markmail.org/search/?q=#query:%20list%3Aorg.apache.inc > ubator.callback-dev+page:1+mid:xagvpmc2m3nw2m6w+state:results > _______________________________________________ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
