715470 - Developers should specifiy which origins an addon can reach through XHR

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Louis-Rémi BABE]

XHR calls made from addons are privileged and can reach websites on different origins.

To mitigate the security risks implied by this possibility, the "Addons SDK" of Safari[1] and Chrome[2] require developers to specify which origins can be accessed by the plugin.

This has two security benefits:
- If the addon SDK or the addon itself ever have a security flaw that allows Web content to escalate privileges, the potential damages should be limited to the "permitted origins".
- If those "permitted origins" are specified in the addon manifest, it makes it possible to inform the user which website the addon will be given access to. This allows them to spot potentially malicious or misbehaving addons.

To make this change backward compatible, all origins should be allowed by default. This seems to defeat the first benefit listed above. But if developers are encouraged to use that feature, it should still result in an improved level of security and control for addon users.

[1] http://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/ExtensionPermissions/ExtensionPermissions.html#//apple_ref/doc/uid/TP40009977-CH8-SW4
[2] http://code.google.com/chrome/extensions/xhr.html#requesting-permission

Comment 1

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Brian/Irakli, what thoughts do you guys have on how to do this?

Comment 2

[Gabor Krizsanits (INACTIVE)]

So currently for cross origin XHR addons need to use the modules which have system principal. In the near future there will be another, simpler way for that, from content-script. For that addon developers will have to specify what origins they want to have access to, and the content-script sandbox will be created with an nsExpandedPrincipal for them, that will come with a special XHR object that allows access to these origins. Also the content-script will have same origin access to these origins.

Now on the other hand limiting the XHR object of a system principal does not make much sense to me tbh. Simply because in case of any privilage leaking the least of my worries are cross domain XHR.

I invented nsEP for this problem: Bug 734891
Landed the final blocking bits that was blocking us from using them: Bug 820170
Finally this is where you can follow the progression of the landing part: Bug 786681

One more thing is that I think I should mention that I'm planning to invent an all domain principal for some edge cases, where the user have no way of telling the list of domains he wants to have access (for example yahoo mail has some crazy server names, and this caused a problem in the past). Google also have a wild card feature to specify domains, but since it didn't work out for them very well and would be a lot of work I don't really plan to implement that.

Comment 3

[Erik Vold [:erikvold] (please needinfo? me)]

This was completed in bug 786681