I asked this question a little over a week ago on the Atom forums (link below), and didn't receive a response, so I am reposting it here in the hopes that someone may be able to provide insight on my problem.
Recently, I have taken up an open source project which uses Electron as it’s front-end. This project has two requirements: it must be cross-platform, and it must have an embedded web browser (which should be able to browse the web and render content like a typical browser). Considering the rather large footprint Electron has already netted my application, it seems like a bad idea to attempt to use another embedded web framework alongside it. So, in the interest of simplifying my project and retaining the UI built on top of Electron, I am looking into using Electron itself as the web browser. Here’s where I’ve come into a problem.
In a security page for Electron’s documentation, it is explicitly stated that,
it is important to understand … Electron is not a web browser
This quote comes within the context that Electron–or rather the code running on top of it–carries the unique ability to interact with the user’s operating system, unlike typical web applications. The page goes on to say,
displaying arbitrary content from untrusted sources poses a severe security risk that Electron is not intended to handle
At this point, I was tempted to give up on the idea of using Electron as an inbuilt browser, but further down on that same page, you can find another very interesting tidbit:
To display remote content, use the <webview> tag or BrowserView , [and] make sure to disable the nodeIntegration and enable contextIsolation
Link: https://electronjs.org/docs/tutorial/security#isolation-for-untrusted-content
First, in regard to using webviews, Electron’s own documentation recommends outright avoiding them:
Electron’s webview tag is based on Chromium’s webview , which is undergoing dramatic architectural changes. This impacts the stability of webviews , including rendering, navigation, and event routing. We currently recommend to not use the webview tag and to consider alternatives, like iframe , Electron’s BrowserView , or an architecture that avoids embedded content altogether.
Link: https://electronjs.org/docs/api/webview-tag
Seeing as though I cannot avoid embedded content, I opted to look into using a BrowserView, but what I found was not very motivating either. The advice, as it stands, is to do two things:
disable nodeIntegration
enable contextIsolation
After looking at the security and best-practices page, I will also append the following steps:
deny session permission requests from remote content (webcam, microphone, location, etc.)
catch webview elements in creation and strip default privileges
disable the creation of new windows
disable the remote module
That is a fair amount of steps to undergo in securing external content. Not to mention, there were several additional warnings scattered through the best practices page such as the following:
(On verifying webview options before creation)
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
Link: https://electronjs.org/docs/tutorial/security#11-verify-webview-options-before-creation
(On disabling the remote module)
However, if your app can run untrusted content and even if you sandbox your renderer processes accordingly, the remote module makes it easy for malicious code to escape the sandbox and have access to system resources via the higher privileges of the main process.
Link: https://electronjs.org/docs/tutorial/security#15-disable-the-remote-module
Not to mention, upon navigation to the BrowserView page, the whole class is listed as experimental.
This all isn’t even to mention the added attack surface created by Electron, such as a vulnerability in the webview component just last year: CVE-2018-1000136
Now, taking into account all of the above, numerous developers have still opted to create web browsers that routinely consume external and uncontrolled content using Electron.
Browser’s using Electron (linked directly from Electron’s website):
https://electronjs.org/apps/wexond
https://electronjs.org/apps/dot
https://electronjs.org/apps/beaker-browser
To me, it seems irresponsible to submit users to the above security implications as a trade-off for convenience.
That being said, my question is: can you safely, to the point at which you could ensure the integrity of your users, implement web browsing capabilities for uncontrolled content using Electron?
Thank you for your time.
Link to the original post:
https://discuss.atom.io/t/security-implications-in-electron-as-a-web-browser/70653
Some ideas that don't fit into a comment box:
[the project] must have an embedded web browser
So I presume then that this project isn't just a web browser. There's other content there that may have access to Node, but you just want the embedded-web-browser portion of it to be sandboxed appropriately, right?
Regarding the comments about <webview>, yes, it is considered unstable and Electron recommends using a BrowserView instead. I don't think that the fact that it's marked as "experimental" should necessarily deter you from using it (especially considering that the Electron team is recommending it [though maybe as the best of two evils]).
Experimental doesn't imply it's unstable. It can just mean that the Electron team is experimenting with this approach, but this approach may change in the future (at which point I would expect Electron to provide a transition path forward). Though this is one possible interpretation and ultimately Electron would have to comment on this.
The advice... is to do two things:
disable nodeIntegration
enable contextIsolation
I would also make use of the sandbox option inherited from BrowserWindows. BrowserView's docs on the constructor options say:
webPreferences Object (optional) - See BrowserWindow.
which tells me that BrowserView accepts the same options as BrowserWindow.
You would set it up like so:
new BrowserView({ webPreferences: {
sandbox: true,
nodeIntegration: false,
contextIsolation: true,
preload: "./pathToPreloadScript.js"
}});
See more information about this approach here. The preload script is what would expose some Node IPC APIs to the sandboxed content you're loading. Note the Status section at the bottom, which says:
Please use the sandbox option with care, as it is still an experimental feature. We are still not aware of the security implications of exposing some Electron renderer APIs to the preload script
If the content you're loading in the BrowserView never needs to communicate back to the application, then you don't need a preload script at all and can just sandbox the BrowserView.
After looking at the security and best-practices page, I will also append the following steps:
deny session permission requests from remote content (webcam, microphone, location, etc.)
catch webview elements in creation and strip default privileges
disable the creation of new windows
disable the remote module
Sure, those sound reasonable. Note that if your embedded browser needs to be able to open new windows (via window.open or <a target="_blank" />) then you'd have to allow popups.
That is a fair amount of steps to undergo in securing external content.
Sure, but is your main concern with the security of the app, or with how much work it takes to make it secure? Browser developers need to consider similar things to ensure webpages can't get access to the OS. It's just part of the game.
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
This is just saying that if all you're trying to do is display a website, then just use a browser since that's what they're there for.
If you need to do other things, well then you can't use a browser, so you'll have to make your own app, making sure it's reasonably secure.
I think that if you follow what's recommended in the Security document and keep up to date with new Electron releases, then you're doing the best you can do.
As for whether that's good enough, I can't say. It depends on what you're developing and what you're trying to protect against.
However, my thoughts can't substitute the more expert opinions of those on the Electron team. This question could certainly use some guidance from them.
What is an easy way to write a browser application on Linux (Crunchbang/Debian)?
I need to write an application for some DOM editing and automation. My preferred way of doing this is to have my own browser object (like WebKit's WebView or System.Windows.Forms.WebBrowser) and access the DOM from there. I tried both (with mono), but I found two things:
WebView does not implement DOM access (ref)
System.Windows.Forms.WebBrowser does not work (ref)
This means Mono is not very suitable for this purpose.
What is your preferred way for accessing web pages, reading the DOM and automating navigation?
Probably easier to use PhantomJS?
Uses Webkit to render webpages and then makes the DOM available for you:
http://phantomjs.org
Is there a way to port existing HTML5 apps to WinJS without modifying libraries? Going through each library and wrapping innerHTML calls with execUnsafeLocalFunction is such a dirty hack.
Could I load the base page as unsafe some how? Loading everything in an iframe is just displaying an empty white box.
You should be able to make things work with an iframe if you put it in the right context with ms-appx-web:
<iframe src="ms-appx-web:///path/to/iframe.html"></iframe>
The downside is you won't be able to get at WinRT APIs from there. Unfortunately there isn't a way to selectively disable parts of SafeHTML. While you could globally disable it by doing some hacks to replace HTMLElement.innerHTML so that it calls execUnsafeLocalFunction implicitly, that would also open you up to script injection attacks which could cause your app to be rejected from the store.
Another option is to actually navigate the root page into the web context:
window.location.href = "ms-appx-web:///path/to/iframe.html";
I believe you then may be able to have an invisible iframe back to the local context (ms-appx) and use the postMessage API to communicate across the boundary as needed.
I know that Apple products like the iPad or the iPhone have trouble with flash apps.
What web development tools should I use in order to avoid compatibility issues when creating a website? My only constraint is that the languages must provide for interactivity and animation - such as in jQuery.
HTML, CSS, and PHP are a few that I can think of that will behave on 99% of all internet enabled devices.
What tools & languages are available to use when creating a website intended to be viewed on any device's internet "explorer"?
Should I just stick to HTML, CSS, & PHP? I want a certain level of interactivity so that, for example, a user can hover over images and have pop-ups containing data to appear... or when an object is clicked, an action can happen without a page reload.
Can someone point me in the right direction and help me develop a list of languages that are all-device friendly?
I am familiar with programming in several web-focused languages, I'm just wondering which ones to stay away from. Certain ones will limit the devices that can view the site and besides that constraint, the site needs to be interactive and animated.
HTML, CSS, PHP, JQUERY are truly your best bet for developing for a wide range of devices. If the scope of devices is the main goal I would stay away from using HTML5 and CSS3. You still may run into problems using much jquery with IE7 below. Mobile browsers on the other hand are much more advanced or up to date with standards then desktop browsers. I would suggest creating two versions of your application. One dedicated to running on mobile devices and one for desktop browsers. It is a shame apple wouldn't support flash applications. If all you need is hoovers for interaction you won't even need jquery / but for the other it will be useful.
The "Web" is a name for the concept of having interlinked documents accessible over the internet. Therefore, to have a website you really only need a document able to link to other documents, namely HTML.
HTML is not really a programming language or a tool though, it is a document format.
If you want to make a website you need use HTML to Markup what you're writing. Then you use CSS to format different sections of the document you marked up.
PHP though, is completely separate from this, PHP is for creating dynamic HTML, or any document on the server side.
If you want to achieve a flash-effect on a site you use Javascript to modify the page content (HTML) and appearance (CSS).
If you need to learn HTML/CSS I would highly recommend http://htmldog.com/
As per the question, HTML CSS and Javascript are pretty much the only mobile-browser compatible method for website content as they don't need plugins.
What exactly are you trying to do?
We have a .Net application that is used for editing/rendering customized HTML documents. It is hosted in IE using the AxSHDocVw.AxWebBrowser controls. We proceed with navigating to "about:blank" page initially then we change the Document by writing our custom values into it. The problem we are facing is the call to IHTMLTxtRange.execCommand("Copy",false,null) is failing if we don't enable the IE Security Settings in the Internet Security zone (Scripting->Allow Programmatic Access to Clipboard ).
In order to bypass the security setting ,I tried to point to a local html file initially while navigating. But this fails as soon as I modify the Document.
I want to use the IHTMLTxtRange.execCommand("Copy",false,null) command so that I can customize our Copy/Paste operations.
Is there any other way I can do this.
Please share your ideas inorder to overcome this situation.
Thanks.
Sriram
Try implement IInternetSecurityManager on your webbrowser control host, handle URLACTION_SCRIPT_PASTE in ProcessUrlAction.
Note there is a bug in earlier versions of IE that causes the webbrowser to ignore host's URLACTION_SCRIPT_PASTE handling.
As far as I know, there is no way to do that without user permission. Its a security/privacy loophole to allow access to clipboard, and its natural that browsers are protective about it.
You have already tried out ActiveX, and it doesn't work
With Flash, you can interact with system clipboard - but only if its a part of an event handler. See Flash Player 10 Security.
Javascript doesn't expose a way to access the clipboard.
Not sure about silverlight, but I am guessing it would also restrict access to clipboard.
In short, the user has to explicitly give your application/website permission to access clipboard.