Security/Reviews/SocialAPI

From MozillaWiki
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


submit threat brainstorming comments, suggestions to amuntner (@) mozilla.com

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 

  • IIUC discovery and install will not land in 16, can this item be removed until that functionality is figured out and moves to landing?
  • 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 

Proposed Remediation 

  •  Providers  only allowed to provide string (no input fields, etc); only interaction is a click driving an event back to Ffx
  • Guide providers about safe strings to place in notifications - e.g. "Joe has come online" but not "Joe has a new update and here it is: XXXX"

Agreed Path Forward

  • will implement remediation prior to launch

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, on a per-provider basis
  • Need to decide on default

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
    • Can we do this with CSP?(use csp in js sandbox)
  •  Save checksum of manifest to make sure it didnt change
    • where would we save this that an addon couldnt change as well?  manifests are only updateable from priviledged code.
  • Egress filtering is very hard.  Focus attention on transport-layer remediation

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 
      • 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. 

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

  • Need a 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 

  •  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 (yes)
      • 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? Sure, a malicious addon can do anything
    • Is the Recommend button on the page? (no)
      • Can a Javascript/flash/etc “rootkit”  learn the current page, and pass it to a malicious site? No

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 

Agreed Path Forward:

  • Filter on cache-control
  • Investigate whether META cache-control: private is good enough for content

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?   

Proposed Remediation 

  • Visual cue, also visual cue for developer mode
  • Education efforts with providers to never present login bars in sidebar and user education that user will never be asked for logins within sidebar
  • Specify that providers should never ask for login credentials within sidebar. If they choose to do this, they are aware of a very difficult phishing problem.  

Agreed Path Forward

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

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.
    • not relevant: we are not checking recommend links against Safe Browsing
  • See discussion in #6
  • What if we provide a meta for "share URL"? could contain a safer version of URL

Agreed Path Forward

  • Can't really solve this problem: this is a problem of poor website design

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

Threat

  •  Worker enables webcam/mic to spy on user 

Proposed Remediation 

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

Agreed Path Forward




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 <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)

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 

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

Agreed Path Forward

  • Address before launch





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. (agreed: moving to prefs-only)

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. 
      • Integrity protection for platform-specified preferences
      • For platforms supporting code signing: is it only for binaries, or for .js config files, too?

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 - <a href="https://mxr.mozilla.org/mozilla-central/search?string=hiddenWindow">https://mxr.mozilla.org/mozilla-central/search?string=hiddenWindow</a>

  •  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=
submit threat brainstorming comments, suggestions to amuntner (@) mozilla.com

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 

  • IIUC discovery and install will not land in 16, can this item be removed until that functionality is figured out and moves to landing?
  • 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 

Proposed Remediation 

  •  Providers  only allowed to provide string (no input fields, etc); only interaction is a click driving an event back to Ffx
  • Guide providers about safe strings to place in notifications - e.g. "Joe has come online" but not "Joe has a new update and here it is: XXXX"

Agreed Path Forward

  • will implement remediation prior to launch

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, on a per-provider basis
  • Need to decide on default

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
    • Can we do this with CSP?(use csp in js sandbox)
  •  Save checksum of manifest to make sure it didnt change
    • where would we save this that an addon couldnt change as well?  manifests are only updateable from priviledged code.
  • Egress filtering is very hard.  Focus attention on transport-layer remediation

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 
      • 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. 

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

  • Need a 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 

  •  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 (yes)
      • 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? Sure, a malicious addon can do anything
    • Is the Recommend button on the page? (no)
      • Can a Javascript/flash/etc “rootkit”  learn the current page, and pass it to a malicious site? No

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 

Agreed Path Forward:

  • Filter on cache-control
  • Investigate whether META cache-control: private is good enough for content

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?   

Proposed Remediation 

  • Visual cue, also visual cue for developer mode
  • Education efforts with providers to never present login bars in sidebar and user education that user will never be asked for logins within sidebar
  • Specify that providers should never ask for login credentials within sidebar. If they choose to do this, they are aware of a very difficult phishing problem.  

Agreed Path Forward

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

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.
    • not relevant: we are not checking recommend links against Safe Browsing
  • See discussion in #6
  • What if we provide a meta for "share URL"? could contain a safer version of URL

Agreed Path Forward

  • Can't really solve this problem: this is a problem of poor website design

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

Threat

  •  Worker enables webcam/mic to spy on user 

Proposed Remediation 

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

Agreed Path Forward




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 <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)

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 

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

Agreed Path Forward

  • Address before launch





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. (agreed: moving to prefs-only)

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. 
      • Integrity protection for platform-specified preferences
      • For platforms supporting code signing: is it only for binaries, or for .js config files, too?

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 - <a href="https://mxr.mozilla.org/mozilla-central/search?string=hiddenWindow">https://mxr.mozilla.org/mozilla-central/search?string=hiddenWindow</a>

  •  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.allizom.org/index.php?title=Security/Reviews/SocialAPI&oldid=443803"