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%); |
- 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%);
" contains strip markers and therefore it cannot be parsed sufficiently.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
Threat
- Can a website say, "click to add whateverbook," and really add a MITM site to your manifest, with legit ssl key?
- 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
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
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>
- 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"
- will implement remediation prior to launch
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)"
- 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.
- Yes, option to turn off windows entirely, on a per-provider basis
- Need to decide on default
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.
- 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
- Address primary attack point (transit) via requiring SSL for manifest access
- 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
- 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.
- Worker context is sandboxed with no access to plugins
- Bug 766607 for ensuring content-type is for test/plain or something like that
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?
- 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.
- 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
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)
- 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)
- 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
- Filter on cache-control
- Investigate whether META cache-control: private is good enough for content
- 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.
- 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.
- We are not extracting or passing metadata today
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.
- Require SSL connection to all service providers
- Require SSL connection
Threat
- MITM on sidebar content? Could get at the getWorker() call, so you could spoof interactions with the sidebar.
- Require SSL
- Require SSL, same as 7, see bug 766616 for network recovery
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?
- 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.
- Produce a strongly worded guidance document
- Make an effort to develop a visual cue, soon. bug 766622
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
- ?
- Malware/malicious site recommendation by user
- 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
- Can't really solve this problem: this is a problem of poor website design
Threat
- Worker enables webcam/mic to spy on user
- Standard content-based permission management - note that doorhanger-based permission may not render correctly in pinned chat window
- Worker doesn't get access.
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?
- 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.
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
- Ensure that only content-type that is allowed is non-DOM (proposed: application/json) bug 766607
- Address before launch
- 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)
- 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.
- 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.
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?
- 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.
- 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.
- Property "SecReview feature goal" (as page type) with input value "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
- Property "SecReview threat brainstorming" (as page type) with input value "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 ForwardNot a blocker for initial launchWill revisit upon future implementationultimately best solution for protecting built-in prefs is at the platform level2 Growl/Toast style ephemeral window used to spoof a system or application windowThreat 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 http://www.symantec.com/connect/blogs/please-send-me-your-facebook-anti-csrf-tokenProposed Remediation Providers only allowed to provide string (no input fields, etc); only interaction is a click driving an event back to FfxGuide 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 Forwardwill implement remediation prior to launch3 Growl/Toast style ephemeral window used to DoS user's displayThreat 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 basisMore severe: default to ephemeral windows OFFOSes 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 ForwardYes, option to turn off windows entirely, on a per-provider basisNeed to decide on default4 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 persistentlyCan we do this with CSP?(use csp in js sandbox) Save checksum of manifest to make sure it didnt changewhere 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 remediationAgreed Path ForwardAddress primary attack point (transit) via requiring SSL for manifest accessThreat 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 ForwardWorker context is sandboxed with no access to pluginsBug 766607 for ensuring content-type is for test/plain or something like that5 Sidebar enabled at inappropriate timesThreat 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 ForwardNeed 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 developersAction: Look at what happens when we get 404, 500, network reset on worker/sidebar request6 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 anythingIs the Recommend button on the page? (no)Can a Javascript/flash/etc “rootkit” learn the current page, and pass it to a malicious site? NoThreat 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 http://site.com?page=91cf5039c559d5 and http://site.com?sessid=91cf5039c559d5 vs not letting the worker receive params?Options: Filter on method (disallow POST) - maybe. error-prone.Filter on transport (disallow HTTPS) - unlikely to be usefulFilter on cache-control (disallow "private", "no-store", "no-cache", etc.) - a good ideaInvent a new META header - but which way? open/closed?Filter on presence of sharing metadata (Open Graph META tags) - limits usefulness to long tailAgreed Path Forward:Filter on cache-controlInvestigate whether META cache-control: private is good enough for contentThreat 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 ForwardWe are not extracting or passing metadata today7 MITM attack against active worker session with providerThreat 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 ForwardRequire SSL connection8 MITM against sidebar contentThreat MITM on sidebar content? Could get at the getWorker() call, so you could spoof interactions with the sidebar. Proposed Remediation Require SSL Agreed Path ForwardRequire SSL, same as 7, see bug 766616 for network recovery9 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 modeEducation efforts with providers to never present login bars in sidebar and user education that user will never be asked for logins within sidebarSpecify 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 ForwardProduce a strongly worded guidance documentMake an effort to develop a visual cue, soon. bug 76662210 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 RemediationControls 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 BrowsingSee discussion in #6What if we provide a meta for "share URL"? could contain a safer version of URLAgreed Path ForwardCan't really solve this problem: this is a problem of poor website design11 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 windowWorker doesn't get access.Agreed Path Forward12 Manifest is retrieved from a local file:// uri rather than remote websiteThreat Starts a malicious js process, such as to implement a javascript portscanner and sending the results to a website. Ex http://www.gnucitizen.org/blog/attackapi/ Builtin providers are allowed to point to file system resources via the resource scheme, which is necessary to implement the feature. They must provide an origin value, which any non-resource uris are resolved against. Can the ability to point to local files be used to read the content of arbitrary files? Proposed Remediation Currently, code loaded from a manifest is sandboxed with a smaller API than what is available to normal web content in a browser tab. I suppose it would be possible to create a port scanner somehow using WebSocket, but if so then that is a platform security issue that is outside the domain of the socialapi. ** Even if the code had full access to the normal iframe content, it is still controlled by iframe content policy enforced at the platform layer. 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 766607Agreed Path ForwardAddress before launchOpen 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)" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
Action Items
Action Item Status | In Progress | ||||||||||||||||||||||||||||||||
Release Target | ` | ||||||||||||||||||||||||||||||||
Action Items | |||||||||||||||||||||||||||||||||
2 Total; 0 Open (0%); 2 Resolved (100%); 0 Verified (0%); |
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%);
" contains strip markers and therefore it cannot be parsed sufficiently.