Security/Reviews/SocialAPI

From MozillaWiki
< Security‎ | Reviews
Revision as of 15:02, 12 June 2012 by Curtisk (talk | contribs)
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Item Reviewed

Social API
Target *https://wiki.mozilla.org/Labs/SocialAPI Full Query
ID Summary Priority Status
733414 SecReview for SocialAPI -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

{{#set:SecReview name=Social API |SecReview target=*https://wiki.mozilla.org/Labs/SocialAPI

Full Query
ID Summary Priority Status
733414 SecReview for SocialAPI -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

}}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

The Social Browsing feature adds a subsystem to the browser that provides a persistent connection to one or more "social service providers." The goal of the feature is to:

  • Allow deeper engagement with social services, for users that desire it.
  • Provide a standard mechanism for social service providers to engage in "marginalia" conversations about the web
  • Simplify the user interface of "social recommendation" of web content, in order to start to reduce the NASCAR-button-spam we see on many pages today
  • Provide a clean user interface abstraction for real-time communication between users on a social network

What sort of communication? Inc vid? +yes

  • Enhance user choice by allowing users to "bring their own network" to the web (as opposed to the current system of iframe embedding, which requires the site developer to choose which network to use for social recommendation)
  • Lay the groundwork for user-provided contact list and activity stream consumption by the user agent

Implementation overview: The current implementation depends on a JSON-encoded metadata file that identifies a social service. This includes a name, icon, a JavaScript Worker URL, a Sidebar URL, and a URL prefix. This metadata file is parsed and stored in a sqlite database of "social services", and an XPCOM service providing access to this database is registered. At startup time, we create a "background worker" for each active service. Since we don't actually have background workers, we do it like this (in frameworker.js): We create an iframe on the hidden window, and load the JS URL in it (as content!). Then we attach a Sandbox to the iframe and copy a couple objects from the iframe to the sandbox. Then we eval the JS in the sandbox. This gives us a JS context which runs in the principal of the JS URL, but has no DOM. We copy the XMLHttpRequest, WebSockets, indexedDB, localStorage, btoa, atob, setTimeout, setInterval, clearTimeout, clearInterval, dump, FileReader, Blob, and navigator objects. The Worker runs effetively for the duration of the browser session (though see note on Private Browsing) We synthesize a MessagePort object which provides text-only messaging between the Worker and the browser. We invoke a method on the Worker passing in a MessagePort, which it saves, and posts messages to, later. We inspect the "topic" attribute of messages that come out of the Worker; if they start with the "social." prefix, we handle them internally (more below); otherwise we forward them to sidebar and window content. At window overlay time, we create three new UI elements:

  • A recommendation button in the URL bar
  • A toolbar item which is positioned at the end of the nav-bar
  • A sidebar browser element which is positioned to the right of content and may be initially hidden.
  • Private Browsing

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.

  • Activating the Feature

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. I suggest that this be implemented as: 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.

What solutions/approaches were considered other than the proposed solution?

`

Why was this solution chosen?

`

Any security threats already considered in the design and why?

- Phishing

Threat Brainstorming

- MITM of 3rd party sites

  • manifest file - what are the security requirements for entrance? Can a website say, "click to add whateverbook," and really add a MITM site to your manifest, with legit ssl key?
  • Under "To figure out, it says, "Do we need to blacklist some URLs for "recommend"? (i.e. anything with security-sensitive GET params)" - Are there any examples you have in mind? hopefully the websites just don't do this.
  • 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)"
    • concerns:
      • 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.
      • glowing/hopping ambient notifications, collections - DoS against user's display?'
  • The worker should not have write access to the manifest database to prevent persistent XSS/sidebar rootkit type exploits and payloads
  • how can we restrict outbound network sockets to a whitelist of those needed by the provider? this would be to prevent abuse cases in evil sidebars/injected js/etc such as js portscanners, click fraud, DoS, etc, which would run persistently
  • sidebar should be disabled in kiosk mode
  • an it dept should be able to disable sidebar functionality, or add their ow
  • save checksum of manifest to make sure it didnt change
  • flash, java applets, etc running inside the window will not be bound by restrictions on what js can do... google needs flash for now and its common for streaming media, but is scary and maybe could go away with html5? Also, it doesnt have to be applet AND flash, it could applet OR flash, until html5

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?

  • Is domain in the draft being used the same as origin in SOP?
    • e.g. Can service provider and and service be on same domain but different port / scheme? (good question, see discussion below under threats brainstorming / "activating the feature")
  • Is the notification system different from the notification system being developed by services?
  • sandbox == iframe sandbox?

Threat thoughts: Two big categories, I think. Privacy threats from installed service providers: Can a service provider make malicious use of browsing data provided through this API?

  • The current design is that no browsing information is passed to the service provider without a user action. The only context currently provided, in fact, is a click on the "recommend" button, which passes the URL of the current page to the Worker.
  • In future, though, I think the feature would be improved by 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. 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.
    • Can the Worker be MITMed? That could be bad. Require SSL? (yes)
    • MITM on sidebar content? Could get at the getWorker() call, so you could spoof interactions with the sidebar. Require SSL?

Phishing threats from spoofing the social browsing UX:

  • 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? Can't think of anything right now.

{{#set: SecReview feature goal=The Social Browsing feature adds a subsystem to the browser that provides a persistent connection to one or more "social service providers." The goal of the feature is to:

  • Allow deeper engagement with social services, for users that desire it.
  • Provide a standard mechanism for social service providers to engage in "marginalia" conversations about the web
  • Simplify the user interface of "social recommendation" of web content, in order to start to reduce the NASCAR-button-spam we see on many pages today
  • Provide a clean user interface abstraction for real-time communication between users on a social network

What sort of communication? Inc vid? +yes

  • Enhance user choice by allowing users to "bring their own network" to the web (as opposed to the current system of iframe embedding, which requires the site developer to choose which network to use for social recommendation)
  • Lay the groundwork for user-provided contact list and activity stream consumption by the user agent

Implementation overview: The current implementation depends on a JSON-encoded metadata file that identifies a social service. This includes a name, icon, a JavaScript Worker URL, a Sidebar URL, and a URL prefix. This metadata file is parsed and stored in a sqlite database of "social services", and an XPCOM service providing access to this database is registered. At startup time, we create a "background worker" for each active service. Since we don't actually have background workers, we do it like this (in frameworker.js): We create an iframe on the hidden window, and load the JS URL in it (as content!). Then we attach a Sandbox to the iframe and copy a couple objects from the iframe to the sandbox. Then we eval the JS in the sandbox. This gives us a JS context which runs in the principal of the JS URL, but has no DOM. We copy the XMLHttpRequest, WebSockets, indexedDB, localStorage, btoa, atob, setTimeout, setInterval, clearTimeout, clearInterval, dump, FileReader, Blob, and navigator objects. The Worker runs effetively for the duration of the browser session (though see note on Private Browsing) We synthesize a MessagePort object which provides text-only messaging between the Worker and the browser. We invoke a method on the Worker passing in a MessagePort, which it saves, and posts messages to, later. We inspect the "topic" attribute of messages that come out of the Worker; if they start with the "social." prefix, we handle them internally (more below); otherwise we forward them to sidebar and window content. At window overlay time, we create three new UI elements:

  • A recommendation button in the URL bar
  • A toolbar item which is positioned at the end of the nav-bar
  • A sidebar browser element which is positioned to the right of content and may be initially hidden.
  • Private Browsing

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.

  • Activating the Feature

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. I suggest that this be implemented as: 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. |SecReview alt solutions=' |SecReview solution chosen=' |SecReview threats considered=- Phishing |SecReview threat brainstorming=- MITM of 3rd party sites

  • manifest file - what are the security requirements for entrance? Can a website say, "click to add whateverbook," and really add a MITM site to your manifest, with legit ssl key?
  • Under "To figure out, it says, "Do we need to blacklist some URLs for "recommend"? (i.e. anything with security-sensitive GET params)" - Are there any examples you have in mind? hopefully the websites just don't do this.
  • 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)"
    • concerns:
      • 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.
      • glowing/hopping ambient notifications, collections - DoS against user's display?'
  • The worker should not have write access to the manifest database to prevent persistent XSS/sidebar rootkit type exploits and payloads
  • how can we restrict outbound network sockets to a whitelist of those needed by the provider? this would be to prevent abuse cases in evil sidebars/injected js/etc such as js portscanners, click fraud, DoS, etc, which would run persistently
  • sidebar should be disabled in kiosk mode
  • an it dept should be able to disable sidebar functionality, or add their ow
  • save checksum of manifest to make sure it didnt change
  • flash, java applets, etc running inside the window will not be bound by restrictions on what js can do... google needs flash for now and its common for streaming media, but is scary and maybe could go away with html5? Also, it doesnt have to be applet AND flash, it could applet OR flash, until html5

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?

  • Is domain in the draft being used the same as origin in SOP?
    • e.g. Can service provider and and service be on same domain but different port / scheme? (good question, see discussion below under threats brainstorming / "activating the feature")
  • Is the notification system different from the notification system being developed by services?
  • sandbox == iframe sandbox?

Threat thoughts: Two big categories, I think. Privacy threats from installed service providers: Can a service provider make malicious use of browsing data provided through this API?

  • The current design is that no browsing information is passed to the service provider without a user action. The only context currently provided, in fact, is a click on the "recommend" button, which passes the URL of the current page to the Worker.
  • In future, though, I think the feature would be improved by 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. 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.
    • Can the Worker be MITMed? That could be bad. Require SSL? (yes)
    • MITM on sidebar content? Could get at the getWorker() call, so you could spoof interactions with the sidebar. Require SSL?

Phishing threats from spoofing the social browsing UX:

  • 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? Can't think of anything right now.

}}

Action Items

Action Item Status In Progress
Release Target `
Action Items
Who bug Action By When Completed date

[NEW] new [DONE] Done [MISSED] Miss

yvan 763936 security test plan for social api (coordinate with services) TBD [NEW] new
Yvan 763937 sync with security team at FaceBook TBD [NEW] new
763941 Security Code Review TBD [NEW] new

Bugzilla query error

Query options must be valid JSON.1

{{#set:|SecReview action item status=In Progress

|Feature version=`

|SecReview action items=

Who bug Action By When Completed date

[NEW] new [DONE] Done [MISSED] Miss

yvan 763936 security test plan for social api (coordinate with services) TBD [NEW] new
Yvan 763937 sync with security team at FaceBook TBD [NEW] new
763941 Security Code Review TBD [NEW] new

Bugzilla query error

Query options must be valid JSON.1

}}

Retrieved from "https://wiki.allizom.org/index.php?title=Security/Reviews/SocialAPI&oldid=440293"