Open Bug 1269456 Opened 5 years ago Updated 2 months ago

[meta] Add permission to allow extensions to load semi-privileged URLs

Categories

(WebExtensions :: Frontend, task, P3)

task

Tracking

(Not tracked)

People

(Reporter: abr, Unassigned)

References

(Depends on 2 open bugs, Blocks 6 open bugs)

Details

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

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.
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)
Whiteboard: [design-decision-needed]
Paul, the potential use case for security page permissions we discussed in a meeting.
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)
(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.
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]
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!
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
Any status on this? We need to open about:addons to fully migrate to webextensions...
thanks
(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
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...
Any other thoughts, or a status update? Is this in the works? thanks
Duplicate of this bug: 1405415
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.
> 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.
(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...
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)
> 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)
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 :)
(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.
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.
Duplicate of this bug: 1412498
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?
> 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).
Flags: needinfo?(amckay)
I'd like a webextension to load about:downloads in a tab
thanks.
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)
Keywords: meta
Hi, as requested I have submitted bug 1420105 for about:downloads.
Duplicate of this bug: 1418022
Depends on: 1420405
Blocks: 1420406
No longer blocks: 1420406
Depends on: 1420406
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).
> 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
Product: Toolkit → WebExtensions
See Also: → 1468191
Type: defect → task
Summary: Add permission to allow extensions to load semi-privileged URLs → [meta] Add permission to allow extensions to load semi-privileged URLs

long standing feature request

Flags: needinfo?(philipp)
Priority: P2 → P3

This bug has a lot of comments, but I've tried to digest them in a way that would allow me to come to a decision on this. If I understood correctly, the main ask for this bug is to make it possible for browser.tabs.create() and .update() to open tabs, or update the URL of tabs to point to about: pages. There were some concerns about parameters on about pages, that it is possible that our code would consider the content of these parameters as safe.

What I feel we should do is allow creating/updating tabs of about: pages, using a whitelist for specific pages we'd want to allow. The whitelist should be guided by pages where we feel there is a reasonable use case for opening that page. A few requirements:

  • The fact that users may type an about page in a imitated URL bar is great for those specific add-ons, but is not something that should drive the decision on which URLs to allow. If that were the case, we'd essentially have to allow all of them, which I don't think is feasible.
  • The whitelist should not include pages mainly appealing to power users. I would not want an add-on to open about:config, as it could be used as a mechanism to trick unknowing users into changing security-related preferences.
  • Add-ons must not be able to interact with the pages, as it was before. If possible we might also want to avoid allowing these pages to be framed.
  • Pages we whitelist should get a comment in their implementation code, noting that the page can be opened by an extension. This way Firefox developers are more sensitive to how the pages are opened.
  • Query parameters should be disallowed generally, though if there is a compelling use case we might want to allow them on specific pages.

To me this is not an immediate priority, if the dependent fixes serve further purposes I think that would increase the likelihood of this being implemented.

Flags: needinfo?(philipp)
Depends on: 1564571
Blocks: 1564571
No longer depends on: 1564571

Is there something I (or somebody else) could do to make this progress in any way?

Depends on: 1538451
You need to log in before you can comment on or make changes to this bug.