Question regarding web_accessible_resources

[Mohamed Mansour]

Hello,

When creating overlays within content scripts, I usually use the iframe approach so I can define my own CSS and different view (MVVM) for that overlay than sharing the documents resources (css/js).

Now, with manifest 2, I cannot use the same approach unless I expose the web_accessible_resources attribute for that file. Any reasons why a content script cannot not inject their own iframe which is bundled within the extension? I really don't want external websites to be exposed to the html page that my extension has.

According to the doc "Injected content scripts themselves do not need to be whitelisted", shouldn't that be applied to html files?

Thanks,

Mohamed Mansour

[Joe Marini]

It's a security issue. Since content scripts themselves execute in their own context within the page, other scripts can't mess with their data. However, since any change you make to the DOM is visible broadly, we want to make sure that there are no potential vectors that a malicious script could exploit.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.

--
Joe Marini

Developer Advocate / Chrome

joem...@google.com | +Joe Marini | @joemarini

[John J Barton]

On Mon, Aug 27, 2012 at 10:07 AM, Joe Marini <joem...@google.com> wrote:
> It's a security issue. Since content scripts themselves execute in their own
> context within the page, other scripts can't mess with their data. However,
> since any change you make to the DOM is visible broadly, we want to make
> sure that there are no potential vectors that a malicious script could
> exploit.

Could you explain this a bit more?

As I understand the original question, the content-script adds an
iframe with a chrome-extension:// url to the web page. The web page
has no access to such an iframe, it's not in the same domain.

Where does the security issue arise?

Since the origin loading the scripts/styles/images into the iframe is
chrome-extension://<id>, the iframe is not part of the web page so the
web_accessible_resources doesn't even make sense to me in this
scenario.

jjb

[Mike West]

On Mon, Aug 27, 2012 at 7:28 PM, John J Barton wrote:

As I understand the original question, the content-script adds an

iframe with a chrome-extension:// url to the web page. The web page
has no access to such an iframe, it's not in the same domain.

Since the iframe is in the page's DOM, the page has the same cross-origin access to the frame that the content script would: postMessage. If you're not careful about the origin of messages that you receive and act upon, you might have a problem.

 

Since the origin loading the scripts/styles/images into the iframe is
chrome-extension://<id>, the iframe is not part of the web page so the
web_accessible_resources doesn't even make sense to me in this
scenario.

I think there's a good argument to be made that the iframe's internal resources (CSS, JS, etc) shouldn't need to be web accessible. If that's required at the moment, please do file a bug.

>> According to the doc "Injected content scripts themselves do not need to
>> be whitelisted", shouldn't that be applied to html files?

The content script isn't injected into the page in the same way an iframe (or any other element) is. If you inject a script into the page (by appending a `script` element, for instance), that script does need to be listed as web accessible.

What's the drawback from your perspective to adding the iframe.html file to web_accessible_resources?

-mike

[Mohamed Mansour]

Well,

I don't want any website to know I have the extension installed for various privacy reasons. I still don't understand why injecting my own html page into the DOM causes a security risk. Am I protecting against myself? So I am understanding the security implications here.

I agree in manifest 1 external websites could target extension installations hence why we now have web_accessible_resource, but enforcing the developer to add a resource to that list, defeats the purpose of having one.

Just filed the bug: http://crbug.com/145191

Kind regards,
Mohamed Mansour