Security/Reviews/SocialAPI
Item Reviewed
Social API | |||||||||
Target | *https://wiki.mozilla.org/Labs/SocialAPI
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%); |
{{#set:SecReview name=Social API |SecReview target=*https://wiki.mozilla.org/Labs/SocialAPI
- https://github.com/mozilla/socialapi-dev/blob/develop/docs/socialAPI.md
- https://github.com/michaelrhanson/socialapi-hacking has some hacked up examples, not truely providers, but the yammer one makes some use of the socialapi
- https://github.com/michaelrhanson/mozilla-demo-social-service has a better example of a provider with a node.js server
- https://github.com/mozilla/socialapi-dev is the git development repo which gets pulled into the hg repo
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
- 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.
- Trick user into providing their CSRF token – see <a href="http://www.symantec.com/connect/blogs/please-send-me-your-facebook-anti-csrf-token">http://www.symantec.com/connect/blogs/please-send-me-your-facebook-anti-csrf-token</a>
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
- Constraints
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?
- 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.
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
- Can a Javascript/flash/etc “rootkit” learn the current page, and pass it to a malicious site? No
- Is the Recommend button in Chrome (yes)
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
- Allow or disallow parameters being passed to workers
- Tradeoff between allowing <a href="http://site.com?page=91cf5039c559d5">http://site.com?page=91cf5039c559d5</a> and <a href="http://site.com?sessid=91cf5039c559d5">http://site.com?sessid=91cf5039c559d5</a> vs not letting the worker receive params?
- Options:
- Filter on method (disallow POST) - maybe. error-prone.
- Filter on transport (disallow HTTPS) - unlikely to be useful
- Filter on cache-control (disallow "private", "no-store", "no-cache", etc.) - a good idea
- Invent a new META header - but which way? open/closed?
- Filter on presence of sharing metadata (Open Graph META tags) - limits usefulness to long tail
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.
- 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.
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.
- How would this work?
- 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?
- 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
- Initial startup code - <a href="https://github.com/mozilla/socialapi-dev/blob/develop/content/main.js">https://github.com/mozilla/socialapi-dev/blob/develop/content/main.js</a>
- Other source repo - <a href="https://github.com/michaelrhanson/socialapi-hacking">https://github.com/michaelrhanson/socialapi-hacking</a>
- Q - Where is the definitive source?
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.
- 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.
- 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
- 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.
- Trick user into providing their CSRF token – see <a href="http://www.symantec.com/connect/blogs/please-send-me-your-facebook-anti-csrf-token">http://www.symantec.com/connect/blogs/please-send-me-your-facebook-anti-csrf-token</a>
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
- Constraints
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?
- 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.
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
- Can a Javascript/flash/etc “rootkit” learn the current page, and pass it to a malicious site? No
- Is the Recommend button in Chrome (yes)
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
- Allow or disallow parameters being passed to workers
- Tradeoff between allowing <a href="http://site.com?page=91cf5039c559d5">http://site.com?page=91cf5039c559d5</a> and <a href="http://site.com?sessid=91cf5039c559d5">http://site.com?sessid=91cf5039c559d5</a> vs not letting the worker receive params?
- Options:
- Filter on method (disallow POST) - maybe. error-prone.
- Filter on transport (disallow HTTPS) - unlikely to be useful
- Filter on cache-control (disallow "private", "no-store", "no-cache", etc.) - a good idea
- Invent a new META header - but which way? open/closed?
- Filter on presence of sharing metadata (Open Graph META tags) - limits usefulness to long tail
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.
- 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.
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.
- How would this work?
- 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?
- 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
- Initial startup code - <a href="https://github.com/mozilla/socialapi-dev/blob/develop/content/main.js">https://github.com/mozilla/socialapi-dev/blob/develop/content/main.js</a>
- Other source repo - <a href="https://github.com/michaelrhanson/socialapi-hacking">https://github.com/michaelrhanson/socialapi-hacking</a>
- Q - Where is the definitive source?
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.
- 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.
- 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 | |||||||||||||||||||||||||||||||||
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 |
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%);
}}