1073863 - spoofing risks in social activation doorhanger

Status: VERIFIED FIXED

(Firefox Graveyard :: SocialAPI, defect)

Description

[Daniel Veditz [:dveditz]]

The social activation doorhanger embeds page content in the middle of a sentence, a known spoofing risk. In English the prompt reads

   Would you like to enable services from <name> to display
   in your <ShortBrand> toolbar and sidebar?

In bug 1029942 comment 27 Shane notes that we already use the name in a number of places such as menu items and in about:addons. However those are contexts where the name stands alone. Embedded in a sentence this allows a malicious page to get creative and use the sentence structure to endow authority or mislead about who's asking. E.g.:

   Would you like to enable services from <Mozilla that prevent
   websites from tracking you, and> to display in your
   <ShortBrand> toolbar and sidebar?

Not great (Nigerian-spam quality grammar; I'm sure Jesse could come up with something better) but I hope that gives a taste of what's possible. Keep web-supplied values contextually separate from the prompt (Bonus: this is easier for localization, too).

Off the top of my head (i.e. plenty of room for improvement):

  This website offers enhanced services that can display
  in your <ShortBrand> toolbar and sidebar. Would you like
  to enable them?

  Service: <name>
  Homepage: <url>

That brings us to the second problem: Website A can claim to be installing services for B while actually installing services for C. By not showing the URL for which we're adding the service we've created a phisher's dream. For example: from our activation site (mozilla.net) I installed what the site /said/ was GMail. Since I often flush my cookied the first thing that happened when I clicked on the "Share" button was a panel claiming to be google in web content wanting me to give it my password. I have no idea whether what got installed was GMail, and having installed it I have no idea who was really behind that password prompt.

OK, so everyone trusts Mozilla and we're not going to do anything evil from our activation page -- it's probably the real GMail. But what about some other random page? If I'm on trusted Foo.com and it asks to install services for itself I can probably trust that, too -- why would they lie? Unless, of course, they were hacked or I'm on an insecure (http) connection to it. But if I'm on some "fan" site for a service the average user has no way to know whether it's an evil fan or not.

Gotta show the origin somewhere.

(and of course when you show the origin watch out for scumbags who create really long domains hoping bits get truncated: www.facebook.com.social.I.hope.this.is.cut.off.evil.com. eTLD+1 can be misleading, but if bits get truncated it might be safer than the truncation. If you do truncate, chop from the front not the middle.)

But then we might show the "homepage" field, and it might not match the actual service origins. Does the API force the important URLs to be same-origin? The Icons probably don't matter (or at least we should make an exception to allow data:) but the services should match the homepage. Or the services should match each other, and we show /that/ origin on the dialog, saving the homepage field for the addons manager.

Comment 1

[Shane Caraveo (:mixedpuppy)]

(In reply to Daniel Veditz [:dveditz] from comment #0)

> Off the top of my head (i.e. plenty of room for improvement):
> 
>   This website offers enhanced services that can display
>   in your <ShortBrand> toolbar and sidebar. Would you like
>   to enable them?
> 
>   Service: <name>
>   Homepage: <url>


That's a fine change to do for 35, but not upliftable due to strings.  

For pre-35;

We can revert to using the install origin (upliftable), but that is a bit misleading since on directory sites it will show an origin different than the service. e.g. installing gmail from mozilla.net would show: "Would you like to enable services from activations.cdn.mozilla.net to display in your <ShortBrand> toolbar and sidebar?"

Or, I could use the manifest origin, which is a) origin of manifest data if not installing from a directory (set in firefox), or b) controlled by whoever controls the directory.  With the current text, installing gmail from mozilla.net would show: "Would you like to enable services from mail.google.com to display in your <ShortBrand> toolbar and sidebar?"

> That brings us to the second problem: Website A can claim to be installing
> services for B while actually installing services for C. By not showing the
> URL for which we're adding the service we've created a phisher's dream. For
> example: from our activation site (mozilla.net) I installed what the site
> /said/ was GMail. Since I often flush my cookied the first thing that
> happened when I clicked on the "Share" button was a panel claiming to be
> google in web content wanting me to give it my password. I have no idea
> whether what got installed was GMail, and having installed it I have no idea
> who was really behind that password prompt.

maybe we show the url much like hover over links in normal tabs shows it?  Would be easy to do (I hope)

> Does the API force the important URLs to be
> same-origin? 

no, only the origin field is validated to be the origin of the manifest data (if installed from any site, installed from a directory the directory can set it).  Some services have an install origin different than some of the urls used (e.g. weibo is a mobile site for the sidebar, m.weibo.cn, but the share panel is on services.weibo.com)

Comment 2

[Shane Caraveo (:mixedpuppy)]

Attachment: use manifest origin rather than name

The origin is added by Firefox if it is a "foreign" install.  If it is an install from the configured directory (social.directories pref) then the directory sets the manifest origin.

This patch can be uplifted since it doesn't change any strings.

Comment 3

[Daniel Veditz [:dveditz]]

Under the constraint of not tweaking localizations that WFM. It does solve the spoofing problem.

Comment 4

[Mark Hammond [:markh] [:mhammond]]

Comment on attachment 8496477 [details] [diff] [review]
use manifest origin rather than name

Review of attachment 8496477 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM - are we using another bug for the more substantial changes we want in 35+?

Comment 5

[Shane Caraveo (:mixedpuppy)]

bug 1075251 for a better ux on showing the url loaded into the panel
bug 1075254 for improvements to the activation panel

Comment 6

[Shane Caraveo (:mixedpuppy)]

https://hg.mozilla.org/integration/fx-team/rev/0204f2429e77

Comment 7

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8496477 [details] [diff] [review]
use manifest origin rather than name

Going away on PTO, so requesting this a tad early...

Approval Request Comment
[Feature/regressing bug #]: 1029942
[User impact if declined]: possible to spoof provider name
[Describe test coverage new/current, TBPL]: existing tests
[Risks and why]: low
[String/UUID change made/needed]: none

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0204f2429e77

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4ff49aa32213
https://hg.mozilla.org/releases/mozilla-beta/rev/6326278b28ac

Comment 10

[Kamil Jozwiak [:kjozwiak]]

I reproduced the original problem that Dan mentioned in comment #0 with the following build:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-09-27-03-02-04-mozilla-central/

Once the above build was installed, I received the social activation doorhanger from the following services:

Before fix: goal.com, gmail, google+, twitter
After fix: www.goal.com, mail.google.com, plus.google.com, twitter.com

Tested using the following OS's:
- Win 8.1 x64 (VM) - PASSED
- Ubuntu 14.0.4.1 x64 (VM) - PASSED
- OSX 10.9.5 x64 - PASSED

fx35:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-10-08-03-02-02-mozilla-central/

fx34:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-10-08-00-40-04-mozilla-aurora/

fx33:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/33.0-candidates/build1/

Test Cases:

- ensured that the "learn more..." button is working correctly
- ensured that the <install origin> is being used rather than <name>
- ensured that the <ShortBrand> correctly listed the correct channel
- ensured that clicking on the "cloud" in the URL bar correctly display's the social activation doorhanger
- ensured that selecting "Enable" enables the service without any issues
- ensured that the service is being listed under about:addons -> services