Security/Tracker/SocialAPI/Threat Model

Project Info

Security Information

Threat Summary
The main categories of threats we considered were:

- Social providers could access more data than you expect
- You could share more than you intend to
- A social provider could become intrusive
- The Social API could facilitate phishing
- The Social API could be used to compromise users

Threats

1 Manifest file - what are the security requirements for entrance?
Threat

Can a website say, "click to add whateverbook," and really add a MITM site to your manifest, with legit ssl key?

Proposed Remediation
-requirements are valid SSL cert over secure channel, manifest urls must resolve to same-origin, any "install button" in the site would be tied to same-origin as well.
-Manifest data is stored in prefs

-suggest that we may move to a "if you know what you're doing..." UI at some point

Agreed Path Forward

Not a blocker for initial launch
Will revisit upon future implementation
ultimately best solution for protecting built-in prefs is at the platform level

2 Growl/Toast style ephemeral window used to spoof a system or application window
Threat

toast/growl style windows - might user trust instructions received in this window, and follow them? if so, it could be used to trick the user into doing something bad.

It was determined that this threat is not unique to SocialAPI, it would be just as true for the provider's own site.

3 Growl/Toast style ephemeral window used to DoS user's display

Threat

API ref says, for Client to user notification "these notifications may be used to trigger a variety of attention-getting interface elements, including "toast" or "Growl"-style ephemeral windows, ambient notifications (e.g. glowing, hopping, pulsing), or collections (e.g. pull-down notification panels, lists of pending events)"

Proposed Remediation

-Frequency count?
-Option to turn off ephemeral windows entirely, on a per-provider basis
-More severe: default to ephemeral windows OFF
-OSes are providing features to manage notification load: may make sense to have a product call on this. May require platform-level analysis of feature usefulness.

Agreed Path Forward

-Yes, option to turn off windows entirely
-When multiple providers are supported, tnhis will be on a per-provider basis
-Need to decide on default
- Consider that this is a provider, not mozilla problem.

4 Built-in provider functionality could be hijacked
Threat

Pollution of Manifest db with persistent XSS/Sidebar rootkit
Installation of malicious provider though add-on - Addon code runs privileged and has access to anything in the system.

Agreed Path Forward

Address primary attack point (transit) via requiring SSL for manifest access

Threat

Malicious code developed for active content types like flash and java might not play nicely inside the sidebar and hidden window
Java and Flash are the top two browser exploit vectors
flash, java applets, etc running inside the window will not be bound by restrictions on what Javascript can do.

Constraints
- Google needs flash for now.
-- This is not currently a concern as there is no google socialapi provider at the present time
-Flash is still common for streaming media

Agreed Path Forward

-Worker context is sandboxed with no access to plugins
-Bug 766607 for ensuring content-type is for test/plain or something like that

5 Sidebar enabled at inappropriate times
Threat

Sidebar not appropriate for all browser deployments. Some users may not want SocialAPI functionality in their browser
What about public terminals? Could users end up installing SPs on these and forgetting to uninstall them? Think kiosk mode - user might not be able to easily close the browser?

Proposed Remediation

-There should be an easy to configure preference for users to disable
-Sidebar should be disabled in kiosk mode
-A corporate IT dept should be able to disable sidebar functionality for a standard deployment, or add their own default provider
-The design intent is that going into Private Browsing mode should cause all Social objects to be unloaded. The Worker should be destroyed and all sidebar/toolbar/recommendation buttons should be destroyed.
-Our intent is that the entire system defaults to "off". We would like a social service provider to have the power to turn the feature on, for its own domain, while the user is visiting their site.
-Proposed implementation: On pages whose domain matches the URLPrefix of an installed service provider, a JS function ("activateSocialBrowsing") is enabled. Calling this function prompts the user with a "want to turn on social browsing?" panel; if selected, this enables the feature and selects the current provider. If the user declines to turn it on, we should have the option to remember this choice and not present the panel in future. turn it on, we should have the option to remember this choice and not present the panel in future.
-Possible threat: Can this window be spoofed to trick the user into opening a fake panel, enter credentials, etc?
Agreed Path Forward

-Pref to disable the feature entirely (already implemented)
-Private browsing should disable feature and unload all content (already implemented)
-There isn't really a "Kiosk Mode" flag; we should either support the most popular existing "Kiosk" addons to reach out the developers
-Action: Look at what happens when we get 404, 500, network reset on worker/sidebar request

6 Privacy threats from installed service providers - Can a service provider make malicious use of browsing data provided through this API?
Threat
- A malicious addon can do anything
Accepted Remediation
- This is a platform issue, not a SocialAPI issue

Threat

Proposed future feature - more information sharing. i.e. extracting metadata from visited pages and passing it to the Worker.
This has potential for user surveillance and tracking if used aggressively.

Proposed Remediation

For future releases, we may want to build a logging/notification system to let the user know exactly what is being shared, and when, and give the user full control over that.

Agreed Path Forward

We are not extracting or passing metadata today

7 MITM attack against active worker session with provider
Threat

User session proxied and MITM by attacker
An addon or external process need only change the proxy settings of firefox (unsigned pref settings on disk), or of the underlying OS in order to mitt the socialapi, as well as any other web content loaded into the browser.
Even if we sign our urls and somehow ensure that they are 100% unchangeable, that can occur
Once the url is set on the worker iframe, or any social content panel, there is no way to prevent any addon from simply changing that url to something else.

Remediation

-Require SSL connection to all service providers

-Agreed Path Forward

-Require SSL connection

8 MITM against sidebar content
Threat

-MITM on sidebar content? Could get at the getWorker() call, so you could spoof interactions with the sidebar.

-Proposed Remediation

-Require SSL

-Agreed Path Forward

-Require SSL, same as 7, see bug 766616 for network recovery

9 Phishing threat from spoofing the social browser UX
Threat

The user may infer a greater degree of trust from social network providers.
This could be abused for phishing attacks.
How would this work?
If an attacker can synthesize a UI that looks like the social service provider, they could drive user behavior - e.g. create a "sidebar" element that looks like chrome in order to steal to a Facebook login.
Attack surface through Notification API?

Agreed Path Forward

-Produce a strongly worded guidance document
-Make an effort to develop a visual cue, soon. bug 766622

10 Will sidebar and chat windows created through SocialAPI include webcam/audio chat support?

Threat

Worker enables webcam/mic to spy on user

'P'roposed Remediation

- Standard content-based permission management - note that doorhanger-based permission may not render correctly in pinned chat window
- Worker doesn't get access.

11 Manifest is retrieved from a local file:// uri rather than remote website
Threat

Starts a malicious js process, such as to implement a javascript portscanner and sending the results to a website. Ex <a href="http://www.gnucitizen.org/blog/attackapi/">http://www.gnucitizen.org/blog/attackapi/</a>
Builtin providers are allowed to point to file system resources via the resource scheme, which is necessary to implement the feature. They must provide an origin value, which any non-resource uris are resolved against.
Can the ability to point to local files be used to read the content of arbitrary files?

Proposed Remediation

Currently, code loaded from a manifest is sandboxed with a smaller API than what is available to normal web content in a browser tab. I suppose it would be possible to create a port scanner somehow using WebSocket, but if so then that is a platform security issue that is outside the domain of the socialapi. ** Even if the code had full access to the normal iframe content, it is still controlled by iframe content policy enforced at the platform layer.

Agreed Path Forward:
-Manifests should only be loaded from HTTPS
-Devmode exception? Okay. (put something in about:social, panel menu to remind/warn)

12 Javascript or other active content running in the initial hidden window?
Threat

We create an iframe (for each provider) on the hidden window with the src attribute set to workerURL from the providers manifest. The content retrieved is copied and eval'd in the sandbox. Can code run in the hidden window, prior to being sandboxed?
The remote code is loaded into a sandboxed content iframe without access to chrome privileges or the hidden xul window.
Not sure if this is part of the threat or remediation, I don't know enough about this part of firefox

Proposed Remediation

Ensure that only content-type that is allowed is non-DOM (proposed: application/json) bug 766607