297
edits
Security/Reviews/SocialAPI: Difference between revisions
m
formatting
No edit summary |
m (formatting) |
||
| Line 37: | Line 37: | ||
|SecReview threats considered=- Phishing | |SecReview threats considered=- Phishing | ||
|SecReview threat brainstorming='''1 Manifest file - what are the security requirements for entrance? ''' | |SecReview threat brainstorming='''1 Manifest file - what are the security requirements for entrance? ''' | ||
Threat | Threat | ||
* Can a website say, "click to add whateverbook," and really add a MITM site to your manifest, with legit ssl key? | * Can a website say, "click to add whateverbook," and really add a MITM site to your manifest, with legit ssl key? | ||
| Line 44: | Line 45: | ||
'''2 Growl/Toast style ephemeral window used to spoof a system or application window''' | '''2 Growl/Toast style ephemeral window used to spoof a system or application window''' | ||
Threat | 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. | * 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. | ||
| Line 52: | Line 54: | ||
'''3 Growl/Toast style ephemeral window used to DoS user's display''' | '''3 Growl/Toast style ephemeral window used to DoS user's display''' | ||
Threat | 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)" | * 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)" | ||
| Line 59: | Line 62: | ||
'''4 Built-in provider functionality could be hijacked ''' | '''4 Built-in provider functionality could be hijacked ''' | ||
Threat | Threat | ||
* Pollution of Manifest db with persistent XSS/Sidebar rootkit | * Pollution of Manifest db with persistent XSS/Sidebar rootkit | ||
| Line 64: | Line 68: | ||
Proposed Remediation | Proposed Remediation | ||
* Worker should not have write access to the manifest database to prevent persistent XSS/sidebar rootkit type exploits and payloads | * Worker should not have write access to the manifest database to prevent persistent XSS/sidebar rootkit type exploits and payloads | ||
* Egress filter: Restrict outbound network sockets to a whitelist of those needed by the provider? this would be to prevent abuse cases in evil sidebars/injected js/etc such as js portscanners, click fraud, DoS, etc, which would run persistently | |||
* Save checksum of manifest to make sure it didnt change | * Save checksum of manifest to make sure it didnt change | ||
Threat | Threat | ||
| Line 70: | Line 74: | ||
* Java and Flash are the top two browser exploit vectors | * 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. | * flash, java applets, etc running inside the window will not be bound by restrictions on what Javascript can do. | ||
* Constraints | ** Constraints | ||
* Google needs flash for now | *** Google needs flash for now | ||
* Flash is still common for streaming media | *** Flash is still common for streaming media | ||
Proposed Remediation | 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. | * 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. | ||
| Line 78: | Line 82: | ||
'''5 Sidebar enabled at inappropriate times''' | '''5 Sidebar enabled at inappropriate times''' | ||
Threat | Threat | ||
* Sidebar not appropriate for all browser deployments. Some users may not want SocialAPI functionality in their browser | * Sidebar not appropriate for all browser deployments. Some users may not want SocialAPI functionality in their browser | ||
| Line 87: | Line 92: | ||
* 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. | * 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. | * 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. | ** 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? | *** Possible threat: Can this window be spoofed to trick the user into opening a fake panel, enter credentials, etc? | ||
'''6 Privacy threats from installed service providers - Can a service provider make malicious use of browsing data provided through this API? ''' | '''6 Privacy threats from installed service providers - Can a service provider make malicious use of browsing data provided through this API? ''' | ||
Threat | 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. | * 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 | ** Is the Recommend button in Chrome | ||
* Could a malicious add-in “click” this, allowing a maliciously installed social provider top lean the page, or GET/POST it to a malicious site? | *** Could a malicious add-in “click” this, allowing a maliciously installed social provider top lean the page, or GET/POST it to a malicious site? | ||
* Is the Recommend button on the page? | ** Is the Recommend button on the page? | ||
* Can a Javascript/flash/etc “rootkit” learn the current page, and pass it to a malicious site? | *** Can a Javascript/flash/etc “rootkit” learn the current page, and pass it to a malicious site? | ||
Threat | Threat | ||
* How are URL parameters handled? | * 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. | ** 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) | * 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 | Proposed Remediation | ||
* Allow or disallow parameters being passed to workers | * 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? | ** Tradeoff between allowing http://site.com?page=91cf5039c559d5 and http://site.com?sessid=91cf5039c559d5 vs not letting the worker receive params? | ||
Threat | Threat | ||
* Proposed future feature - more information sharing. i.e. extracting metadata from visited pages and passing it to the Worker. | * 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. | ** This has potential for user surveillance and tracking if used aggressively. | ||
Proposed Remediation | 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. | * 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. | ||
| Line 113: | Line 119: | ||
'''7 MITM attack against active worker session with provider''' | '''7 MITM attack against active worker session with provider''' | ||
Threat | Threat | ||
* User session proxied and MITM by attacker | * 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. | ** 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 | *** 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. | *** 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 | Remediation | ||
Require SSL connection to all service providers | * Require SSL connection to all service providers | ||
'''8 MITM against sidebar content''' | '''8 MITM against sidebar content''' | ||
Threat | Threat | ||
* MITM on sidebar content? Could get at the getWorker() call, so you could spoof interactions with the sidebar. | * MITM on sidebar content? Could get at the getWorker() call, so you could spoof interactions with the sidebar. | ||
| Line 131: | Line 139: | ||
'''9 Phishing threat from spoofing the social browser UX''' | '''9 Phishing threat from spoofing the social browser UX''' | ||
Threat | Threat | ||
* The user may infer a greater degree of trust from social network providers. *This could be abused for phishing attacks. | * The user may infer a greater degree of trust from social network providers. | ||
* How would this work? | * This could be abused for phishing attacks. | ||
* 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? | ||
*** 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? | * Attack surface through Notification API? | ||
Proposed Remediation | Proposed Remediation | ||
| Line 140: | Line 149: | ||
'''10 Are some URLs inherently risky to “recommend?”''' | '''10 Are some URLs inherently risky to “recommend?”''' | ||
Threat | Threat | ||
* Recommending URLs with security-sensitive GET parameters | * 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 | Proposed Remediation | ||
* ? | * ? | ||
| Line 153: | Line 163: | ||
'''11 Will SocialAPI include webcam/audio chat support?''' | '''11 Will SocialAPI include webcam/audio chat support?''' | ||
Threat | Threat | ||
* Worker enables webcam/mic to spy on user | * Worker enables webcam/mic to spy on user | ||
| Line 160: | Line 171: | ||
'''12 Manifest is retrieved from a local file:// uri rather than remote website''' | '''12 Manifest is retrieved from a local file:// uri rather than remote website''' | ||
Threat | Threat | ||
* Starts a malicious js process, such as to implement a javascript portscanner and sending the results to a website. Ex http://www.gnucitizen.org/blog/attackapi/ | * 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/ | ||
| Line 165: | Line 177: | ||
* Can the ability to point to local files be used to read the content of arbitrary files? | * Can the ability to point to local files be used to read the content of arbitrary files? | ||
Proposed Remediation | 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. | * Currently, code loaded from a manifest is sandboxed with a smaller API than what is available to normal web content in a browser tab. I suppose it would be possible to create a port scanner somehow using WebSocket, but if so then that is a platform security issue that is outside the domain of the socialapi. ** Even if the code had full access to the normal iframe content, it is still controlled by iframe content policy enforced at the platform layer. | ||
'''13 Javascript or other active content running in the initial hidden window? | '''13 Javascript or other active content running in the initial hidden window? | ||
Threat''' | 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? | * 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? | ||
| Line 179: | Line 192: | ||
'''Open Questions''' | '''Open Questions''' | ||
* Is domain in the draft being used the same as origin in SOP? | * 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") | ** 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? | * Is the notification system different from the notification system being developed by services? | ||
* sandbox == iframe sandbox? | * sandbox == iframe sandbox? | ||
| Line 189: | Line 202: | ||
'''Platform Issues - Firefox''' | '''Platform Issues - Firefox''' | ||
* Data Encryption for preferences data | * 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. | ** 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''' | '''Platform Issues - Javascript Engine''' | ||
* Non-responsive Scripts (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. | ** 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. | 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. | The real worker implementation should probably be in scope for that as well. | ||
| Line 203: | Line 216: | ||
* Initial startup code - https://github.com/mozilla/socialapi-dev/blob/develop/content/main.js | * Initial startup code - https://github.com/mozilla/socialapi-dev/blob/develop/content/main.js | ||
* Other source repo - https://github.com/michaelrhanson/socialapi-hacking | * Other source repo - https://github.com/michaelrhanson/socialapi-hacking | ||
* Q - Where is the definitive source? | ** Q - Where is the definitive source? | ||
Firefox Hidden Window refs – every instance of Firefox has a hidden window - https://mxr.mozilla.org/mozilla-central/search?string=hiddenWindow | Firefox Hidden Window refs – every instance of Firefox has a hidden window - https://mxr.mozilla.org/mozilla-central/search?string=hiddenWindow | ||
* Controls around installing new social providers: For installing new social providers, the safeguards in place include: requiring valid ssl certs, safebrowsing checks, same-origin policy of any urls in the manifest. | * 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. | ** 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. | *** Right now (an likely not for the initial landing), the only way to install a remote manifest file (other than a malicious addon) is by browsing to a website that has a "link rel=manifest href=path" tag in the the html head section. That link path must be same-origin to the page containing it, and urls within the manifest must be same origin as the manifest file itself. The channel must be secure with a valid ssl cert. The safebrowsing check is just an additional check prior to these measures. | ||
* Sync support - Moving to using prefs for storing the social provider metadata gives us sync for free. | * Sync support - Moving to using prefs for storing the social provider metadata gives us sync for free. | ||