Security/Reviews/SocialAPI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (formatting)
(more formatting...)
Line 185: Line 185:
* 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?
* 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.   
* 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
**  Not sure if this is part of the threat or remediation, I don't know enough about this part of firefox
Proposed Remediation
Proposed Remediation
* ?
* ?

Revision as of 09:30, 14 June 2012

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

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

  • ?


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

Threat

Proposed Remediation

  • ?


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

  • ?


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.

Proposed Remediation

  • Worker should not have write access to the manifest database to prevent persistent XSS/sidebar rootkit type exploits and payloads
  • Egress filter: 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
  • Save checksum of manifest to make sure it didnt change

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
      • Flash is still common for streaming media

Proposed Remediation

  • Cu.Sandbox runs javascript, and we currently dont provide DOM access even though I want to change that. Without DOM access, you cannot include the plugins to run java, flash, etc. Even with DOM access, we can disable those, and I was intending to add those few lines of code regardless, Shane added bug 764215 for 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?


6 Privacy threats from installed service providers - Can a service provider make malicious use of browsing data provided through this API?

Threat

  • 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.
    • Is the Recommend button in Chrome
      • Could a malicious add-in “click” this, allowing a maliciously installed social provider top lean the page, or GET/POST it to a malicious site?
    • Is the Recommend button on the page?
      • Can a Javascript/flash/etc “rootkit” learn the current page, and pass it to a malicious site?

Threat

  • How are URL parameters handled?
    • Some sites unfortunately still include sensitive information in parameters, such as Session ID. Other sites require the parameter in order to transmit the correct page to the worker.
  • If the page was generated via a POST request, there isn't enough data for a useful link to be sent. (more a feature issue than security issue)

Proposed Remediation

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.


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


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


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?

Proposed Remediation

  • ?


10 Are some URLs inherently risky to “recommend?”

Threat

  • Recommending URLs with security-sensitive GET parameters
  • * Hopefully websites don't do this – potential for CSRF attack against the user who clicks a link

Proposed Remediation

  • ?

Threat

  • Malware/malicious site recommendation by user

Proposed Remediation

  • Controls around installing new social providers: For installing new social providers, the safeguards in place include: requiring valid ssl certs, safebrowsing checks, same-origin policy of any urls in the manifest.
  • Possible issue: FireFTP addin installed. Safe Browsing will test http, https, ftp. If a site hosts malicious Javascript from a host that is FTPs only, it might check as OK, as google's search engine is unlikely to ever find it, even though it hosts malware.


11 Will SocialAPI include webcam/audio chat support?

Threat

  • Worker enables webcam/mic to spy on user

Proposed Remediation

  • ?


12 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 http://www.gnucitizen.org/blog/attackapi/
  • 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.


13 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

  • ?


Open Questions

  • 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?
  • 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)<- from notes, I don't understand this, though
  • We'd could definitely use a step-by-step explanation of how it is intended to work. Pedantic is good, more detail is better than less.
  • We're moving away from using sqlite to using prefs, at least in the near term, for storing the provider information. We expect that any given user will install less than 3 or 4 providers, and most will likely only have 1. (Question: Is this a good assumption? Example: Facebook, Twitter, Google Chat are three. We expect – and hope – more sites will create socialapi functionality. There will likely be toolkits created to make this easy. ) Using a full db for such a small amount of data is overkill and the change to prefs removes a good chunk of code. Any issues/concerns related specifically to the sqlite db can be removed.


Platform Issues - Firefox

  • Data Encryption for preferences data
    • Firefox stores a lot of critical metadata in the clear, in text files, such as it's own update url, and the update url for all addons, safebrowsing, etc. It may be a good security improvement to have some crypto signing of that data, which any feature or addon could then also take advantage of. This would be a good bug for the platform or security roadmap, but not a part of the socialapi scope.


Platform Issues - Javascript Engine

  • Non-responsive Scripts (Javascript Engine)
    • Cu.Sandbox doesn't provide a way for us to test for non-responsive scripts, so making this a blocker will prevent the feature from moving forward at this time. Shane thinks that kind of functionality should actually be integral to Cu.Sandbox itself rather than features utilizing it, it would be a good addition, but something for js engine.

Placing the non-responsive test at the sandbox level will also provide that protection to the many places sandbox is used throughout firefox. The real worker implementation should probably be in scope for that as well.


Security-Relevent Technical Notes

Firefox Hidden Window refs – every instance of Firefox has a hidden window - https://mxr.mozilla.org/mozilla-central/search?string=hiddenWindow

  • Controls around installing new social providers: For installing new social providers, the safeguards in place include: requiring valid ssl certs, safebrowsing checks, same-origin policy of any urls in the manifest.
    • Bug 756591 asks whether this is sufficient, if we have to implement a new service to support blacklisting it will have to be on a future roadmap. For the initial landing, it is likely we will not include the ability to install new providers, but we will ensure that developers can easily add new providers via preferences or addons that set those preferences.
      • Right now (an likely not for the initial landing), the only way to install a remote manifest file (other than a malicious addon) is by browsing to a website that has a "link rel=manifest href=path" tag in the the html head section. That link path must be same-origin to the page containing it, and urls within the manifest must be same origin as the manifest file itself. The channel must be secure with a valid ssl cert. The safebrowsing check is just an additional check prior to these measures.
  • Sync support - Moving to using prefs for storing the social provider metadata gives us sync for free.


Notes for pentest

  • Sandbox: Cu.Sandbox allows chrome to inject code for content to use, some of which may presumably safely call back into chrome functionality. IMHO The question here is, have we used the sandbox correctly. We had the code looked over in bug 751241, and further again by ddahl (more an off-the-record review for a question I had). As part of the full code review the sandbox use should be scrutinized. If there are risk problems with the sandbox itself, that needs to go to the javascript engine team.

{{#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=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

  • ?


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

Threat

Proposed Remediation

  • ?


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

  • ?


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.

Proposed Remediation

  • Worker should not have write access to the manifest database to prevent persistent XSS/sidebar rootkit type exploits and payloads
  • Egress filter: 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
  • Save checksum of manifest to make sure it didnt change

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
      • Flash is still common for streaming media

Proposed Remediation

  • Cu.Sandbox runs javascript, and we currently dont provide DOM access even though I want to change that. Without DOM access, you cannot include the plugins to run java, flash, etc. Even with DOM access, we can disable those, and I was intending to add those few lines of code regardless, Shane added bug 764215 for 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?


6 Privacy threats from installed service providers - Can a service provider make malicious use of browsing data provided through this API?

Threat

  • 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.
    • Is the Recommend button in Chrome
      • Could a malicious add-in “click” this, allowing a maliciously installed social provider top lean the page, or GET/POST it to a malicious site?
    • Is the Recommend button on the page?
      • Can a Javascript/flash/etc “rootkit” learn the current page, and pass it to a malicious site?

Threat

  • How are URL parameters handled?
    • Some sites unfortunately still include sensitive information in parameters, such as Session ID. Other sites require the parameter in order to transmit the correct page to the worker.
  • If the page was generated via a POST request, there isn't enough data for a useful link to be sent. (more a feature issue than security issue)

Proposed Remediation

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.


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


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


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?

Proposed Remediation

  • ?


10 Are some URLs inherently risky to “recommend?”

Threat

  • Recommending URLs with security-sensitive GET parameters
  • * Hopefully websites don't do this – potential for CSRF attack against the user who clicks a link

Proposed Remediation

  • ?

Threat

  • Malware/malicious site recommendation by user

Proposed Remediation

  • Controls around installing new social providers: For installing new social providers, the safeguards in place include: requiring valid ssl certs, safebrowsing checks, same-origin policy of any urls in the manifest.
  • Possible issue: FireFTP addin installed. Safe Browsing will test http, https, ftp. If a site hosts malicious Javascript from a host that is FTPs only, it might check as OK, as google's search engine is unlikely to ever find it, even though it hosts malware.


11 Will SocialAPI include webcam/audio chat support?

Threat

  • Worker enables webcam/mic to spy on user

Proposed Remediation

  • ?


12 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 http://www.gnucitizen.org/blog/attackapi/
  • 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.


13 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

  • ?


Open Questions

  • 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?
  • 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)<- from notes, I don't understand this, though
  • We'd could definitely use a step-by-step explanation of how it is intended to work. Pedantic is good, more detail is better than less.
  • We're moving away from using sqlite to using prefs, at least in the near term, for storing the provider information. We expect that any given user will install less than 3 or 4 providers, and most will likely only have 1. (Question: Is this a good assumption? Example: Facebook, Twitter, Google Chat are three. We expect – and hope – more sites will create socialapi functionality. There will likely be toolkits created to make this easy. ) Using a full db for such a small amount of data is overkill and the change to prefs removes a good chunk of code. Any issues/concerns related specifically to the sqlite db can be removed.


Platform Issues - Firefox

  • Data Encryption for preferences data
    • Firefox stores a lot of critical metadata in the clear, in text files, such as it's own update url, and the update url for all addons, safebrowsing, etc. It may be a good security improvement to have some crypto signing of that data, which any feature or addon could then also take advantage of. This would be a good bug for the platform or security roadmap, but not a part of the socialapi scope.


Platform Issues - Javascript Engine

  • Non-responsive Scripts (Javascript Engine)
    • Cu.Sandbox doesn't provide a way for us to test for non-responsive scripts, so making this a blocker will prevent the feature from moving forward at this time. Shane thinks that kind of functionality should actually be integral to Cu.Sandbox itself rather than features utilizing it, it would be a good addition, but something for js engine.

Placing the non-responsive test at the sandbox level will also provide that protection to the many places sandbox is used throughout firefox. The real worker implementation should probably be in scope for that as well.


Security-Relevent Technical Notes

Firefox Hidden Window refs – every instance of Firefox has a hidden window - https://mxr.mozilla.org/mozilla-central/search?string=hiddenWindow

  • Controls around installing new social providers: For installing new social providers, the safeguards in place include: requiring valid ssl certs, safebrowsing checks, same-origin policy of any urls in the manifest.
    • Bug 756591 asks whether this is sufficient, if we have to implement a new service to support blacklisting it will have to be on a future roadmap. For the initial landing, it is likely we will not include the ability to install new providers, but we will ensure that developers can easily add new providers via preferences or addons that set those preferences.
      • Right now (an likely not for the initial landing), the only way to install a remote manifest file (other than a malicious addon) is by browsing to a website that has a "link rel=manifest href=path" tag in the the html head section. That link path must be same-origin to the page containing it, and urls within the manifest must be same origin as the manifest file itself. The channel must be secure with a valid ssl cert. The safebrowsing check is just an additional check prior to these measures.
  • Sync support - Moving to using prefs for storing the social provider metadata gives us sync for free.


Notes for pentest

  • Sandbox: Cu.Sandbox allows chrome to inject code for content to use, some of which may presumably safely call back into chrome functionality. IMHO The question here is, have we used the sandbox correctly. We had the code looked over in bug 751241, and further again by ddahl (more an off-the-record review for a question I had). As part of the full code review the sandbox use should be scrutinized. If there are risk problems with the sandbox itself, that needs to go to the javascript engine team.

}}

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
Full Query
ID Summary Priority Status
763936 SecReview: SocialAPI - security test plan for social api (coordinate with services) -- RESOLVED
763941 SecReview: SocialAPI - Security Code Review P2 RESOLVED

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

{{#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
Full Query
ID Summary Priority Status
763936 SecReview: SocialAPI - security test plan for social api (coordinate with services) -- RESOLVED
763941 SecReview: SocialAPI - Security Code Review P2 RESOLVED

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

}}

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