#121 web_accessible_resources and UUID leaking

Closed
opened 7 months ago by 12bytes.org · 5 comments

i was just doing some long overdue reading on how extensions (and in turn the browser) can be fingerprinted and i see that if an ext. uses "web_accessible_resources" (and JS is enabled), it's possible to get the UUID of the ext.

in the LCDN manifest i'm seeing "web_accessible_resources" and i'd just like to get your take on whether it may be affected by this

Bug 1405971

i was just doing some long overdue reading on how extensions (and in turn the browser) can be fingerprinted and i see that if an ext. uses "web_accessible_resources" (and JS is enabled), it's possible to get the UUID of the ext. in the LCDN manifest i'm seeing "web_accessible_resources" and i'd just like to get your take on whether it may be affected by this [Bug 1405971](https://bugzilla.mozilla.org/show_bug.cgi?id=1405971)
nobody added the
question/discussion
label 7 months ago
nobody commented 7 months ago
Owner

The option web_accessible_resources is limited to the directory resources in LocalCDN. A simple XMLHttpRequest request to moz-extension://[UUID]/manifest.json fails, but moz-extension://[UUID]/resources/algoliasearch/3.35.1/algoliasearch.min.jsm works.

The resources in this directory should later be injected into a web page. At the moment this is unfortunately not a one-way street.

The UUID cannot be extracted, so you have to try to get an exact fingerprint. There are many possible combinations, so I don't know if a website does this.

Extensions can't prevent that as far as I know. I'll close this issue because it's not a problem with LocalCDN, but we can still write here.

The option `web_accessible_resources` is limited to the directory `resources` in LocalCDN. A simple XMLHttpRequest request to `moz-extension://[UUID]/manifest.json` fails, but `moz-extension://[UUID]/resources/algoliasearch/3.35.1/algoliasearch.min.jsm` works. The resources in this directory should later be injected into a web page. At the moment this is unfortunately not a one-way street. The UUID cannot be extracted, so you have to try to get an exact fingerprint. There are many possible combinations, so I don't know if a website does this. Extensions can't prevent that as far as I know. I'll close this issue because it's not a problem with LocalCDN, but we can still write here.
nobody closed this issue 7 months ago
Poster

Extensions can’t prevent that as far as I know.

i'm totally NOT well versed in this, nor do i do JS, but my impression is that the UUID leak can be prevented by the extension - here's some more info

> Extensions can’t prevent that as far as I know. i'm totally NOT well versed in this, nor do i do JS, but my impression is that the UUID leak can be prevented by the extension - [here's some more info](https://github.com/soufianesakhi/firefox-search-engines-helper/issues/15#issuecomment-699635063)
nobody commented 7 months ago
Owner

Thanks for the link. Yes, if you don’t need to deliver resources to a website, you can remove web_accessible_resources from manifest.json. This is what is meant and the developer of CRX Viewer did. There web_accessible_resources isn’t needed and can be removed. It makes sense to remove as many extensions as possible if you don’t need web_accessible_resources, to reduce the possible hits.

If I remove web_accessible_resources from manifest.json of LocalCDN, no resources can be replaced. You can check this by installing LocalCDN as a temporary extension and removing the section web_accessible_resources from manifest.json. (I attached this at the bottom)

Basically the topic isn’t new. This discussion exists since about 3 years. I thought about it some weeks or months ago, but unfortunately e.g. blocking requests for moz extension:// doesn’t work.

Mozilla’s description:

Sometimes you want to package resources—for example, images, HTML, CSS, or JavaScript—with your extension and make them available to web pages.

and maybe important

In Chrome, an extension’s ID is fixed. When a resource is listed in web_accessible_resources, it is accessible as chrome-extension://<your-extension-id>/<path/to/resource>.

When I think about it, I guess it's more relevant for Chromium users because the UUID is fixed, if that's still true.

I think it's very difficult to implement that. A few thoughts on this: You have to try different UUIDs with JavaScript on the client side. The UUIDs have 32 digits (without the dashes) and can contain the characters [a-z] and [0-9]. That means there are 36^32 possible combinations (63,340,286,662,973,277,706,162,286,946,811,886,609,896,461,828,096). Trying out the UUIDs should be stopped if you navigate somewhere else inside the page.

{
  "manifest_version": 2,
  "name": "LocalCDN",
  "version": "2.5.1",
  "browser_specific_settings": {
    "gecko": {
      "id": "{b86e4813-687a-43e6-ab65-0bde4ab75758}",
      "strict_min_version": "63.0"
    }
  },
  "author": "nobody",

  "default_locale": "en_US",

  "description": "__MSG_extensionDescription__",
  "icons": {
    "16": "icons/icon16.png",
    "48": "icons/icon48.png",
    "96": "icons/icon96.png",
    "128": "icons/icon128.png"
  },

  "permissions": [
    "*://*/*",
    "privacy",
    "storage",
    "unlimitedStorage",
    "tabs",
    "webNavigation",
    "webRequest",
    "webRequestBlocking"
  ],

  "background": {
    "page": "pages/background/background.html"
  },

  "browser_action": {
    "default_icon": {
      "16": "icons/action/default/icon16-default.png",
      "18": "icons/action/default/icon18-default.png",
      "19": "icons/action/default/icon19-default.png",
      "32": "icons/action/default/icon32-default.png",
      "36": "icons/action/default/icon36-default.png",
      "38": "icons/action/default/icon38-default.png",
      "64": "icons/action/default/icon64-default.png"
    },
    "default_popup": "pages/popup/popup.html",
    "browser_style": false
  },

  "options_ui": {
    "page": "pages/options/options.html",
    "open_in_tab": true
  }
}
Thanks for the link. Yes, if you don’t need to deliver resources to a website, you can remove `web_accessible_resources` from `manifest.json`. This is what is meant and [the developer of CRX Viewer](https://github.com/Rob--W/crxviewer/issues/100#issuecomment-699621760) did. There `web_accessible_resources` isn’t needed and can be removed. It makes sense to remove as many extensions as possible if you don’t need `web_accessible_resources`, to reduce the possible hits. If I remove `web_accessible_resources` from `manifest.json` of LocalCDN, no resources can be replaced. You can check this by installing LocalCDN as a [temporary extension](https://codeberg.org/nobody/LocalCDN/wiki/Running-the-code-as-temporary-extension) and removing the section `web_accessible_resources` from `manifest.json`. (I attached this at the bottom) Basically the topic isn’t new. This discussion exists since about 3 years. I thought about it some weeks or months ago, but unfortunately e.g. blocking requests for `moz extension://` doesn’t work. [Mozilla’s description](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/web_accessible_resources): > Sometimes you want to package resources—for example, images, HTML, CSS, or JavaScript—with your extension and make them available to web pages. and maybe important > In Chrome, an extension’s ID is fixed. When a resource is listed in `web_accessible_resources`, it is accessible as `chrome-extension://<your-extension-id>/<path/to/resource>`. When I think about it, I guess it's more relevant for Chromium users because the UUID is fixed, if that's still true. I think it's very difficult to implement that. A few thoughts on this: You have to try different UUIDs with JavaScript on the client side. The UUIDs have 32 digits (without the dashes) and can contain the characters [a-z] and [0-9]. That means there are 36^32 possible combinations (`63,340,286,662,973,277,706,162,286,946,811,886,609,896,461,828,096`). Trying out the UUIDs should be stopped if you navigate somewhere else inside the page. ``` { "manifest_version": 2, "name": "LocalCDN", "version": "2.5.1", "browser_specific_settings": { "gecko": { "id": "{b86e4813-687a-43e6-ab65-0bde4ab75758}", "strict_min_version": "63.0" } }, "author": "nobody", "default_locale": "en_US", "description": "__MSG_extensionDescription__", "icons": { "16": "icons/icon16.png", "48": "icons/icon48.png", "96": "icons/icon96.png", "128": "icons/icon128.png" }, "permissions": [ "*://*/*", "privacy", "storage", "unlimitedStorage", "tabs", "webNavigation", "webRequest", "webRequestBlocking" ], "background": { "page": "pages/background/background.html" }, "browser_action": { "default_icon": { "16": "icons/action/default/icon16-default.png", "18": "icons/action/default/icon18-default.png", "19": "icons/action/default/icon19-default.png", "32": "icons/action/default/icon32-default.png", "36": "icons/action/default/icon36-default.png", "38": "icons/action/default/icon38-default.png", "64": "icons/action/default/icon64-default.png" }, "default_popup": "pages/popup/popup.html", "browser_style": false }, "options_ui": { "page": "pages/options/options.html", "open_in_tab": true } } ```
Poster

so you're confirming what i thought may be the case; the site would have to enumerate all possible combos which is... just stupid

and yes, Chrome exposes a whole new level of this exploit (assuming it's not fixed), thus why Moz is assigning random UUIDs

on another topic (i didn't want to open a new issue and since this is closed and this is a rather trivial question)...

other than a performance boost (loading speed), is there any advantage to using LCDN when both FPI and RFP are enabled, and we're dumping storage at tab close (or browser close) (Cookies AutoDelete in my case)?

i get not using LCDN may (or not?) slightly comprimise privacy even with the settings mentioned, but wouldn't that be applicable only while you're visiting the host?

so you're confirming what i thought may be the case; the site would have to enumerate all possible combos which is... just stupid and yes, Chrome exposes a whole new level of this exploit (assuming it's not fixed), thus why Moz is assigning random UUIDs on another topic (i didn't want to open a new issue and since this is closed and this is a rather trivial question)... other than a performance boost (loading speed), is there any advantage to using LCDN when both FPI and RFP are enabled, and we're dumping storage at tab close (or browser close) (Cookies AutoDelete in my case)? i get not using LCDN may (or not?) slightly comprimise privacy even with the settings mentioned, but wouldn't that be applicable only while you're visiting the host?
nobody commented 7 months ago
Owner

the site would have to enumerate all possible combos which is... just stupid

Yes, there are much better and faster methods 😄

i didn’t want to open a new issue

That would not have been a problem 😉

other than a performance boost (loading speed), is there any advantage to using LCDN when both FPI and RFP are enabled, and we’re dumping storage at tab close (or browser close) (Cookies AutoDelete in my case)?

i get not using LCDN may (or not?) slightly comprimise privacy even with the settings mentioned, but wouldn’t that be applicable only while you’re visiting the host?

Yes, the IP address. Of course, the IP address is only a small part of tracking a person across multiple websites, but everything can be traced back to at least one household (except mobile networks). Especially considering that with IPv6, every device could have its own permanent IP address. However, the aim is that as less external content is loaded as possible and the site can still be used.

> the site would have to enumerate all possible combos which is... just stupid Yes, there are much better and faster methods :smile: > i didn’t want to open a new issue That would not have been a problem :wink: > other than a performance boost (loading speed), is there any advantage to using LCDN when both FPI and RFP are enabled, and we’re dumping storage at tab close (or browser close) (Cookies AutoDelete in my case)? > > i get not using LCDN may (or not?) slightly comprimise privacy even with the settings mentioned, but wouldn’t that be applicable only while you’re visiting the host? Yes, the IP address. Of course, the IP address is only a small part of tracking a person across multiple websites, but everything can be traced back to at least one household (except mobile networks). Especially considering that with IPv6, every device could have its own permanent IP address. However, the aim is that as less external content is loaded as possible and the site can still be used.
nobody added the
observation
label 5 months ago
nobody removed the
observation
label 1 month ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.