Skip to content

Home

Jump to bottom
Luca Carettoni edited this page Mar 12, 2019 · 43 revisions

Welcome to Electronegativity Official Documentation

Electronegativity is a tool to identify misconfigurations and security anti-patterns in Electron-based applications. It leverages AST and DOM parsing to look for security-relevant configurations, as described in our Electron Security Checklist - A Guide for Developers and Auditors white-paper.

The Electron security white-paper introduces a checklist of security anti-patterns and must-have features to illustrate misconfigurations and vulnerabilities in Electron-based applications. Software developers and security auditors can benefit from this document as it provides a concise, yet comprehensive, summary of potential weaknesses and implementation bugs when developing applications using Electron. Based on this study, we developed Electronegativity to automate the discovery of those security anti-patterns.

Security Is Everyone's Responsibility

It is important to remember that the security of your Electron application is the result of the overall security of the framework foundation (Chromium, Node.js), Electron itself, all NPM dependencies and your code. In addition to all application code vulnerabilities potentially discovered by this tool, it is your responsibility to follow a few important best practices:

  • Keep your application up-to-date with the latest Electron framework release. When releasing your product, you’re also shipping a bundle composed of Electron, Chromium shared library and Node.js. Vulnerabilities affecting these components may impact the security of your application. By updating Electron to the latest version, you ensure that critical vulnerabilities (such as nodeIntegration bypasses) are already patched and cannot be exploited in your application.

  • Evaluate your dependencies. While NPM provides half a million reusable packages, it is your responsibility to choose trusted 3rd-party libraries. If you use outdated libraries affected by known vulnerabilities or rely on poorly maintained code, your application security could be in jeopardy.

  • Adopt secure coding practices. The first line of defense for your application is your own code. Common web vulnerabilities, such as Cross-Site Scripting (XSS), have a higher security impact on Electron applications hence it is highly recommended to adopt secure software development best practices and perform security testing.

Getting Started

While installing and using Electronegativity is fairly easy, the following section covers some of the details around the tool command line arguments and internal heuristics.

To get Electronegativity up and running, it's possible to use NPM since major releases are pushed to the repository:

$ npm install @doyensec/electronegativity -g

At this stage, the tool can be invoked by using the following command line:

$ electronegativity -i [TARGET]

Where [TARGET] is either the application source code directory, a single JavaScript file (.js), a single HTML file (.html), or an application ASAR package (.asar). In case of single files, the tool will only invoke checks that are relevant for the target. Please note that it is also possible to use wildcard * characters.

Since the tool can be used on both source code and application packages, it is easy to perform testing on both open-source and commercial applications.

In addition to the mandatory -i [TARGET] command line argument, the user can also specify the following options:

  • -o, --output This is used for selecting a different output type. By default, the application uses standard terminal output to display results in a compacted table. The user can select Comma-Separate file (CSV) or Sarif (SARIF) to obtain a more detailed description of the findings. SARIF stands for Static Analysis Results Interchange Format and it defines a standard format for the output of static analysis tools.

  • -c, --checks By default, the tool will run all checks on the target file(s). However, the user may be interested in specific classes of vulnerabilities only thus it is possible to select a list of checks (comma-separated) to be used. Checks are defined by its name (e.g. CSPJSCheck).

Electronegativity Checks

Electronegativity currently implements the following checks:

  1. AllowPopupCheck.js - ALLOWPOPUPS_HTML_CHECK
  2. AuxclickJSCheck.js - AUXCLICK_JS_CHECK
  3. AuxclickHTMLCheck.js - AUXCLICK_HTML_CHECK
  4. BlinkFeaturesJSCheck.js - BLINK_FEATURES_JS_CHECK
  5. BlinkFeaturesHTMLCheck.js - BLINK_FEATURES_HTML_CHECK
  6. CertificateErrorEventJSCheck.js - CERTIFICATE_ERROR_EVENT_JS_CHECK
  7. CertificateVerifyProcJSCheck.js - CERTIFICATE_VERIFY_PROC_JS_CHECK
  8. ContextIsolationJSCheck.js - CONTEXT_ISOLATION_JS_CHECK
  9. CustomArgumentsJSCheck.js - CUSTOM_ARGUMENTS_JS_CHECK
  10. CSPGlobalCheck.js - CSP_GLOBAL_CHECK
  11. DangerousFunctionsJSCheck.js - DANGEROUS_FUNCTIONS_JS_CHECK
  12. ElectronVersionJSCheck.js - ELECTRON_VERSION_JSON_CHECK
  13. ExperimentalFeaturesHTMLCheck.js - EXPERIMENTAL_FEATURES_HTML_CHECK
  14. ExperimentalFeaturesJSCheck.js - EXPERIMENTAL_FEATURES_JS_CHECK
  15. HTTPResourcesJSCheck.js - HTTP_RESOURCES_JS_CHECK
  16. HTTPResourcesHTMLCheck.js - HTTP_RESOURCES_HTML_CHECK
  17. InsecureContentHTMLCheck.js - INSECURE_CONTENT_HTML_CHECK
  18. InsecureContentJSCheck.js - INSECURE_CONTENT_JS_CHECK
  19. NodeIntegrationHTMLCheck.js - NODE_INTEGRATION_HTML_CHECK
  20. NodeIntegrationAttachEventJSCheck.js - NODE_INTEGRATION_ATTACH_EVENT_JS_CHECK
  21. NodeIntegrationJSCheck.js - NODE_INTEGRATION_JS_CHECK
  22. OpenExternalJSCheck.js - OPEN_EXTERNAL_JS_CHECK
  23. PermissionRequestHandlerJSCheck.js - PERMISSION_REQUEST_HANDLER_JS_CHECK
  24. PreloadJSCheck.js - PRELOAD_JS_CHECK
  25. ProtocolHandlersJSCheck.js - PROTOCOL_HANDLER_JS_CHECK
  26. SandboxJSCheck.js - SANDBOX_JS_CHECK
  27. WebSecurityHTMLCheck.js - WEB_SECURITY_HTML_CHECK
  28. WebSecurityJSCheck.js - WEB_SECURITY_JS_CHECK

This content is used within the tool to document findings and mitigations.

Clone this wiki locally