Add permission to allow extensions to load semi-privileged URLs

NEW
Unassigned

Status

P2
normal
3 years ago
5 months ago

People

(Reporter: abr, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 5 bugs, {meta})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [design-decision-approved] triaged[tabs])

(Reporter)

Description

3 years ago
As identified by an add-on developer in <https://mail.mozilla.org/pipermail/dev-addons/2016-May/000610.html>, there are legitimate reasons for WebExtensions to be able to open URLs that correspond to certain about: URLs.

There are arguments in Bug 1227462 about why this shouldn't be allowed in the general case. Because of the legitimate uses, however, we should allow add-ons to request special permission. There are three ways I can envision this being designed:

1) Expand the set of allowed operations granted by the "tabs" permission to include using tabs.create() and tabs.update() to navigate to all "about:" URLs.

2) Define a new permission (say, "aboutTabs") that explicitly grants this permission, separate from the other enhanced tabs permissions.

3) Expand host permission match patterns to include the "about:" scheme, and allow tabs.create() and tabs.update() to navigate to any URLs specified in the host permission match patterns.
(Reporter)

Comment 1

3 years ago
Tagging Dan and Al for their awareness (since they were involved in Bug 1227462).
Do you have any concerns here, Dan? This seems reasonable.
Flags: needinfo?(dveditz)

Updated

3 years ago
Whiteboard: [design-decision-needed]
Paul, the potential use case for security page permissions we discussed in a meeting.

Updated

3 years ago
Whiteboard: [design-decision-needed] → [design-decision-needed] triaged
I don't have a security concern about adding a permission to allow a WebExtension to load privileged pages. It can be a reasonable thing to do, and by adding the permission it flags the use for reviewers to check and make sure it _is_ reasonable.

Doing something like this would be incompatible with Chrome and Edge though. might want to see if we can come up with something generic enough to pass muster with them.
Flags: needinfo?(dveditz)
(Reporter)

Comment 5

3 years ago
(In reply to Daniel Veditz [:dveditz] from comment #4)
> Doing something like this would be incompatible with Chrome and Edge though.
> might want to see if we can come up with something generic enough to pass
> muster with them.

I was under the impression that our model was going to be "WebExtensions++", where we explicitly planned to add interfaces (and presumably permissions) above and beyond those supported by Chrome.

Comment 6

3 years ago
I have to confess I was struggling to keep up with the notes and the conversation on this issue as we got into some details in the meeting at London. So I'm going to try and summarize it and get it wrong, please correct me. This particular bug is about allowing about: pages to be created from tabs.create etc. In the sense that this about opening new tabs and windows this should be fine in that, as long as there is no escalation of privileges that allows a developer to escape the sandbox.

In comment #4 dveditz suggests adding in a permission for this. I think the purpose of that permission is just to assist reviews and shouldn't be one we prompt users for.
Whiteboard: [design-decision-needed] triaged → [design-decision-approved] triaged[tabs]

Comment 7

3 years ago
FYI: Chrome extensions can navigate to *any* page, except for some explicitly blacklisted dangerous URLs (such as chrome://kill). This liberal approach has advantages and disadvantages:

Advantages:
- Extensions can activate protocol handlers which are unknown to the browser (e.g. magnet: URLs).
- Extensions can provide a button to quickly access some internal page (Downloads, settings, ...) - like a glorified bookmark.
- Extensions can guide the user to enable settings to allow the extension to function properly (see e.g. https://github.com/mozilla/pdf.js/pull/6233, the "chrome://extensions" "link" in the screenshot is using chrome.tabs.update because direct navigations are now allowed).

Disadvantages:
- If dangerous URLs are not blacklisted, then WebExtensions can cause bad things to happen.

Being able to navigate to some URL in itself should not be dangerous, otherwise any site that can trick a user into copying and pasting a URL can cause harm. The current restrictions are blocking legitimate use cases, even data:-URLs (which are allowed in window.open()) are currently blocked!

Updated

2 years ago
Component: WebExtensions: Untriaged → WebExtensions: Frontend
Priority: -- → P2
Summary: Add permissions item to allow use of tabs.create/tabs.update → Add permission to allow extensions to load semi-privileged URLs
Duplicate of this bug: 1322306
Duplicate of this bug: 1335102
Duplicate of this bug: 1356251

Comment 11

2 years ago
Any status on this? We need to open about:addons to fully migrate to webextensions...
thanks

Comment 12

2 years ago
(In reply to mozilla.utensil from comment #11)
> Any status on this? We need to open about:addons to fully migrate to
> webextensions...

If your add-on has an inline options page, then you can open about:addons (with your extension's options page shown) using browser.runtime.openOptionsPage:

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/openOptionsPage

Comment 13

2 years ago
Thanks for the quick reply, but I don't think that does what I want. I need to open the about:addons page that shows all the addons installed, as openings chrome://extensions does. Using browser.runtime.openOptionsPage() as you suggest instead opens two new tabs for me, about:addons showing only my addon, and the inline options page...

Comment 14

2 years ago
Any other thoughts, or a status update? Is this in the works? thanks
Duplicate of this bug: 1405415

Updated

a year ago
Blocks: 1405887
Duplicate of this bug: 1371793
I'm trying to wrap my head around this, I think there are several things that come up around loading urls:

1. When opening a URL in an existing tab, the XSS attack described in bug 1227462
2. Opening a new window/tab with window.open() provides the caller with the destination window object if they have the same origin
3. Some about: pages may not be prepared to handle arbitrary user input in query parameters (eg what if you open about:reader?url=javascript:whatever)

Due to #1, we check any urls that an extension tries to load with browser.tabs.create() (which opens a new tab) or browser.tabs.update() (which can cause an existing tab to load a new url) with nsIScriptSecurityManager.checkLoadURIWithPrincipal().  This is the only reason I bring up #2 since I think window.open() ends up in the same place (probably with different flags?) to check a URL passed to it.  However, I don't think #2 is actually an issue here since extension pages are not same-origin with about: pages.

As for #3, it looks like we have (or had?  or partially had?) a concept of which about: pages can be safely linked to:
http://searchfox.org/mozilla-central/rev/40e8eb46609dcb8780764774ec550afff1eed3a5/docshell/base/nsAboutRedirector.cpp#28-30
But empirically, that comment doesn't appear to be true any more, "buildconfig" has the URI_SAFE_FOR_UNTRUSTED_CONTENT flag but when I try to link to it I see a Security Error in the browser console.

I'm way over my head in arcane platform stuff here.  Boris, is the above correct and complete?  The quick context is that there are situations where extension want to open or navigate to about: pages.  UX concerns aside, are there reasons I've overlooked why this would be unsafe?  If we can agree this is safe for at least a subset of about: pages, how do we get there from here?
Flags: needinfo?(bzbarsky)
Blocks: 1403295
My first question is actually what the initial motivating use case is.  The link in comment 0 seems to go to a thread that has nothing to do with this bug.

> 1. When opening a URL in an existing tab, the XSS attack described in bug 1227462

This could be addressed without doing a general checkLoadURI check, fwiw.  Or by comparing checkLoadURI with/without DISALLOW_INHERIT_PRINCIPAL and disallowing only if the two disagree.

> 3. Some about: pages may not be prepared to handle arbitrary user input in query parameters

Right.  This comes back to the last paragraph of comment 7, where the "should not be dangerous" is definitely aspirational but likely false in practice in various cases.  Which is why the entire CheckLoadURI mechanism exists, in fact.

> "buildconfig" has the URI_SAFE_FOR_UNTRUSTED_CONTENT flag but when I try to link to it I see a
> Security Error in the browser console.

There are two separate concepts at this point:

1)  URI_SAFE_FOR_UNTRUSTED_CONTENT (not very well-named anymore): If set, the about: URI will _not_ run as system.

2)  MAKE_LINKABLE: whether untrusted content can link to the URI in question, but only if URI_SAFE_FOR_UNTRUSTED_CONTENT is also set.  This is incorrectly referred to as "URI_CONTENT_LINKABLE" in the docs for URI_SAFE_FOR_UNTRUSTED_CONTENT... :(

Obviously the issue in this bug is all about about: pages that currently are _not_ listed as "can be safely linked to"; that's the whole problem, right?

> Boris, is the above correct and complete?

Sort of.  In general, this should be a problem exactly in the sense that XSS is a problem.  With that in mind...

1)  It's not clear to me why the thing described in bug 1227462 is a problem.  It's not a problem on the web.  Are we doing those loads with a triggering principal that doesn't correspond to the relevant extension (e.g. system principal), or something?  If so, _that_ seems like something we should fix in general, no?

2)  Things like "you get access to the window you opened" are not an issue per se, in the sense that this happens on the web too.

3)  The fundamental premise of this bug (that about: URIs are "semi-privileged") is false.  The only actual URI mentioned in this bug as something extensions want to load is about:addons, which is system-privileged.

4)  The real problem is that this _is_ an XSS problem.  On the web, the responsibility for hardening against XSS injection attacks of various sorts basically falls on the target site.  The browser prevents direct scripting, but if the attacker can inject content of their choice into your site, that's your problem.  We do provide some tools like CSP to help avoid this problem, of course.  In the context of about: pages, we have historically had an additional mitigation that the web at large does not have: we simply prevent arbitrary loads of the about: page from untrusted content.  This reduces the XSS attack surface quite significantly, and allows us to not have to deal with carefully auditing all the bits of those about: pages.  Which we have not done, by the way.

Additionally, the consequences of a successful XSS attack on a privileged about: page are significantly more severe than the consequences of a successful XSS attack on a random site: the former gets you full local code execution.

OK, so what do we actually do?  We could add some sort of "linkable from extensions" flag to some subset of about: URIs (Which ones?  See my question above.) and then allow all extensions, or extensions with certain permissions, to link to those.  We would need to audit those about: URIs carefully to make sure they have no XSS vulnerabilities.  Doubly so if they're not URI_SAFE_FOR_UNTRUSTED_CONTENT.

But in general, I'm not a huge fan of this for two reasons.  First, which things are about: vs chrome:// is a pretty arbitrary distinction.  Why do extensions need to open about: URIs but not chrome:// URIs?  Or do they need to open the latter too?  Second, the fact that an about: URI is how one gets to some functionality is totally an implementation detail that we may want to change.  about:preferences used to not exist, and may stop existing again.  about:addons may stop existing.  We don't really want extensions to depend on these implementation details if we can avoid it, in my opinion; it would be better if we found out what their actual use cases are and added explicit APIs for those.
Flags: needinfo?(bzbarsky) → needinfo?(adam)
Maybe the link in comment 0 was supposed to be to https://mail.mozilla.org/pipermail/dev-addons/2016-May/000609.html

If so, that's talking about loading about:reader, which is at least URI_SAFE_FOR_UNTRUSTED_CONTENT.  I would be OK with making it linkable from all extensions (and probably doing the same for all URI_SAFE_FOR_UNTRUSTED_CONTENT) about: URLs.  That does not solve the about:addons problem, of course.  Also, the approach suggested in that mail presupposes that the way one loads reader mode is by loading "about:reader?url=stuff", which is relying on an internal implementation detail of reader mode that may be subject to change, as I noted above.

Comment 20

a year ago
> We don't really want extensions to depend on these implementation details if we can avoid it, in my opinion; it would be better if we found out what their actual use cases are and added explicit APIs for those.

For Vimium-ff, we have our own address/search bar. This has worked fine on Chrome for years, even on privileged URLs, but we keep getting user reports that about:addons, etc. and bookmarklets (javascript:...) don't work in Firefox. As nice as it is to have APIs for everything, it's frustrating for us and the users that we can't open URLs they've specifically requested.

Comment 21

a year ago
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #18)
> My first question is actually what the initial motivating use case is.  The
> link in comment 0 seems to go to a thread that has nothing to do with this
> bug.

I believe https://bugzilla.mozilla.org/show_bug.cgi?id=1356251 is the motivating case.
mrmr1993, thank you.  That is useful information.  I don't understand why the decision was made to block javascript: offhand, actually.

Ed, thank you as well.  That is a useful usecase to keep in mind.

Note that both of these use cases would be addressed by allowing load of bare "about:foo" URIs without query parameters, which would mitigate XSS concerns, but not address the "about:reader?url=stuff" usecase mentioned above....
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #18)
> 1)  It's not clear to me why the thing described in bug 1227462 is a
> problem.  It's not a problem on the web.  Are we doing those loads with a
> triggering principal that doesn't correspond to the relevant extension (e.g.
> system principal), or something?  If so, _that_ seems like something we
> should fix in general, no?

At the time, data: URIs inherited principals, so if they were loaded into a tab
with an existing page loaded, they would inherit that principal. We could have
allowed the load and disabled principal inheritance instead, but the semantics
would have gotten pretty muddy.

At this point, we really just need to use the appropriate triggering principal
for the load, and make sure that that's the principal that gets inherited.

> 3)  The fundamental premise of this bug (that about: URIs are
> "semi-privileged") is false.  The only actual URI mentioned in this bug as
> something extensions want to load is about:addons, which is
> system-privileged.

Dan's original use case was view-source: URIs, which have weird semantics, and I
was considering semi-privileged.

> 4)  The real problem is that this _is_ an XSS problem.  On the web, the
> responsibility for hardening against XSS injection attacks of various sorts
> basically falls on the target site.  The browser prevents direct scripting,
> but if the attacker can inject content of their choice into your site,
> that's your problem.  We do provide some tools like CSP to help avoid this
> problem, of course.  In the context of about: pages, we have historically
> had an additional mitigation that the web at large does not have: we simply
> prevent arbitrary loads of the about: page from untrusted content.  This
> reduces the XSS attack surface quite significantly, and allows us to not
> have to deal with carefully auditing all the bits of those about: pages. 
> Which we have not done, by the way.
> 
> Additionally, the consequences of a successful XSS attack on a privileged
> about: page are significantly more severe than the consequences of a
> successful XSS attack on a random site: the former gets you full local code
> execution.

We also have a long history of assuming that, since arbitrary web content can't
load privileged URLs, the data in their query/hash parameters can be trusted. I
don't want to make any bets that there aren't any places where we don't sanitize
that data, or take actions based on it. There have definitely been exploits of
extension URLs that take action based on their query parameters in the past.

> OK, so what do we actually do?  We could add some sort of "linkable from

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #22)
> mrmr1993, thank you.  That is useful information.  I don't understand why
> the decision was made to block javascript: offhand, actually.

Because javascript: URLs inherit the principal of the page they're loaded into,
which the extension may not have permission for. And if we load with principal
inheritance disabled, there's not much point in loading javascript: URLs at all.
> so if they were loaded into a tab with an existing page loaded, they would inherit that principal.

Only if the caller either passed system as triggering principal or passed no triggering principal.  Either behavior would be a bug in the caller, in my opinion....

> we really just need to use the appropriate triggering principal for the load, and make
> sure that that's the principal that gets inherited.

Yes, agreed!

> Dan's original use case was view-source: URIs

OK, that's not what comment 0 is about, and this is the first mention of view-source: in this bug.  ;)

I think there should be no issue at all with allowing webextensions to load view-source: urls.

> We also have a long history of assuming that, since arbitrary web content can't
> load privileged URLs, the data in their query/hash parameters can be trusted. 

Right, exactly.

> Because javascript: URLs inherit the principal of the page they're loaded into,

Again, only if there is no triggering principal passed, right?  If there's a triggering principal passed they inherit that, and just don't run if that doesn't subsume the principal of the page they're being loaded into.

This is just like the data: issue: it "simply" requires getting the triggering principal right.
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #24)
> OK, that's not what comment 0 is about, and this is the first mention of
> view-source: in this bug.  ;)
> 
> I think there should be no issue at all with allowing webextensions to load
> view-source: urls.

Those got handled separately in bug 1261289.  The patch there did in fact add a URI_LOADABLE_BY_EXTENSIONS flag, though that flag applies to protocol handlers, not about: modules so its not directly useful here.

From comment 22, do I understand that you believe it would be safe to allow extensions to open "bare" about: urls (ie no query string and perhaps no hash reference?)  Or that would only be safe after marking individual about modules safe based on an audit?

Note that we've already done separate work to handle the specific about:reader case in bug 1408993 and we can do additional similar features if necessary, but at least for the simple cases the vimium use case seems compelling and like something we ought to be able to handle...
(Reporter)

Comment 26

a year ago
bz -- you tagged me with ni?, but I don't see a question directed at me here. What information would you like me to provide?
Flags: needinfo?(bzbarsky)

Comment 27

a year ago
> which about URIs?

Hopefully all of them!

But these are most important: addons, downloads, config, debugging, robots

---

The motivation is mostly from add-ons that wish to provide an alternative UI to firefox, generally something inspired by Vim (Vimium, vimperator, vim-fx).

It's important for vim-like-UIs' UX that users can do everything they want to from the UI we implement. If users have to fall-back to a UI that they've deliberately tried to replace or augment, that's confusing.

:aswan's suggestion would suit this use-case reasonably well (users won't be able to paste in about: URIs with get parameters, but I've never had cause to do that).

There are similar bugs that the same reasons apply to for most of the classes of URI that firefox forbids webextensions to set tabs to:

about: here
file: Bug 1266960
data: Bug 1317166 (can already open data URLs with window.location.href from content scripts)
chrome: no bug yet
> but I don't see a question directed at me here.

The question was what the link in comment 0 was supposed to be, because the link actually there has nothing to do with this bug.
Flags: needinfo?(bzbarsky)
> do I understand that you believe it would be safe to allow extensions to open "bare" about: urls
> (ie no query string and perhaps no hash reference?) 

I believe it would be easier to prove it safe than it would be to prove arbitrary parameters safe.  We would still need to audit some to make sure it's OK.

Since we have a URI_LOADABLE_BY_EXTENSIONS mechanism already, by the way, we could reuse it here.  nsAboutProtocolHandler implements nsIProtocolHandlerWithDynamicFlags already, so we could do whatever examining of the URIs we want, possibly informed by additional about module flags we add.

> but at least for the simple cases the vimium use case seems compelling and
> like something we ought to be able to handle

Yes, I agree, for the set of about: URIs that we want people navigating to manually.  Which is perhaps not all of them.

> But these are most important: addons, downloads, config, debugging, robots

I should note that about:downloads is an implementation detail of how we show downloads in private windows, and is not something that's guaranteed to keep existing, to work in non-private windows, etc...  Furthermore, it has actual UI to get to it in the case when it's supposed to work... (and yes, I know that's the UI vim-like things are trying to avoid).  Of course I agree that about:config and about:debugging are basically the only entrypoints to those pieces of UI.  And I have no objection in principle to exposing things like about:downloads as long as people understand that it could disappear at any time, I guess.

One fundamental problem with all this, of course, is that we are trying to not give webextensions full system privileges, which means we have to guard against anything that could lead to them escalating to full system access...  That means that we can't necessarily allow them to do everything the normal Firefox UI can do, because in security terms we trust the Firefox UI but not webextensions.  :(

Anyway, I think getting to the point where we're fairly confident that we can allow "about:something" for arbitrary "something" without query params or anchors is doable.
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #29)
> I should note that about:downloads is an implementation detail of how we
> show downloads in private windows, and is not something that's guaranteed to
> keep existing, to work in non-private windows, etc...  Furthermore, it has
> actual UI to get to it in the case when it's supposed to work...

For that matter, about:addons is also an implementation detail, with UI and a keyboard shortcut to get to it. Initially, we even hid the location bar whenever it was open. Arguably, it's not likely to stop working any time soon, and a lot of people probably use the URL as the primary way that they open it...

But I still don't want add-ons to start relying on the URL as a way to open the add-on manager. Same for the downloads manager. We have logic to try to re-use existing about:addons tabs and about:downloads tabs if they exist, and it's entirely possible that we may move to some other, non-tab-content UI for it in the future. (For which reasons we have separate bugs for adding actual APIs for opening built-in UIs like these)

Comment 31

a year ago
I don't think add=ons should rely on the URL either, but users will want to type `about:addons` into their address bar and have whatever firefox would do happen.

If it's not a security risk and the other API is visible and recommended, what's the problem?

But the UX is fine with either one of the APIs: if I can't really tabs.create about:addons, I'll just alias attempts to do that to the other API call (ui.addonsPage()?).

> That means that we can't necessarily allow them to do everything the normal Firefox UI can do, because in security terms we trust the Firefox UI but not webextensions.  :(

I understand that you're trying to maintain a sandbox around webextensions; I'm just trying to make sure it can fit a big V in it :)
(Reporter)

Comment 32

a year ago
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #28)
> > but I don't see a question directed at me here.
> 
> The question was what the link in comment 0 was supposed to be, because the
> link actually there has nothing to do with this bug.

Ah, yes. You found the right one. It appears that a message must have been removed from the archive, resulting in a message renumbering. That seems like rather unfortunate behavior -- I thought pipermail links were intended to be stable.

The message I was referring to is now at https://mail.mozilla.org/pipermail/dev-addons/2016-May/000609.html -- given that it has moved once already, I have no idea how long that will be true.
Flags: needinfo?(adam)
(In reply to Adam Roach [:abr] from comment #32)
> The message I was referring to is now at
> https://mail.mozilla.org/pipermail/dev-addons/2016-May/000609.html -- given
> that it has moved once already, I have no idea how long that will be true.

Permalink: http://web.archive.org/web/20171028045057/https://mail.mozilla.org/pipermail/dev-addons/2016-May/000609.html
Duplicate of this bug: 1412498
> But these are most important: addons, downloads, config, debugging, robots

Not to forget about:newtab. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1371793#c8 for the use case.
about:newtab is one that we definitely should *not* allow. Tabs open with the appropriate new tab page automatically. about:newtab is an implementation detail, and should never be used directly.

Comment 37

a year ago
Again, from the Vimium side, we have users typing about:newtab to reach their top pages (when they've configured our open new tab command to open a different page). Implementation detail or not, it sucks when users ask us to open a page and we can't.
There *needs* to be a way to open the default new tab page or how the use case should be handled? It doesn't matter if I have to call it "about:newtab" in my add-on or if there will be a method to get the default new tab page, the point is that a way is needed to open the new tab page. I see no reasons in comment 36 why it should not be possible to open this page. So please don't say "we definitely should *not* allow" if there are no good reasons to forbid this…

It's by the way very annoying. In bug 1371793 it was said by Andy "Seems reasonable to me", then it was said in bug 1411647 this bug should be the way forward "so hopefully we'll come up with something that will help" and now we have the same discussion again…
Duplicate of this bug: 1371793
> but users will want to type `about:addons` into their address bar and have whatever firefox would
> do happen.

Right.  I strongly suspect allowing that particular string is not a problem.

> If it's not a security risk and the other API is visible and recommended,
> what's the problem?

There isn't one, _if_ we can prove "it" (whatever "it" is) is not a security risk.

I do think that any about: URI we suggest users type themselves is not a security risk pretty much by definition, if we disallow query and ref bits.

For what it's worth, I think marking things as duplicate of this bug is a _really_ bad idea, because we haven't even decide what this bug is going to be "about" anyway.  All those duplicates should be dependencies, and once this bug is fixed we should reevaluate them all to see whether they are then fixed or whether they need more work.
So to be clear, the approach here would be to create a new flag in nsIAboutModule and then add code here to map that flag to nsIProtocolHandler::LOADABLE_BY_EXTENSIONS?
http://searchfox.org/mozilla-central/rev/1ebd2eff44617df3b82eea7d2f3ca1b60cc591a0/netwerk/protocol/about/nsAboutProtocolHandler.cpp#75
And I presume this would also be the place where we would enforce the "without querying strings or anchors" restriction.

Then we create separate dependent bugs for each individual about: page we want to make available and we do the individual audits and bikeshedding about whether to expose them at all in those bugs?
That seems like a viable path forward, yes.

Updated

a year ago
Duplicate of this bug: 1412498

Updated

a year ago
Blocks: 1412498
Some quick context: I'm trying to migrate my extension https://addons.mozilla.org/en-US/firefox/addon/auto-reader-view/ to the WebExtensions API and have run into this issue. This extension allows users to enable automatic switching to reader view for domains of their choosing. I've implemented this by essentially updating the URL to about:reader?url=CURRENT_URL when the user is on a stored domain. This no longer works as I get an "Illegal URL" error when calling browser.tabs.update.

Are there any plans to allow setting a "about:reader?url=stuff" using the WebExtensions API? I'm not sure I understand the security concerns...if access to these types of urls is exposed as an extra permission then a user would be aware of the extension's additional privileges at install time and would make a decision about whether to trust it or not. 

If access to "about:reader" is blocked then how about a reader API to enable reader view programmatically?

Comment 45

a year ago
> reader API to enable reader view programmatically

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/toggleReaderMode

tabs.onUpdated also has changeInfo.isArticle (undocumented).

Updated

a year ago
Flags: needinfo?(amckay)

Comment 46

a year ago
I'd like a webextension to load about:downloads in a tab
thanks.

Comment 47

a year ago
Note that the ability to open a tab in reader mode was added in bug 1381992. I think at this point the best bet is to file bugs for each of the tabs (eg: tabs -> about:downloads) and windows (eg: tools -> downloads) we want to open as seperate bugs and block to this (I think some of those already exist). 

Then they can be evaluated on a case by case basis.
Flags: needinfo?(amckay)

Updated

a year ago
Keywords: meta

Comment 48

a year ago
Hi, as requested I have submitted bug 1420105 for about:downloads.

Updated

a year ago
Duplicate of this bug: 1418022

Updated

a year ago
Depends on: 1420405

Updated

a year ago
Blocks: 1420406

Updated

a year ago
No longer blocks: 1420406
Depends on: 1420406

Comment 50

a year ago
I've opened a couple of dependent bugs, but I don't see why we can't just allow any about:* URL so long as it doesn't have any anchor or query strings. What possible attacks are thought possible? DoS, maybe, but extensions can already do that.

We're not passing any user input to these pages, we're just opening them. And the use case described above for UI-replacement add-ons is solid for any about page: I don't want to have to use different open page mechanisms for different pages.

Boris says: "I do think that any about: URI we suggest users type themselves is not a security risk pretty much by definition, if we disallow query and ref bits."

Can we at least fast stream config, debugging, healthreport, profiles, support?
(In reply to Colin Caine from comment #50)
> I've opened a couple of dependent bugs, but I don't see why we can't just
> allow any about:* URL so long as it doesn't have any anchor or query
> strings. What possible attacks are thought possible?

Most about:* pages are privileged. If there is a vulnerability in these pages and an extension can open such pages without limitations, then that can result in security bugs. One year ago, there was such a bug in Chrome: https://crbug.com/668653

In Chrome it used to be possible to crash the browser by opening a certain debugging URL. The solution was to blacklist debugging URLs...

Another issue that I see quite often is extensions that call tabs.create or tabs.update without sanitizing the input. If powerful URLs are allowed by default in the tabs.create/update APIs, then the impact of having installed such a badly coded extension is more severe.


So allowing "about:*" without permissions should be out of the question.
Allowing a subset of "about:*" should be OK, especially if there are extra permissions for the more powerful URLs (including query string/reference fragment).

Comment 52

a year ago
> One year ago, there was such a bug in Chrome: https://crbug.com/668653

That bug requires the passing of a variable. I am specifically asking about being able to open the page without passing query or anchor parts, so that doesn't apply here.

If the page cannot receive input from extensions it's going to be tricky to do a XSS attack.

> In Chrome it used to be possible to crash the browser by opening a certain debugging URL.

Does the WebExtension API seek to prevent DoS attacks (here meaning Denial of the service of using firefox)? Because I'm pretty sure I can ruin a user's experience of firefox from extension code pretty easily and that this is not possible to fix at an API level.

> call tabs.create or tabs.update without sanitizing the input

I am specifically requesting that only URLs without query or anchor parts be permitted. There is no sanitization issue if that is done.
(In reply to Colin Caine from comment #52)
> > One year ago, there was such a bug in Chrome: https://crbug.com/668653
> 
> That bug requires the passing of a variable. I am specifically asking about
> being able to open the page without passing query or anchor parts, so that
> doesn't apply here.

The bug does not require any variable. Merely opening "chrome://downloads" was sufficient (you can watch the attached video if you don't want to read the full report).

(I consider "about:downloads" to be a reasonable URL to whitelist given its legitimate use cases though.)
(In reply to Colin Caine from comment #50)
> Can we at least fast stream config, debugging, healthreport, profiles,
> support?

The work from comment 41 still needs to be done first.  I don't really care if that happens in this bug or a new bug gets opened for it but I don't think anybody from the mozilla side has time to work in this during the 59 cycle.  I'd be happy to help get patches from a volunteer contributor reviewed and landed though.
Blocks: 1420405
No longer depends on: 1420405
Blocks: 1420105

Updated

8 months ago
Product: Toolkit → WebExtensions

Updated

8 months ago
See Also: → bug 1468191
You need to log in before you can comment on or make changes to this bug.