Last Comment Bug 779197 - Use a protocol not accessible from content
: Use a protocol not accessible from content
Status: NEW
[fingerprinting]
: privacy
Product: Add-on SDK
Classification: Client Software
Component: General (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://media.blackhat.com/bh-us-12/B...
Depends on: 820213 852297
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-31 10:25 PDT by Alexandre Poirot [:ochameau] PTO, back on 1st
Modified: 2016-05-09 16:24 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Alexandre Poirot [:ochameau] PTO, back on 1st 2012-07-31 10:25:20 PDT
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.
Comment 1 Alexandre Poirot [:ochameau] PTO, back on 1st 2012-07-31 15:49:13 PDT
We already discussed about new protocol specific to addon content in bug 644595,
as part of Addon Page API.
Comment 2 Alexandre Poirot [:ochameau] PTO, back on 1st 2012-08-03 09:28:01 PDT
Blackhat hack description:
https://media.blackhat.com/bh-us-12/Briefings/Fleischer/BH_US_12_Fleischer_Implementing_Web_Tracking_gfleischer_WP.pdf
Comment 3 Dave Townsend [:mossop] 2013-01-11 10:34:43 PST
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.
Comment 4 Dave Townsend [:mossop] 2013-01-11 11:57:51 PST
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
Comment 5 Erik Vold [:erikvold] (please needinfo? me) 2013-04-28 12:07:58 PDT
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.
Comment 6 Erik Vold [:erikvold] (please needinfo? me) 2013-04-28 12:11:01 PDT
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.
Comment 7 Dave Townsend [:mossop] 2013-05-17 10:37:25 PDT
(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.

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