1096854 - Allow inline script in priviledged apps for app html

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

[Axel Nennker]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141013200257

Steps to reproduce:

My app has an index.html with inline script:
<script type="text/javascript">
          var dummy = "inline script";
</script>



Actual results:

Now my app needs to be priviledged because it needs access to APIs that require it.

But inline script is banned for priviledged apps:
https://developer.mozilla.org/en-US/Apps/Build/installable_apps_for_Firefox_OS/CSP
even when the html that contains the inline script is part of my app.


Expected results:

If the html is part of my app then inline script should be executed.

Comment 1

[Axel Nennker]

Here is the logcat output:

W/WalletExperience( 1322): [JavaScript Error: "Content Security Policy: The page's settings blocked the loading of a resource at self ("script-src app://twe.gaiamobile.org")." {file: "app://twe.gaiamobile.org/index.html" line: 54 column: 0 source: "
W/WalletExperience( 1322): 		    var dummyItems = items;
W/WalletExperience( 1322): 
W/WalletExperience( 1322):         ..."}]

Comment 2

[Frederik Braun [:freddy]]

Hi Axel.

Let's discuss this in the thread you started on the dev-b2g mailing list. Feel free to also join our IRC chat on irc.mozilla.org - channels are #security, #gaia or #b2g. My nickname is "freddyb".


Thanks!

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Here's my comments from the thread. I agree that this is WONTFIX.

On Nov 13, 2014 6:56 AM, <[e-mail]> 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.