For security considerations I am wondering if Chrome extensions had access to an app. I design a Chrome App which handles sensitive data. As far as I understand it, that app runs in a sandboxed environment which should be fairly isolated. If a user had by mistake installed a malicious Chrome extension, would that extension be able to intercept/modify any of the sensitive data in the app?
Please note that I do not consider other ways of interceptions outside of the Chrome environment, e.g. some virus that allows someone to get root access or alike. I would just like to understand to what degree a Chrome app is more susceptible to interception than a standard stand-alone application.
Sebastian
On one hand, extensions cannot touch your app's windows (as in, inspection / script injection) in the default environment, even with "debugger" permission. Your "local" data should be safe.
On the other, I tested it and conclude that webRequest API will catch all XHRs you send.
This includes headers for both request and response, and request body. Response body is currently not available for inspection; however, a malicious extension can perform a redirect, modify your request or cancel it.
This was deemed a security issue; as of Chrome 45, extensions can no longer intercept traffic from other extensions and apps. Hosted apps were accidentally included too, but it's a bug that will be fixed soon - traffic from hosted apps will be open to webRequest as normal.
I don't know any other possibility for an extension to snoop on an app (without any anomalous chrome://flag configuration).
Extensions or other apps cannot access data inside other extensions or apps. An exception may be data in the syncFileSystem api, since an extension could be granted access to the user's Gdrive.
Related
I need some advice about Chromium extension possibilities. Can the extension change configs of the browser such as: home page, default behavior for protocol handlers (tel, mailto), security settings ("protect from dangerous websites" for example), disable sending statistics to Google, etc.?
Which configs from chrome://settings/ can be changed and how to do it if it's possible?
The Chrome API index is a good place to start.
From it, you can glean the following capabilities:
accessibilityFeatures API that deals with accessibility settings.
browsingData API that deals with clearing browsing data.
contentSettings API that deals with allowed content, site permissions and plugins.
downloads API can at least partially influence download settings.
fontSettings API can manage fonts used by Chrome.
management API can manage (but not install) other extensions.
privacy API deals with privacy-related settings (that includes some security settings).
proxy API can manage proxy settings.
In addition, there's a lot of Chrome OS specific APIs I won't list here.
There are also some manifest keys that can influence Chrome settings on install - such as the home page. See chrome_settings_overrides (note: not available on Linux) and to a lesser extent Override Pages.
See also Protecting user settings on Windows with the new Settings API (which announced the above).
Other than those, no, you can't override Chrome settings. You cannot dynamically change the home or search provider, you can't control protocol handlers (that's on OS level anyway), etc.
Note that you can't inject scripts into chrome://* pages, so you won't be able to just fiddle with the UI.
We have authored a Chrome extension and would like to ensure that our extension does not at any time participate in being sync'd using Google Account synchronization, even if the user has specified in the Advanced sync settings dialog that extensions be sync'd. Is there a way to prevent this sync'ing on a per-extension basis? Is there some setting we could place in the extension manifest file to accomplish this? Or other way to accomplish this?
If that is not possible, can we force the Extensions checkbox to always be unchecked and unalterable by the user, using enterprise-level techniques such as Group Policy Update? This is not optimal, since we only want to stop the sync'ing of our extension, and not prevent sync'ing of all extensions.
We do see that the SyncDisabled policy registry setting is available to us, but that looks like it will disable ALL data synchronization including Apps, Extensions, Settings, History, etc. This is even less desirable to us, since we don't want to affect other synchronization -- we just want to prevent only our extension from being sync'd.
The use case for this involves the following:
A corporate user installs Chrome on his work computer. Our extension is useful in the enterprise environment and is installed on Chrome.
At some point, using the Chrome browser, this user logs into his personal Gmail account. He has set up his Google Account to turn synchronization on.
Now when this user, using his home computer and Chrome browser, logs in to Google, he will find that our extension has also been installed on his Chrome browser at home -- this is not desirable, since our extension has no usefulness in the home environment. Moreover, the user may consider the presence of our extension an unwanted intrusion into his home computing environment.
The only remedy for this user would seem to be that he could go to the Advanced sync settings and uncheck the Extensions checkbox, but then he would lose the benefit of extension sync'ing of other extensions, which he may want.
Well, if you're doing it in a corporate / managed environment, you don't need to publish your extension on Web Store at all (thus preventing the sync) if you can use Group Policy.
Any extension in ExtensionInstallForcelist will be installed even if it (and its update manifest) is hosted outside Web Store. This will prevent the extension itself from syncing (though will probably still allow chrome.storage.sync to function for it, which is a plus).
Other than that, I don't think there's a way to prevent an individual Store-hosted extension from syncing.
I am developing a GWT based client server web application.
The application installs a web site on the IIS.
When clients first browse to the web site, they need to run a local installation, which installs a local process and a NPAPI plugin on the client computer.
The client runs in browsers such as IE, Chrome and Firefox,
and uses the NPAPI plugin to send messages to the local process.
The local process is used for accessing the file system, registry, etc.
In order to prevent other web sites from using the NPAPI plugin,
When a user first login, the server sends him a hash of a string which contains the URL of the site + some other data.
The NPAPI plugin has access to the current URL of the browser, and also creates the same hash and compares the two.
Due to Chrome upcoming end of support of NPAPI plugins, I am trying to replace the plugin with a Chrome extension, and a native messaging host.
The extension can't be limited to a certain domain because it can be used from many domains.
I am trying to figure out a way to prevent other web sites from using the extension to send messages to the native host but can't find a way to do it.
Does anyone have an idea how I can accomplish that?
Any advice would be greatly appreciated, thanks.
Have you considered having the extension be limited to a specific domain, and then having the other domains iframe that domain and communicate via postMessage? You could have a whitelist of domains in the JS of the iframe, and validate the message origin against that list.
It appears that chrome apps are unable to render as tabs in the browser... I happen to like the chrome tabbing interface and it would be a shame to have to try and re-implement it in html/css/js. Is there really no way to do tab management at the chrome application level? Must all new windows be shell/panel level windows?
I can imagine scenarios for applications where they would want to contribute extension related features to the browser... why are you making it more confusing for users (who now have to install an app and an extension) in order to get the full feature set?
Is there really no room for middle-ground here?
Chrome apps are separate from the browser. This is a very deliberate approach, which is unlikely to change.
For apps to be seen as apps, as opposed to websites, which are always available regardless of connectivity, they need to be seen as separate to a browser. We have found having apps launched and run outside the browser very important for users to conceptualize them as apps.
There are also security reasons to keep apps out of the browser. They have access to APIs that websites and extensions do not have access to, but to make this possible they are also individually sandboxed and have no access to the browser.
Extensions and apps can communicate via messages. It is less than ideal that a user may need to install both an app and an extension; we have been looking at some form of bundling to make this simpler.
Chrome extension is packed to zip archive. After setup it is installed on folder and user can access to it. Also he can rewrite extension and even clone to new extension.
How i can protect extension from user modifications and cloning?
I find possibility for dll files (can be compiled) - but it is not very nice.
In case you have some proprietary code (e.g. special algo you want to keep safe etc') and you are targeting Chrome - I would suggest to go with Native Client. Nacl let you run C/C++ code in your browser. It's very powerful and you can be sure it will be very hard for someone to pick into your binary.
The premise seems to be simple. By default browser interprets HTML/Javascript, so are the chrome extensions which run along with the page.
One way is to obfuscate your javascript code , or rely on NPAPI compiled-binary plugins, or use NaCL
Obfuscating the code might no longer be a solution after Chrome forbade obfuscating extensions: https://stackoverflow.com/a/49509913
Currently there is no way you can hide your Chrome extension source code from users or competitors.
There is a statement in Chrome web store faq:
Can I sell extensions in the store?
Not yet, but this functionality is coming soon.
You may wait for this feature or try the following alternatives:
Obfuscate your Javascript source: Check this for more details How can I obfuscate (protect) JavaScript?
Keep your key logic on a remote server and make Ajax calls from the background script to communicate to the server
Chrome extensions are free from 'same origin policy' if cross-origin permission is defined in the manifest:
Regular web pages can use the XMLHttpRequest object to send and
receive data from remote servers, but they're limited by the same
origin policy. Extensions aren't so limited. An extension can talk to
remote servers outside of its origin, as long as it first requests
cross-origin permissions.
Define the following in your manifest:
{
"name": "your extension",
...
"permissions": [
"http://www.yourserver.com/"
],
...
}
I'm using Gulp plugin for JavaScript obfuscation. It doesn't break extension's code.