- Electron Js Security Checklist
- Risk
If enabled, nodeIntegration allows JavaScript to leverage Node.js primitives and modules. This could lead to full remote system compromise if you are rendering untrusted content. Auditing nodeIntegration and nodeIntegrationInWorker are boolean options that can be used to determine whether node integration is enabled.
Auditing
For BrowserWindow, default is true. If the option is not present, or is set to true/1, nodeIntegration is enabled as in the following examples:
mainWindow = new BrowserWindow({ "webPreferences": { "nodeIntegration": true, “nodeIntegrationInWorker": 1 } });
Or simply:
mainWindow = new BrowserWindow() For webview tag, default is false.
When this attribute is present, the guest page in webview will have node integration: When sanbox is enabled (see below), nodeintegration is disabled. Please note that it is also possible to use the will-attach-webview event to verify (and potentially change) any attribute of webPreferences.This event is emitted when a webview is being attached to the web content. Since this mechanism can be used to change the webPreferences configuration, please carefully review the implementation of the callback.At the same time, this is a powerful mechanism to validate all settings and ensure a secure instance of webview, as demonstrated in this implementation:app.on('web-contents-created', (event, contents) => {
contents.on('will-attach-webview', (event, webPreferences, params) => {
// Strip away preload scripts if unused // Alternatively, verify their location if legitimate delete
webPreferences.preload delete webPreferences.preloadURL /
/ Disable node integration
webPreferences.nodeIntegration = false
// Verify URL being loaded
if (!params.src.startsWith('https://www.example.com/')) { event.preventDefault() } }) })
Reference :
- Review the use of preload scripts
Risk
Improper use of preload scripts can introduce nodeIntegration or sandbox bypasses, in addition to other vulnerabilities. If context isolation is not used, there is a risk that malicious code in preload scripts could tamper JavaScript native functions that the preload script and Electron APIs make use of.
Auditing
Search for preload within the webPreferences of BrowserWindow. Manually review the imported scripts. If preload is used, make sure that webPreferences also includes contextIsolation: true or contextIsolation: 1
- Do not use insertCSS, executeJavaScript or eval with user-supplied content
Risk
In a vulnerable application, a remote page could leverage these functions to subvert the flow of the application by injecting malicious CSS or JavaScript.
Auditing
Search for occurrences of insertCSS, executeJavaScript and eval in both BrowserWindow, webview tag and all other JavaScript resources. - Do not allow popups in webview
Risk
Disabling popups reduces the risk of UI-redressing attacks and limits the exploitability of window abuses. Additionally, popups are often used for intrusive advertising and persistency in JavaScript-based attacks.
Auditing
Search for occurrences of allowpopups in webview tags: <webview src="https://example.com/"allowpoups></webview>
- Review the use of custom protocol handlers
Shell’s openExternal() allows opening a given external protocol URI with the desktop’s native utilities. For instance, on macOS, this function is similar to the ‘open’ terminal command utility and will open the specific application based on the URI and filetype association. When openExternal is used with untrusted content, it can be leveraged to execute arbitrary commands, as demonstrated by the following example:
Risk
The use of custom protocol handlers opens the application to vulnerabilities triggered by users clicking on custom links or arbitrary origins forcing the navigation to crafted links.
Auditing
To register a custom protocol handler, it is necessary to use one of the following functions:
• setAsDefaultProtocolClient
• registerStandardSchemes
• registerServiceWorkerSchemes
• registerFileProtocol
• registerHttpProtocol
• registerStringProtocol
• registerBufferProtocol
Search for those occurrences and manually review the implementation. - Review the use of command line arguments
Risk
The use of additional command line arguments can increase the application attack surface, disable security features or influence the overall security posture. For example, if Electron’s debugging is enabled, Electron will listen for V8 debugger protocol messages on the specified port. An attacker could leverage the external debugger to subvert the application at runtime.
Auditing
Review all occurrences of appendArgument and appendSwitch:
const {app} = require('electron')
app.commandLine.appendArgument(‘debug’)
app.commandLine.appendSwitch(‘proxy-server', '8080')
Search for custom arguments (e.g. —debug or —debug-brk) in package.json, and within the application codebase.
- Constantly and regularly inspect for vulnerable dependencies
- Escape HTML,JS & CSS Output
- Do not allow insecure HTTP connections/Only load Secure Content
- Isolation of Untrusted Content
- Enable Contect Isolation for remote Content
- Context Isolation
- Handle session permission requests from remote content
- Donot Disable Websecurity
- Define Content Security Policy
- Do not set allowrunninginsecurecontent to true
- Do not Enable Experimental Features
- Do not use enableblinkfeatures
- Donot use allowpoups
- Verify webview option before creation
- Disable Limit Navigation
- Disable Limit creation of windows
- Donot use openExternal with un-trusted content
- Disable remote module
- Filter remote module
- Use a Current Version of Electron
Reference :
https://www.electronjs.org/docs/tutorial/security
https://doyensec.com/resources/us-17-Carettoni-Electronegativity-A-Study-Of-Electron-Security-wp.pdf
Comments
Post a Comment