Skip to main content

Electron JS Security Checklist

  • 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 : 

    https://www.electronjs.org/docs/tutorial/security#2-do-not-enable-nodejs-integration-for-remote-content

    https://www.electronjs.org/docs/tutorial/context-isolation

 

  • 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.

Reference :

https://www.electronjs.org/docs/tutorial/security

https://doyensec.com/resources/us-17-Carettoni-Electronegativity-A-Study-Of-Electron-Security-wp.pdf


Comments

Popular posts from this blog

WordPress Common Issue Notes

  WordPress: /wp-content/plugins/sfwd-lms/wpml-config.xml /wp-content/plugins/omni-secure-files/plupload/examples/upload.php /wp-content/plugins/contus-hd-flv-player/uploadVideo.php wp-json/th/v1/user_generation /wp-admin/admin-ajax.php?do_reset_wordpress=1 Wordpress xmlrpc.php -common vulnerabilites & how to exploit them https://medium.com/@the.bilal.rizwan/wordpress-xmlrpc-php-common-vulnerabilites-how-to-exploit-them-d8d3c8600b32

SSRF Notes

SSRF Notes NOTE :   Wanted to have everything at one place,  these are my reference notes from various bug bounty write ups & security  research, I thank all the authors of the write ups mentioned below  [will update if i find anything interesting] Description In an SSRF attack against the server itself, the attacker induces the  application to make an HTTP request back to the server that is hosting  the application, via its loopback network interface. This will typically  involve supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a commonly used name for the same adapter).           Many server-side request forgery vulnerabilities are relatively easy to  spot, because the application's normal traffic involves request  parameters containing full URLs Blind SSRF Blind SSRF vulnerabilities arise...