Use a protocol not accessible from content

NEW
Unassigned

Status

Add-on SDK
General
P3
normal
5 years ago
6 months ago

People

(Reporter: ochameau, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {privacy})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fingerprinting], URL)

(Reporter)

Description

5 years ago
As reported by Jorge, some hackers exposed ways to detect which addons are installed by loading resource:// URIs.
And as all jetpack addons use these URIs it make them a bit more unsafe.
We should use another protocol which would prevent that by disallowing loading it from content.
(Reporter)

Comment 1

5 years ago
We already discussed about new protocol specific to addon content in bug 644595,
as part of Addon Page API.
(Reporter)

Comment 2

5 years ago
Blackhat hack description:
https://media.blackhat.com/bh-us-12/Briefings/Fleischer/BH_US_12_Fleischer_Implementing_Web_Tracking_gfleischer_WP.pdf

Updated

5 years ago
Priority: -- → P1
Do we have any more details on how he detected add-ons in this way? The paper is pretty short on details and I want to test if the fix I have solves it or not.
Assignee: nobody → dtownsend+bugmail
Nevermind, I found something that works.

I recommend we don't land this before implementing bug 820213 for people who actually want to inject content into content
Depends on: 820213
We could use an approach that I used in Scriptish to block requests to an add-on's resource: uri if the request comes from page that is not a chrome or resource uri.

https://github.com/scriptish/scriptish/blob/master/extension/components/scriptish.js#L192-L198

I think we could even block requests to the internal directories via its resource: uri from outside the add-on.
Depends on: 852297
Flags: needinfo?(dtownsend+bugmail)
I have an example of the issue on https://github.com/scriptish/scriptish/wiki/FAQ:-What-are-the-security-benefits-over-Greasemonkey%3F in the 'Stealth' section.
(In reply to Erik Vold [:erikvold] [:ztatic] from comment #5)
> We could use an approach that I used in Scriptish to block requests to an
> add-on's resource: uri if the request comes from page that is not a chrome
> or resource uri.
> 
> https://github.com/scriptish/scriptish/blob/master/extension/components/
> scriptish.js#L192-L198
> 
> I think we could even block requests to the internal directories via its
> resource: uri from outside the add-on.

It's a solution, but it adds a lot of work (every add-on with its own content policy for every url access from every page!) that can be avoided with a custom protocol. I should have a proof of concept up in the next few days.
Flags: needinfo?(dtownsend+bugmail)

Updated

4 years ago
Keywords: privacy
Summary: Use protocol not accessible from content → Use a protocol not accessible from content
Whiteboard: [fingerprinting]
Assignee: dtownsend+bugmail → nobody

Updated

a year ago
Priority: P1 → --

Updated

7 months ago
Blocks: 1329996

Updated

6 months ago
Priority: -- → P3
See Also: → bug 863246
You need to log in before you can comment on or make changes to this bug.