292789 - SCRIPT tags can access chrome

Status: RESOLVED FIXED

(Core :: General, defect, P2)

Description

[Michael Krax]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

IMG and SCRIPT tags (and INPUT type=image) can access chrome and use this
ability to check if an extension is installed.

The following piece of code alerts whether or not Adblock is installed. 

<script>var uninstallAdblock = false;</script>
<script src="chrome://adblock/content/uninstall.js"></script>
<script>alert("Adblock is "+(uninstallAdblock?"":"not ")+"installed")</script>

Is there any valid use why unprivileged content should be able to get read
access to the content of chrome files?

The only thing i can imagine is something like 
<img src="chrome://browser/content/about.png">

Reproducible: Always

Comment 1

[Hixie (not reading bugmail)]

This would be because we don't do cross-domain checks on <img> and <script>,
presumably. (I'm guessing the script is running in the context of the page, not
with privs.)

Didn't we already block http:// content from using <img> or <script> on file://
URIs? We should probably block chrome:// and resource: (if we still have that)
as well, if so. We can't just block different schemes, that would block data:,
javascript:, https:, about:, etc, which should keep on working.

Comment 2

[Daniel Veditz [:dveditz]]

IMG was explicitly allowed to load chrome with bug 69070 (which blocked file:
access). Not convinced that was a great idea.

Adblock, of course, can be detected easily in other ways: "var hasAdblock =
window._AdblockFiltered ? true : false", but not every extension sticks things
in the DOM like that.

in general there's not much reason to allow <script src> such wide scope. I'm
sure someone can come up with something cool they can do with it (distribute a
library of useful web-app helper code via extension?), but any legitimate use
could be accomplished in other ways.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> IMG was explicitly allowed to load chrome

That's needed for proper functioning of various XBL-like things in remote XUL,
proper functioning of icons in ftp listings, etc, etc.  That is, lots of our own
"UI" somehow depends on loading chrome images and has the permissions of a web page.

Note sure what the deal with script was, except insofar as remote XUL may want
to use things like contentAreaUtils.js?

Comment 4

[Darin Fisher]

It seems pretty dangerous to allow SCRIPT tags to load chrome:// URLs.  There
are probably interesting ways in which chrome priviledges scripts may be
exploited.  Perhaps by changing a property on the global window?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Scripts are compiled with the permissions of the document that loaded them, no
matter what URI they were loaded from, I believe.  The only thing we should be
basing on the script URI is the decision as to whether to create
XPCNativeWrappers....

Comment 6

[Darin Fisher]

From comment #0 it looks to me as though uninstall.js is able to interact with
JS from the containing document.  That seems like a recipe for trouble.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Yes, in comment 0 the uninstall.js script is being compiled against the content
script global and ending up setting properties on the content global object...

As I said in comment 3, I see no obvious "it'll break the world" situation with
<script> if we disallow linking to chrome script from non-chrome pages.

Comment 8

[Benjamin Smedberg]

This is WONTFIX: we do want to allow untrusted content to link to various pieces
of installed JS, as long as there is no privilege elevation.

Comment 9

[Michael Krax]

Well, i disagree. In the spirit of the "proactive security" MoFo claims this
should be fixed and not left alone because it is "too painfull and probably not
worth it" - i guess this is what most developers think about it *g*

Another argument against this behavior is that website developers could rely on
this kind of code. They could include chrome javascript files or images into
their pages and use it reduce traffic. And when Firefox changes internally,
their pages will break and they will blame MoFo.

If this is a WONTFIX please remove the security flag, make it a documented
feature and tell people if they can/can't rely on this in the future.

Comment 10

[Daniel Veditz [:dveditz]]

Unflagging security sensitive as requested, and because we were convinced it was
safe enough to close as WONTFIX.

Reopening though, as this just seems like a bad idea. It's bad enough when
extensions rely on unfrozen chrome scripts, we don't want web sites doing the same.

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 308808 has been marked as a duplicate of this bug. ***

Comment 12

[Jens Bannmann]

Attachment: testcase

Quoting myself from bug 308808:

> This is probably not a security bug in itself, but I'd classify it as an
> unwanted information leak that makes targeting exploits easier. When a
security
> hole is discovered in an extension, it is easy for the attacker to only
activate
> the exploit on systems where the extension is installed.
> Other potential uses are keeping out "unwanted" AdBlock or GreaseMonkey users

> from web sites - sure, they can disable JavaScript for web pages, but to
enjoy
> the web most users won't do that, and "crossing" the web<>chrome barrier in
this
> way shouldn't be possible from the start.

Attaching demo page detecting the presence of GreaseMonkey, IE View,
FlashGot and Mouse Gestures.

Comment 13

[Daniel Veditz [:dveditz]]

Easy to fix here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsScriptLoader.cpp&mark=517-518#510

Allowing access to chrome scripts has been in since r1.1 of this file. It's hard
to believe any legitimate pages are using this, but we need to watch out for
breaking sites this close to release.

Stopping this won't prevent pages from detecting (some) extensions in other ways.

Comment 14

[Benjamin Smedberg]

The problem is that we really must allow sourcing of chrome JS scripts from XBL
(for remote XUL), which will expose the same "problem" that as using a <script>
element directly.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Hmm... Why does remote XUL XBL need to source chrome via <script> tags?

Comment 16

[Hixie (not reading bugmail)]

Doesn't matter how it sources it. The point is if it is possible to source it
using one technique, then the privacy/security/whatever risk is present anyway.
If the reason to block <script src=""> is a privacy/security/whatever risk, then
we must block all such possibilities. If there is something that outweighs that,
then we should just allow access everywhere. Inconsistent "allowed if you use
this syntax but not if you use that syntax"-type access rights seem bad.

Comment 17

[Jens Bannmann]

(In reply to comment #14)
> The problem is that we really must allow sourcing of chrome JS scripts from XBL
> (for remote XUL), which will expose the same "problem" that as using a <script>
> element directly.

Benjamin, could you (or someone else who isn't on vacation) elaborate for
exactly which purpose remote XUL needs to source a chrome JS script? And is the
XBL that needs to source the chrome script part of our own code, or is it (can
it be) third-party, i.e. served remotely, too?

My thinking is that there are those scripts that "want" to be available to
untrusted content (some XBL-related JS files), and those that are not (all other
chrome JS + extensions). Perhaps we can find a way to distinguish those
(whitelists, or even a special 'publicchrome://' protocol if backwards
compatibility is not an issue)...

(In reply to comment #16)
> Inconsistent "allowed if you use this syntax but not if you use that
> syntax"-type access rights seem bad.

Full ack.

Comment 18

[Boris Zbarsky [:bzbarsky]]

> Doesn't matter how it sources it.

Was anyone suggesting that this does matter?

Comment 19

[Michael Krax]

(In reply to comment #17)
> Perhaps we can find a way to distinguish those
> (whitelists, or even a special 'publicchrome://' protocol 

Please not another pseudo protocol - especially not chrome related. That smells 
like another door for privilege escalation: getting from a normal website to 
publicchrome and than over to "real" chrome including chrome privileges. 

In the last months we finally fixed most of the unchecked places for chrome 
access (menus, dialogs, favicons, etc). Please don't allow yet another way to 
access something that could potentially allow a way into chrome.

Creating a remote app that is not a part of the browser (unlike an auto-update) 
should simply never be allowed to use or rely on something of the local 
installation. Sure, it's nice to save bandwith and have remote XUL apps use 
local scripts for common stuff - but "remote xul apps" should be just a "stand-
alone" thing. Interacting with local files is something for extensions. What if 
ever another vendor (e.g. Opera) adds support for XUL? By allowing remote XUL 
apps to interact with Firefox local chrome files we would allow to limit those 
XUL apps to Firefox and making it an even more proprietary thing. Or we would 
enforce other vendors to ship Firefox chrome files and add the publicchrome 
protocol (if we implement it).

Comment 20

[Boris Zbarsky [:bzbarsky]]

We allow remote XUL apps to interact with the local theme.

The problem is one of defining what is part of "XUL" and what is part of "chrome
that we just happen to have".  Why is a part of XUL implemented in C++ somehow
more acceptable for use in remote XUL than one implemented in JavaScript (via
XBL or pure JS components or whatever).

The real problem Michael put his finger on is that we use chrome://
indiscriminately to refer to both parts of the XUL platform and parts of our
browser UI (including extensions, etc, etc).  Which makes it very hard to make
one work without giving access to the other.  :(

Comment 21

[Jesse Ruderman]

Bug 59701 might be related.

Comment 22

[Michael Krax]

(In reply to comment #20)
> Why is a part of XUL implemented in C++ somehow
> more acceptable for use in remote XUL than one implemented in JavaScript (via
> XBL or pure JS components or whatever).

Personally i would draw the line at the API. If there is a defined and frozen 
API to call via javascript or a tag based langugae like XUL everything is fine 
to me. XUL authors can than use those objects and manipulate them with 
everything javascript offers.

Put as soon as you include the _source_ of such an object via chrome protocol 
and a script tag you are breaking a barrier (you can't include the C++ code to 
answer your question). What if a programmer relies on a function in the source 
that was not frozen? Or relies on a special return value of a private function? 
Or just uses something - maybe even by getting the string value of a function, 
change it and eval it - and bypasses a security check or string validation that 
way?

Extension authors should be allowed to do all those things - they extend the 
browser and maybe want to intentionally break/modifiy a build in function. XUL 
app authors should just be able to use existing functions and never need to 
bother with the source code behind - and don't even have the option since not 
all programmers know what they are doing *g*

Maybe i am wrong. Or i don't understand the full purpose of remote XUL. But 
that is the way i would implement it ;)

Comment 23

[Boris Zbarsky [:bzbarsky]]

The problem is that with JS you can't very well draw the line between the api
and the source -- you have to have acess to the source to be able to call the
functions in it, generally speaking....  A good case in point is the perennial
problem of chrome XBL bindings.  To use a <xul:browser> remote XUL must be able
to load the corresponding XBL, which lives at a chrome URI.

Comment 24

[Mike Schroepfer]

Hey folks - looking like we are not going to get a fix in time for the 1.8b5
release so taking it off the list.  If we close on a solution we can take post
1.5 timeframe.  

Comment 25

[Jeff Walden [:Waldo]]

It seems to me that this problem could be partially ameliorated by preventing
script tags from loading chrome scripts outside of <chrome://global/>; this
would at least eliminate attacks through host app or extension scripts.  Note
that at a minimum this assumes that host apps shouldn't provide XBL bindings
intended to be used remotely, which may not be a valid assumption.

Comment 26

[[e-mail]]

SCRIPT tags aren't the only way to detect extensions, of course.

Comment 27

[Mittineague]

After seeing a reference to this bug in a site that demonstrated a way for pages to determine what Firefox Extensions were installed, I put together a GM userscript to provide some control. It can be found at http://www.mittineague.com/dev/chromesentry.user.js and http://userscripts.org/scripts/show/5899
Comments regarding the possibility of testing for a "window" tag, or another way of identifying legitimate use would be greatly appreciated.
I also would like feedback regarding possible security issues involved with the placing of filtered script content within the replacement script tag.

Comment 28

[sidki]

Having javascript.options.showInConsole set to true, i get these messages when logging into my GMail account:
No chrome package registered for chrome://adblockplus/skin/adblockplus.png .
No chrome package registered for chrome://flashblock/skin/flash-on-24.png .

It turned out to be this script:
http://mail.google.com/mail/?view=page&name=js&ver=a9a9lo240wm7
I don't know for how long the URL is accessible.  Also, the script comes as text/html, so you have to look at the source to see:
var f={"chrome://flashblock/skin/flash-on-24.png":"bf-fb","chrome://adblockplus/skin/adblockplus.png":"bf-ap"};

sidki

Comment 29

[Jesse Ruderman]

That's not this bug.  That's "IMG tags can access chrome" and it's arguably not a bug.

Comment 30

[Boris Zbarsky [:bzbarsky]]

They're all bugs, Jesse.  What we _should_ have is a small subset of chrome that's world-accessible instead of making it all world-accessible.  Please see my post to .security (the one that went completely unanswered) about this...

Comment 31

[Wladimir Palant]

Jesse, they are very much bugs. Have a look at http://jeremiahgrossman.blogspot.com/2006/08/i-know-what-youve-got-firefox.html and say hello to Big Brother. Fortunately I could implement a work-around in Adblock Plus. I designed it in such a way that it can be used by other extensions as well (http://adblockplus.org/en/faq_internal#protectchrome), but not every extension can rely on Adblock Plus being installed. It would be nice to see something like this in Gecko.

Comment 32

[Jesse Ruderman]

I agree with bz that it would be better if only a small subset of chrome were accessible to content.  But extensions that put things into that subset would still be detectable with the same method.  How about denying content *all* access to chrome, and instead allowing chrome scripts (and user stylesheets) to stick images (and XBL) with chrome: URLs into web pages?  See also bug 204140.

Comment 33

[Wladimir Palant]

Yes, my solution to the problem of extensions needing to put chrome content into documents is more of a hack. Its only advantage - it works.

Generally disallowing chrome access: stylesheets are not a problem I guess, allowing DOM nodes to request chrome content if the request was initiated by a chrome script will be more of an issue however. But that surely can be implemented. However, it will break some functionality in remote XUL that currently works - having content XBL that extends a chrome XBL or binding chrome XBL to selected nodes (via CSS or document.addBinding) will no longer work.

Comment 34

[Boris Zbarsky [:bzbarsky]]

Yeah, that's the real question.  We need to decide what our remote XUL story is and implement it, while also keeping security in mind (unlike the current remote XUL impl).  This needs people familiar with XUL, the chrome registry, and security to sit down and talk to each other.  The problem has been finding said people.

I do think we should fix this for Gecko 1.9 -- it keeps coming up as a problem, and it's a serious one imo.  Sadly, this bug doesn't seem to be in Core...

Comment 35

[[e-mail]]

If you could make Gecko automatically import chrome://global/skin/ in such a way that it overrides xul.css then remote XUL should never have to explicitly refer to chrome. (As yet I'm not convinced on remote XUL deriving bindings from chrome). What I don't know is how you would know whether a certain image request originated from a chrome stylesheet or binding or not.

You can still work out what the user's current theme is, by including a representative sample of XUL elements and inspecting their computed style.

Comment 36

[Boris Zbarsky [:bzbarsky]]

> What I don't know is how you would know whether a certain image request
> originated from a chrome stylesheet or binding or not.

The changes I'm considering for bug 221428 would allow me to know.

Importing chrome://global/skin/ should be pretty trivial -- just do it the same way we do mathml.css and svg.css, no?  Or hardcode it in the document viewer for the XUL type.  Or whatever.

Comment 37

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

Hmm.. so how do XBL currently pull in chrome-script? Isn't all script in xbl1 inside the XBL file rather than in external script-files? Or are we worried about extensions putting <script> in the anonymous content?

Comment 38

[Boris Zbarsky [:bzbarsky]]

I don't think web pages should have access to extension-provided XBL either, generally speaking.

Basically, what I think we should do is have a chrome registry way to flag packages as "web-accessible" or something, and not allow things not flagged that way to be linked to (fail CheckLoadURI checks for them).

Comment 39

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

Agreed, I'm just trying to figure out where we need to add blockers. If we want chrome-xbl to be able to have <script>s linking to chrome-scripts we have to somehow flag this on the individual bindings and make script elements check which binding they live in before allowing linking to chrome. Though on second thought that wouldn't be safe since the page can reach in to the binding and insert script elements there. Alternatively we could flag the individual anonymous content nodes, but I bet there'd be ways to work around that too.

So it looks like a first step would be to block non-chrome <script> elements from linking to chrome files, that should take care of the ability to access pure javascript files.

Comment 40

[Benjamin Smedberg]

I don't think we need to check where we're linking *from*... only where we're linking *to*:

e.g. it's ok for web content to link to chrome://xul-bindings (scripts, css, xbl bindings, etc)
but not to chrome://adblock

Comment 41

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

Not sure I follow you. We don't want to block chrome://browser/content/browser.xul from loading browser.js, but we do want to block http://evil.com/ from doing the same.

Comment 42

[Benjamin Smedberg]

We want to block evil.com from loading chrome://browser/content/browser.js

But we want evil.com to be able to load chrome://xul-bindings/content/textbox.js

e.g. in the chrome manifest there would be a flag saying the "xul-bindings" package is safe for content to load.

Comment 43

[Wladimir Palant]

Jonas, there is not only <script>s but also images. And images are far more likely to be found in the anonymous nodes. Problem with flagging anonymous nodes would be that web sites have access to those and can change attributes like src. So to do this properly you would have to unflag the nodes when content changes src attribute and flag them again when chrome does it - that's going to be a mess. It is probably easier to track down the source of each request but this still means lots of changes.

Comment 44

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

Bsmedberg: do we really have any textbox.js type files that anyone needs to load? Looks to me like all of xul lives in .xml xbl files.

Wladimir: Yes, this doesn't solve images, but fixing scripts seems like it's a step on the way.

Comment 45

[Benjamin Smedberg]

sicking, does it matter? The point is that script can load anything from some specific set of chrome packages, and not others (and the default would be inaccessible). This solves the problem of detecting whether an extension is installed (unless the extension wants to make their chrome available to web content, of course).

Comment 46

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

Sure, I'd be fine with having a flag like that if we think that anyone's actually going to use it.

Comment 47

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

Hmm.. Would such a flag solve images even? I.e. could we apply that flag to <img>s and only flag the few directories that XUL and editor[*] uses as being ok to link to?

[*] I believe that one reason we allow pointing <img>s to chrome urls is because editor needs it to implement some of its editing widgets.

Comment 48

[Wladimir Palant]

Benjamin, would it still allow an extension to use addBinding() with a protected chrome URL on a content node? I guess not, checkLoadURI will only know that there is a content document that tries to load an URL that it shouldn't load. In Adblock Plus I have exactly that case - I don't want content to be able to load any of its files (including that binding) but I need the possibility to apply the binding when I want to. Don't know how common this case would be, my solution is linked in comment 31.

Comment 49

[Benjamin Smedberg]

Yes, that flag should be used for images as well.

Comment 50

[Benjamin Smedberg]

Hrm, if you are manually calling addBinding(), why use a chrome: URI instead of, say, a data: URI?

Comment 51

[Wladimir Palant]

I tried, data: URIs don't work for bindings. I guess the anchor is not recognized.

Comment 52

[Boris Zbarsky [:bzbarsky]]

We could make addBinding() work (make it pass an explicit principal, gotten off the JS stack, to the XBL core, and change that to use that explicit principal).  In fact, we'll probably need to do something like that if we decide to _really_ keep track of who's loading the XBL (and give principals to stylesheets, etc).

And yes, XBL doesn't support nsSimpleURI URIs because they don't have anchors as far as our code is concerned.

Comment 53

[Jesse Ruderman]

> I tried, data: URIs don't work for bindings. I guess the anchor is not
> recognized.

Bug 243917 :(

Comment 54

[lkartaltepe]

How about adding something like a .access file to each chrome:// directory. Then this file can be consulted for which groups can access files in the directory. What exactly these different groups are still needs to be decided, but does this work as a solution?

Comment 55

[Ben Bucksch (:BenB)]

First, I'm all for making Mozilla more secure, where possible. I would understand, if this "untrusted can load chrome scripts as untrusted" feature got chopped.

We have a useful use for it, though: Most of the UI is chrome with systenm privileges, needs them. Some of it interacts only with the server, though, so in the interest of security, I made it untrusted. We still want to have the same look for everything, though, and we need (almost) the same self-written JS libraries and XBL widgets on both sides of the fence. The solution right now is to let untrusted load them from chrome: URIs. Any other suitable solution would be welcome, too, and I'd be willing to adapt to any Mozilla changes, given a warning.

There's a potential spoofing danger to allowing untrusted to access local skins, though, no? Brendan mentioned the changable skins as anti-spoof protection. (Granted, that's largely irrelevant now that skins are no longer in vogue, with Firefox.)

Comment 56

[Boris Zbarsky [:bzbarsky]]

You could probably implement a very thin shim protocol handler to do this; that way you could control access to exactly the scripts you want to expose.

That's assuming we don't end up with a "native" mechanism for doing that, of course.

Comment 57

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

Isn't the 'res' protocol still around?

Comment 58

[Reed Loden [:reed]]

Is this what http://www.0x000000.com/?i=417 is talking about?

Comment 59

[Giorgio Maone [:ma1]]

(In reply to comment #58)
> Is this what http://www.0x000000.com/?i=417 is talking about?

Yes it is, as I suggested in http://ha.ckers.org/blog/20070811/firefox-remote-variable-leakage/#comment-45648

Didn't notice this passage, though:

"I've tested this against my own Firefox extension called: Fire Encrypter. And I was able to steal a dynamically generated password successfully."
 
Passwords or private keys hard-coded in a script?!
Or does this extension persitently pollute content some way?

Comment 61

[Ben Bucksch (:BenB)]

> I was able to steal a dynamically generated password successfully.

If (just guessing) Fire Encrypter would at initialization/loading time generate a password and store it in a variable, remote content would have access to it. It would just not be the *same* password that the real extension running with system rights uses, because it's a new instance with new variables.

Comment 62

[lkartaltepe]

The security of private values being stored in javascript isn't what concerns me as a consumer. What concerns me is that I am becoming less anonymous in that websites can determine what plugins I am running, such as firebug, greasemonkey, and ad-blocker and websites are beginning to block me based on this information.

Comment 63

[War59312]

NoScript 1.1.6.15 addresses this some what:

+ noscript.forbidChromeScripts preference (true by default), prevents 
  script tags in content (non chrome:/resource:/file:) documents from
  referencing chrome: scripts, see
  https://bugzilla.mozilla.org/show_bug.cgi?id=292789

http://noscript.net/changelog

Comment 64

[Ben Bucksch (:BenB)]

AdBlock Plus also addresses it since quite some time
http://adblockplus.org/en/faq_internal#protectchrome

Comment 65

[Flaky Jake]

See discussion at http://forums.mozillazine.org/viewtopic.php?t=590601

I've got Adblock Plus 0.7.5.3 (and NoScript 1.1.7.2) and that website can still tell whether Adblock Plus is enabled or not. It's serving ramdom content when Adblock Plus is enabled. Very disturbing!

Comment 66

[Wladimir Palant]

This page simply shows random content, every time you do a full reload it is something different. Somebody probably misconfigured the server. Nothing to do with Adblock Plus or the issue discussed here.

Comment 67

[snooky lansing]

If access to a configuration, addons/extensions or even themes is available without consent it is a provacy issue.

Comment 68

[Boris Zbarsky [:bzbarsky]]

Everyone, please take a step back and go read https://bugzilla.mozilla.org/etiquette.html

Feel free to readd me to the cc list once this bug stops being a pointless-comment-fest.

Comment 69

[snooky lansing]

Having read the previous posts and comments and later on realizing I could have added detail to my post I offer the following for a better understanding. Also sorry if there is some disagreement in my theory, it is not argument but just a consideration.

If one has a mechanical device, one of multiple duplicates manufactured, it's operation creates a series of sounds, a signature, specific to that unit, different from the other peer units. It would seem the information which is central to this issue could be treated as a "signature" on it's very own. While not actually specific to one individual user it could create class identifiers which could then be placed with other indicators such as time for more definition. 

My apology if this comment is not what is considered relative.

Comment 70

[Damon Sicore (:damons)]

jruderman:  +'ing and assigning to you.  Please determine if we are going to fix this or not.  Also, setting priority at P4 as we're not going to block a beta any time soon on this. 

Comment 71

[Mike Beltzner [:beltzner, not reading bugmail]]

Decision needed ASAP, moving to P2

Comment 72

[Daniel Veditz [:dveditz]]

Yes, we need this for Firefox 3

Comment 73

[Daniel Veditz [:dveditz]]

Attachment: whitelist chrome packages that ALLOW_CHROME applies to

This blocks content access to chrome: urls, even in places where the ALLOW_CHROME CheckLoadURI() flag has been set. To keep too many things from breaking there's a whitelist of allowed packages, initially populated with global and browser so as not to break the feed reader.

Testcases that need to continue working:
+ view a feed (http://rss.news.yahoo.com/rss/topstories#)
  should show feed, and media links should show the moz-icon: items

+ Open resource:/// and check directory. Should show the moz-icon:s in the listing.

+ view-source -- should be styled.

This is extensible, so if an extension really needs to allow links to its own chrome (icons maybe?) it can do so, knowing that that potentially allows attackers to fingerprint users of that one extension. For example, Jesse's shell bookmarklet includes scripts from extensiondev if it's installed, so that extension could add the pref "security.chrome_access.extensiondev" and set it to true in order to keep working from the shell bookmarklet.

Comment 74

[(not currently active) Ted Mielczarek]

I don't think the extensiondev bits actually work outside of a chrome context anyway, I think they're just included so Jesse doesn't have to maintain two different versions of the file. :)

Comment 75

[Ben Bucksch (:BenB)]

In the comment in the default prefs, please make clear that the string "browser" is not the English term, but the name of the chrome page. Ideally, give an (commented-out) example how to add my own chrome package with a funny name. (It's clear to me, but won't be for others.)

Comment 76

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 314817 [details] [diff] [review]
whitelist chrome packages that ALLOW_CHROME applies to

>Index: caps/src/nsScriptSecurityManager.cpp
>+            nsCAutoString accesspref("security.chrome_access.");

Let's make that "security.chrome_access_allowed."

Other than that nit, I'm pretty happy with this approach.  Though it might also make sense to ask the chrome registry instead of checking prefs, and have that use bits like it does for XPCNativeWrapper or whatnot...  I'd check with bsmedberg to see which he thinks is a better idea.

>Index: browser/app/profile/firefox.js

Please file bugs on Seamonkey and Thunderbird to add such prefs as needed?

Also, please file a bug to move as much as possible out of the "browser" and "global" packages, or to leave things there and move the "web-accessible" stuff to different packages and adjust the prefs appropriately?

There should be some tests here.  Certainly tests to make sure things are no longer accessible when they shouldn't be, but ideally also the "this should keep working" tests you list.

Comment 77

[Benjamin Smedberg]

I certainly think asking the chrome registry is the better long-term approach: it avoid spreading information about a chrome package over a large surface area. And it's quite easy to implement, if all you want is something like:

nsIChromeRegistry::CanScriptAccess(in nsIURL chromeURL)

that's a 30-minute patch

Comment 78

[Benjamin Smedberg]

Attachment: add a contentaccessible flag to chrome registration

Comment 79

[Benjamin Smedberg]

Oh, please pretend that I rev'ved the IID of nsIXULChromeRegistry

Comment 80

[Daniel Veditz [:dveditz]]

Attachment: alternate w/chromereg change

Alternate implementation of whitelisting using Benjamin's ChromeReg patch.

Comment 81

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 314954 [details] [diff] [review]
alternate w/chromereg change

I like this!

Comment 82

[Dave Townsend [:mossop]]

Comment on attachment 314919 [details] [diff] [review]
add a contentaccessible flag to chrome registration

>diff --git a/content/base/public/nsIChromeRegistry.idl b/content/base/public/nsIChromeRegistry.idl
>--- a/content/base/public/nsIChromeRegistry.idl
>+++ b/content/base/public/nsIChromeRegistry.idl
>@@ -93,6 +93,13 @@ interface nsIXULChromeRegistry : nsIChro
>    * method.
>    */
>   boolean allowScriptsForPackage(in nsIURI url);
>+
>+  /**
>+   * Content should only be allowed to load chrome JS from certain packages.
>+   * This method reflects the allowContentAccess flag on packages.
>+   * Do not pass non-chrome URIs to this method.
>+   */
>+  boolean allowContentToAccess(in nsIURI url);
> };

Nit: The flag is named "contentaccessible"

r=me on the code changes, however you should add a unit test for the flag.

The test changes in the patch seem to be unrelated to this bug and appear to be broken. It looks like you have added a head js file but not included it in the patch.

Comment 83

[Benjamin Smedberg]

Attachment: add a contentaccessible flag to chrome registration

Argh, I spent an extra 30 minutes on the unit tests and then forgot to attach them!

Comment 84

[Benjamin Smedberg]

Attachment: add a contentaccessible flag to chrome registration, final

Mossop looked over my unit tests and suggested one change.

Comment 85

[Daniel Veditz [:dveditz]]

Attachment: mochitest

Comment 86

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 315024 [details] [diff] [review]
mochitest

r=bzbarsky if you run the is/ok() things from a load event.  Otherwise the images might not have loaded yet...

Comment 87

[Boris Zbarsky [:bzbarsky]]

Though ideally we'd have a guaranteed way of testing the "can't load" thing.  Right now, if someone moves those resources and then this bug regresses we won't catch that...

Comment 88

[Reed Loden [:reed]]

Comment on attachment 315024 [details] [diff] [review]
mochitest

>+  <img id="img-global" src="chrome://global/skin/icons/Error.png">

gnomestripe's use of this image is deprecating soon, so it may be wise to use something that is actually themed by all three themes, such as "chrome://global/skin/icons/find.png". For toolkit, gnomestripe overlays winstripe, so it's possible this might continue to work, but it's not guaranteed to work, as would a file that all three themes individually have.

Comment 89

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 315008 [details] [diff] [review]
add a contentaccessible flag to chrome registration, final

a1.9=beltzner

Comment 90

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 314954 [details] [diff] [review]
alternate w/chromereg change

a1.9=beltzner

Comment 91

[Jeff Walden [:Waldo]]

(In reply to comment #87)
> Though ideally we'd have a guaranteed way of testing the "can't load" thing. 

Do a chrome test and include in the page an iframe which sources the same script and checks for |typeof ChromeVar == "undefined"|, changing its query string to indicate the result of the test.  The outer window can at load add a load listener to the iframe and set its location to start the test.  The second time the iframe listener fires, check for success/failure using the iframe's location.  Finally, check |typeof ChromeVar != "undefined"| and you're foolproof.

Comment 92

[Daniel Veditz [:dveditz]]

Attachment: updated mochitest

This one verifies that the chrome we're blocked from loading actually exists, that the load failed because of this bug's fix and not because someone happened to remove one of the resources we're trying to load.

The img onError fires twice: mochitest (in my build) reports 7 tests when there are really only 6.

Comment 93

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 315049 [details] [diff] [review]
updated mochitest

>Index: caps/tests/mochitest/Makefile.in
>+    img.src = uri;
>+    document.getElementById("content").appendChild(img);

This will possibly kick off the load twice (which might explain your error event thing). I wouldn't bother inserting into the document if you're listening for error/load events and don't care about the sizing.

With that one line removed, looks wonderful.

Comment 94

[Benjamin Smedberg]

Landed the chrome-registry changes on CVS trunk.

Comment 95

[Giorgio Maone [:ma1]]

I just tried to package an extension adding to chrome registration the contentaccessible=yes flag, but installation apparently fails:

Warning: Warning: Unrecognized chrome registration modifier 'contentaccessible=yes'

Even if it's reported as a warning, the chrome does not get registered (yesterday's trunk and branch).

How are we supposed to handle backward compatibility for extensions which want to keep working on Fx 2 for some time?

Comment 96

[Benjamin Smedberg]

You can probably use version modifiers of the form:

content mypackage location/ contentaccessible=yes
content mypackage location/ application={ec8030f7-c20a-464f-9b0e-13a3a9e97384} appversion<3.0pre

Comment 97

[Wladimir Palant]

That doesn't sound great when you have to support five applications. I guess something like this will work as well:

content mypackage location/
content mypackage location/ contentaccessible=yes

Older browsers should ignore the second line while in the newer browsers the second should override the first (?). I didn't try but that should work?

Comment 98

[Benjamin Smedberg]

Yes, I believe it should work. Please try it and let me know.

Comment 99

[Daniel Veditz [:dveditz]]

> How are we supposed to handle backward compatibility for extensions which want
> to keep working on Fx 2 for some time?

Should we backport this fix to FF2, or even just the chrome registry part? Doesn't help if you need to support down-rev FF2 versions, but if your users are in the vast majority who keep up to date (which is a good bet for NoScript users) you'd be fine.

caps part of fix checked in.

Comment 100

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Are we sure we didn't want to wait until closer to the freeze, so we could have a bigger surprise for extension authors? :(

Can someone here familiar with the details write a doc (or multiple) for MDC describing how to address the use cases that motivated the WONTFIX in comment 8?  Given that the remote XUL use cases are important enough to keep us from removing the content-XBL attack surface, I presume we're about to break some pretty important applications with this...

Comment 101

[Phil Ringnalda (:philor)]

(In reply to comment #76)
> Please file bugs on Seamonkey and Thunderbird

Oh, don't worry about us, we'll find out when you break us, same as always.

Comment 102

[[e-mail]]

(In reply to comment #76)
>Also, please file a bug to move as much as possible out of the "browser" and
>"global" packages, or to leave things there and move the "web-accessible" stuff
>to different packages and adjust the prefs appropriately?
Would it work to drop a file into resource: somewhere, and make that import the chrome file e.g. for the four or so stylesheets SeaMonkey and Thunderbird use:
chrome://messenger/skin/messageBody.css
chrome://editor/content/EditorContent.css
chrome://editor/content/EditorAllTags.css
chrome://editor/content/EditorParagraphMarks.css

Comment 103

[Wladimir Palant]

(In reply to comment #98)
> Yes, I believe it should work. Please try it and let me know.

Tested it - yes, my suggestion in comment 97 works. Firefox 2 will warn about the unknown "contentaccessible" flag but accept the first declaration. And Firefox 3 will allow access because of the second declaration.

However, as it turns out doing that isn't necessary for Adblock Plus - the call to addBinding happens with chrome privileges, apparently that's enough to attach a chrome binding to content.

Comment 104

[Philip Chee]

Causes a regression in Camino Flash blocking.

From Bug 292789 Comment 1

> Ew.  We didn't get a complete fix for bug 292789, so we might be stuck :( 

> http://tinyurl.com/4dbqes

Comment 105

[Philip Chee]

(In Reply to Comment #100)
> Are we sure we didn't want to wait until closer to the freeze, so we could have
> a bigger surprise for extension authors? :(

(In Reply to Comment #101)
> Oh, don't worry about us, we'll find out when you break us, same as always.

Like Phil says.

Comment 106

[Philip Chee]

> From Bug 292789 Comment 1
Correction: From Bug 428747 Comment 1

Comment 107

[Serge Gautherie (:sgautherie)]

(In reply to comment #102)
> chrome://messenger/skin/messageBody.css

Fix(es) is in bug 428767.

> chrome://editor/content/EditorContent.css
> chrome://editor/content/EditorAllTags.css
> chrome://editor/content/EditorParagraphMarks.css

No fix needed: see bug 428852...

Comment 108

[[e-mail]]

(In reply to comment #102)
> chrome://editor/content/EditorContent.css
> chrome://editor/content/EditorAllTags.css
> chrome://editor/content/EditorParagraphMarks.css 
So as with comment #103 EditorAllTags.css is loaded by chrome, so no problem.

However I'd still appreciate an answer as I don't really want to expose all of mailnews just for one CSS file.

I notice that venkman also tries to load chrome stylesheets from content.

Comment 109

[Boris Zbarsky [:bzbarsky]]

> Would it work to drop a file into resource: somewhere, and make that import the
> chrome file

It should, yes.

Comment 110

[Boris Zbarsky [:bzbarsky]]

Though that depends on the "resource and chrome are same-origin" thing, which is something we really want to change sometime.  Not for 1.9, though.

The "right" solution to that problem is to put the CSS file into its own chrome package which is exposed.

Comment 111

[Serge Gautherie (:sgautherie)]

(In reply to comment #108)
> So as with comment #103 EditorAllTags.css is loaded by chrome, so no problem.

See bug 428852 comment 5 and 6:
The two used and still working editor css files are used by
|.addOverrideStyleSheet()| and |.enableStyleSheet(..., false)|,
and not a SCRIPT tag.

The current bug blocked the SCRIPT tag.
Is it fine that these functions still work ?
(Dumb question, as I really don't know anything about all this.)

> However I'd still appreciate an answer as I don't really want to expose all of
> mailnews just for one CSS file.

Sure, it would be nice if bug 428767 could be a short-term only solution...

> I notice that venkman also tries to load chrome stylesheets from content.

I filed bug 428848.

Comment 112

[James Justin Harrell]

If Firefox 3.0 beta 4, I can still do something like this:

if( "nsIFireBug" in Components.interfaces ) {
    alert("You seem to have FireBug installed.");
}

This has been used in the wild to block Adblock users. This information leak has been well known for ages, yet I don't see it mentioned anywhere in here. Does Mozilla need an information leak meta-bug?

Comment 113

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Sorry for the spam, but does the resolution of this bug affect the application
of a chrome:// XBL to a web page from chrome JS ? I am afraid it does...

Comment 114

[Wladimir Palant]

Note that contentaccessible=yes flag is only accepted on the content declaration but will affect skin and locale as well - I think that should be noted in the documentation.

(In reply to comment #113)
> Sorry for the spam, but does the resolution of this bug affect the application
> of a chrome:// XBL to a web page from chrome JS ? I am afraid it does...

Yes, it does - that's the main reason why chrome://browser/ and chrome://toolkit/ have been whitelisted.

Comment 115

[:Gavin Sharp [email: [e-mail]]]

Attachment: modified test

I reworked the test to avoid using setTimeout, and instead rely on the load events. I'm going to land this now in an attempt to address the linux orange that's been around since this test landed.

Comment 116

[Jesse Ruderman]

James, please do file a bug report on the Components.interfaces information leak.  A metabug about leaks of extension information wouldn't hurt (parallel to bug 412525?).

Comment 117

[Eric Shepherd [:sheppy]]

Already fixed in docs.

Comment 118

[James Justin Harrell]

Jesse, I filed Bug 429070.

Comment 119

[[e-mail]]

Comment on attachment 314954 [details] [diff] [review]
alternate w/chromereg change

>+                reg->AllowContentToAccess(targetBaseURI, &accessAllowed);
Eww, no rv check - no wonder attachment 316287 [details] [diff] [review] works.

Comment 120

[[e-mail]]

Is is possible to do a security check that allows linking to contentaccessible chrome packages? Bug 429721 added <link rel="icon" type="image/png" id="favicon" href="chrome://global/skin/icons/warning-16.png"/> to netError.xhtml which causes SeaMonkey to fail its security check.

Comment 121

[Godmar Back]

I noticed that this fix broke our extension (LibX) in FF3 RC1 and later.
This breakage occurs despite the fact the scenario against which this fix is directed (untrusted code trying to access chrome:// content) does not apply.

The restriction you put in place now prevents even trusted extension code from adding <img> elements to a document if this img's src attribute refers to a chrome:// URL.

See Bug 436989 for details.

Comment 122

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #121)

> The restriction you put in place now prevents even trusted extension code from
> adding <img> elements to a document if this img's src attribute refers to a
> chrome:// URL.
> 

We don't really care _how_ the img src attribute is set the "chrome://", the fact that a web content element is trying to access a chrome resource is all that matters, and we shut it down - unless contentaccessible=yes is set in the chrome manifest. This isn't really a scripting issue, it's a chrome protocol issue.

> See Bug 436989 for details.
> 

I marked that INVALID based on the above

Comment 123

[Godmar Back]

> We don't really care _how_ the img src attribute is set the "chrome://", the
> fact that a web content element is trying to access a chrome resource is all
> that matters, and we shut it down 

That strategy is what I am questioning (or looking for rationale.)

The original complaint in this bug report was that sites can detect if an extension is installed if web content is allowed to add elements that refer to chrome:// resources to their DOM. 

This goal could have been achieved by disallowing only web content from installing or using chrome:// URLs in img and script elements created by it. Instead, you ignore who is setting the chrome:// URL in an element and simply do not render the element. What is the rationale for this decision? (Other than that it took only 30mins to implement, as noted in comment #77 ?)

Comment 124

[Unknown W. Brackets]

(In reply to comment #123)
> That strategy is what I am questioning (or looking for rationale.)
> 
> The original complaint in this bug report was that sites can detect if an
> extension is installed if web content is allowed to add elements that refer to
> chrome:// resources to their DOM. 
> 
> This goal could have been achieved by disallowing only web content from
> installing or using chrome:// URLs in img and script elements created by it.
> Instead, you ignore who is setting the chrome:// URL in an element and simply
> do not render the element. What is the rationale for this decision? (Other than
> that it took only 30mins to implement, as noted in comment #77 ?)
> 

From a security standpoint, it's much better to solve a problem at the mouth of the river than to patch up all the little streams.

Solve something at the root and it's solved everywhere.  The fact that this was quick and simple was even better; instead of spending many hours (which are needed in many places) trying to fix all the cases where web content might be able to add something, and missing something, it was done correctly and fairly quickly too.

Sounds like efficiency and good security practice to me.  If this has limited features, I would suggest a new bug should be filed asking for the ability to add things to the page, in some way, without letting the page add them itself.

-[Unknown]

Comment 125

[Jeff Walden [:Waldo]]

(In reply to comment #123)
> This goal could have been achieved by disallowing only web content from
> installing or using chrome:// URLs in img and script elements created by it.

Why bother?  Dump the stuff you want usable by web content in its own named package, set the content-accessible flag, and let 'er rip.  If the choice here truly limited what you could do, I might sympathize, but you can opt in to exactly the behavior you had in the past with no skin off your back.

Comment 126

[Godmar Back]

> Why bother?  Dump the stuff you want usable by web content in its own named
> package, set the content-accessible flag, and let 'er rip.

I'm sorry if this hasn't been clear, I do not want anything to be "usable by web content."  I don't care what web content uses, knows, or sees about the images I add, as long as they display.

> I would suggest a new bug should be filed asking for the ability to
> add things to the page, in some way, without letting the page add them itself.

Like Bug 436989 ?

Other than that, I do agree with the simplicity argument made in comment #124.

Comment 127

[Unknown W. Brackets]

(In reply to comment #126)
> > Why bother?  Dump the stuff you want usable by web content in its own named
> > package, set the content-accessible flag, and let 'er rip.
> 
> I'm sorry if this hasn't been clear, I do not want anything to be "usable by
> web content."  I don't care what web content uses, knows, or sees about the
> images I add, as long as they display.
> 
> > I would suggest a new bug should be filed asking for the ability to
> > add things to the page, in some way, without letting the page add them itself.
> 
> Like Bug 436989 ?

Perhaps so, but it sounds like this really hasn't limited features.

All you'd do is create a second chrome content directory in your extension, and expose it under a different base chrome:// URI.  So, let's say your current is "chrome://libx/", you'd have "chrome://libx-www/".

Now, since you don't care if web content links to your chrome there (although it's unlikely), you set the content-accessible flag in chrome.manifest.

Then your extension (js code under chrome://libx/) creates an img tag, and sets its src to chrome://libx-www/whatever.png.

And life is good.  This is probably a cleaner way to separate it anyway.  In fact, if you're using a skin (instead of content) in chrome.manifest for the images you want to reference, you might even be able to just put the flag on there and not worry about anything.

-[Unknown]

Comment 128

[Godmar Back]

[ I was going to drop this thread, but I keep getting misunderstood ].

Comment #127 and comment #125 are correct that your fix does not limit features if I set contentaccessible=yes.  Doing so produces the behavior that was in Firefox before. It just means that I do not benefit from the intended effect of this fix, which is to allow extensions to stay undetected by untrusted web content sniffing for them.

The suggestion to create a second chrome directory with the flag contentaccessible=yes flag is, in my opinion, entirely besides the point.  If the goal is for an extension to stay undetected, then it can't set the contentaccessible=yes flag on *any* of its chrome paths.  If I have to set it on any, I may as well set it on all paths.

My suggestion would be to not consider this issue closed, but mark it for future consideration.

Comment 129

[(not currently active) Ted Mielczarek]

If you are adding chrome content to a webpage, then you are explicitly telling the page that your extension exists. The page could have a DOM mutation event listener, and notice your images being inserted. Even if we lied about the URL or denied access, the page could probably use that misinformation to realize that it was being modified. There's really no good solution for that.

Comment 130

[Godmar Back]

True --- but the applied fix, which forces me to set contentaccessible=yes to at least some part of my chrome:// content, leaves me open to detection even by pages whose DOM my extension does not change, just like it was before the fix.  So the fix does not achieve its objective for at least some extensions, which is why I wouldn't close it entirely.

Comment 131

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

For images, you can construct a data: URL and use it, or probably use a canvas element and drawImage into it with your chrome image element as the source.  For scripts, just create a script element and insert the script you want as child content, and then add it to the document -- should work fine.  (Or use a data: URL for scripts as well, of course.)

Comment 132

[(not currently active) Ted Mielczarek]

I'm saying your extension's behavior defies the intent of this fix, so it's a moot point. Just set contentaccessible=yes and you're back where you started.

If you want the protection this fix enables, you will have to find a different way to do what you're doing. End of story.

Comment 133

[Godmar Back]

data: URIs, to my (possible incorrect) knowledge, are limited in length and do not make for a fully functional replacement. In our extension, which actually comes in over 360 editions, adopters control the type and size of the images added.

This fix, as is, creates a (minor) pain, no gain situation for our extension and extensions like it. What is starting to make this a major pain is the apparent refusal to acknowledge and document this trade-off, however reasonable it may be.

Comment 134

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

We've been acknowledging that trade-off all over the place, in this very conversation.  You could add it to the documentation if you wanted, certainly, if you think that the current documentation of it is insufficient.  We didn't document "web pages can detect extensions" at all before, so it still seems like your complaint is "this doesn't improve things for me, because I want to mutate content pages without detection" plus "I have to add a few dozen characters to my chrome.manifest" -- not sure why you think that it needs more documentation than just the chrome.manifest change.

I don't know of any limitations on data: URI length in Firefox, and <canvas>+drawWindow should let you work with any image you choose, regardless of the source, and without converting to base64.  Tried it?

Comment 135

[Godmar Back]

Fair enough.

Comment 136

[Nelson Bolyard (seldom reads bugmail)]

My profile's userChrome.css became broken in the last 2 weeks.
I wonder if the fix for this bug is the cause.
The userChrome file contains:

#navigator-throbber
{list-style-image : url("chrome://communicator/skin/brand/throbber-single.gif")
 !important; }

And the new error (shown in error console) is:

Security Error: Content at
file:///.../Mozilla/SeaMonkey/Profiles/.../chrome/userChrome.css
may not load or link to
chrome://communicator/skin/brand/throbber-single.gif.

Clearly the contents of userChrome are not web content, and denying 
userCrome access to chrome is a bug.

Comment 137

[Eyal Rozenberg]

I have the same problem with an extension of mine, which adds a chrome CSS to mailnews messages; it's BiDi Mail UI 0.9, and I get:

Security Error: Content at mailbox:///C|/Some/Where/MyFolder?number=22870681 may not load or link to chrome://bidimailpack/content/quotebar.css.

this is not userChrome.css but I suspect the cause is the same.

Comment 138

[Unknown W. Brackets]

(In reply to comment #137)
> I have the same problem with an extension of mine, which adds a chrome CSS to
> mailnews messages; it's BiDi Mail UI 0.9, and I get:
> 
> Security Error: Content at mailbox:///C|/Some/Where/MyFolder?number=22870681
> may not load or link to chrome://bidimailpack/content/quotebar.css.

Please see comment #132, comment #114, comment #97, etc.

-[Unknown]

Comment 139

[Marcin Kasperski]

I am yet another person faced with this problem (tested my extension with some firefox3 beta, where it worked perfectly, then out of sudden it stopped to work when firefox3 was published). Well, answered some googled, found contentaccessible=yes, answered some emails, I am done.

But - does there exist  any document which explain what should I do to avoid contentaccessible? My extension refers to the following content:

- a bunch of images (icons I inject into the page) - here I have no idea how could I avoid contentaccessible

- CSS files which I activate by creating link element inside head from overlay - here I could probably inject direct style elements, but as this CSS is rather long I find it unaesthetical at least

- javascript files which I activate by creating script elements inside head from overlay (I need them to provide callback functions extending builtin page functionality, working in the page context) - here again I could probably inject javascript directly, but considering the code is fairly long I again find it innatural

Comment 140

[Godmar Back]

Marcin,

for images, the Mozilla developer suggest you use data: URIs.  They are described here: http://en.wikipedia.org/wiki/Data:_URI_scheme

All you need to do is write the code to convert your data to Base64 and identify the correct MIME type.  Good luck.