Skip to content

Latest commit

 

History

History
118 lines (89 loc) · 10.5 KB

mitigations.md

File metadata and controls

118 lines (89 loc) · 10.5 KB

Mitigation Strategies Analysis for nwjs/nw.js

Mitigation Strategy: Minimize Node.js Usage in Renderers

Mitigation Strategy: Restrict Node.js API access within renderer processes (web pages).

Description:

  1. Review package.json: Examine the package.json file. Look for the node-remote field. If it's present, it should only list specific Node.js modules that absolutely must be accessible from specific renderer processes. Ideally, node-remote should be avoided entirely.
  2. Check Window Configuration: In your main JavaScript file (where you create your main NW.js window), ensure that the window options do not include nodeIntegration: true or webviewTag: true without also having contextIsolation: true. These options, if misused, can enable Node.js in renderers.
  3. Audit Renderer Code: Thoroughly review all HTML, JavaScript, and CSS files that are loaded as part of your application's UI. Search for any direct calls to Node.js APIs (e.g., require('fs'), process.env, etc.). If found, refactor the code to use message passing (see strategy #3).
  4. Remove nodeIntegration from <webview> tags: If you are using <webview> tags, ensure they do not have the nodeintegration attribute.
  5. Remove nwdisable and nwfaketop from <webview> tags: If you are using <webview> tags, ensure they do not have the nwdisable and nwfaketop attributes.

Threats Mitigated:

  • Remote Code Execution (RCE) (Critical): If an attacker can inject malicious JavaScript into your renderer (e.g., via XSS), they could directly execute Node.js code, gaining full control over the user's system.
  • Cross-Site Scripting (XSS) (High, becomes Critical with Node.js access): XSS alone is a serious threat, but with Node.js access, it escalates to RCE.
  • Data Exfiltration (High): Node.js access allows attackers to read and potentially exfiltrate sensitive files from the user's system.
  • System Modification (High): Attackers could modify system files, install malware, or otherwise compromise the user's system.

Impact:

  • RCE: Risk reduced from Critical to (ideally) Negligible. The primary attack vector is eliminated.
  • XSS: Severity reduced from Critical (potential RCE) to High (still a serious threat, but limited to the renderer context).
  • Data Exfiltration/System Modification: Risk significantly reduced, as direct access to system resources is removed.

Currently Implemented:

  • package.json: node-remote is not used. nodeIntegration is set to false globally. contextIsolation is set to true globally.
  • Main Window Configuration: nodeIntegration: false, contextIsolation: true are explicitly set.
  • Renderer Code: A preliminary review has been done, but a full audit is pending.

Missing Implementation:

  • Renderer Code: A complete audit of all renderer code is required to definitively confirm that no direct Node.js calls are present. This is a high-priority task.
  • <webview> tags: Need to check all instances of <webview> tags.

Mitigation Strategy: Enforce Context Isolation

Mitigation Strategy: Ensure contextIsolation is enabled.

Description:

  1. Verify package.json: Check your package.json file. contextIsolation should be set to true (or not explicitly set to false, as it's true by default in recent NW.js versions). It's best to explicitly set it to true for clarity.
  2. Window Configuration: In your main window creation code, double-check that contextIsolation: true is set in the window options.
  3. Testing: Attempt to access Node.js APIs directly from your renderer code (e.g., in the browser's developer console). If contextIsolation is working, these attempts should fail.

Threats Mitigated:

  • RCE (Critical): Even if an attacker manages to inject code that tries to use Node.js, contextIsolation prevents direct access, significantly mitigating RCE.
  • XSS (High, becomes Critical without context isolation): Similar to the previous strategy, it reduces the impact of XSS.
  • Bypass of Message Passing Security (High): If your message passing system (see #3) has vulnerabilities, contextIsolation provides a second layer of defense, preventing direct access even if the messaging system is compromised.

Impact:

  • RCE: Risk significantly reduced, acting as a crucial second layer of defense even if other mitigations fail.
  • XSS: Severity reduced from Critical to High.
  • Bypass of Message Passing: Provides significant protection against vulnerabilities in the message passing system.

Currently Implemented:

  • package.json: contextIsolation: true is explicitly set.
  • Main Window Configuration: contextIsolation: true is explicitly set.
  • Basic Testing: Initial tests confirm that Node.js APIs are not directly accessible from the renderer.

Missing Implementation:

  • More comprehensive testing is needed to ensure that there are no edge cases or bypasses of contextIsolation.

Mitigation Strategy: Implement Strict Message Passing (Preload Scripts)

Mitigation Strategy: Use a well-defined message passing system via preload scripts.

Description:

  1. Create Preload Scripts: Create JavaScript files that will act as intermediaries. These scripts will be loaded into a context that can access Node.js. These are NW.js specific, as they leverage the NW.js runtime's ability to bridge Node.js and the browser.
  2. Define Allowed Messages: Create a strict protocol for the messages that can be exchanged between the renderer and the preload script (and, by extension, the main process). This should be a whitelist of allowed message types and data structures.
  3. Implement Message Handlers:
    • Preload Script: Use chrome.runtime.onMessage.addListener (or a similar mechanism) to listen for messages from the renderer. Validate every message against the allowed protocol. If a message is valid, perform the requested action (using Node.js APIs if necessary) and send a response back to the renderer.
    • Renderer: Use window.postMessage to send messages to the preload script. Listen for responses using window.addEventListener('message', ...) and validate the responses.
    • Main Process (Optional): If your preload script needs to communicate with the main Node.js process, use ipcRenderer.send and ipcMain.on (from the electron module, which is available in NW.js) for communication. Apply the same strict validation to these messages.
  4. Expose Limited API: In your preload script, use contextBridge.exposeInMainWorld to expose only the necessary functions to the renderer. These functions should be simple wrappers that send messages to the preload script's message handler. This is a key NW.js/Electron feature.
  5. Validate All Input: Treat all data received from the renderer as untrusted. Validate data types, lengths, and formats before using them in any Node.js operations.

Threats Mitigated:

  • RCE (Critical): By controlling the communication between the renderer and Node.js, you prevent arbitrary code execution.
  • Data Exfiltration/System Modification (High): Limits the actions that can be performed via Node.js, reducing the risk of unauthorized access to system resources.
  • Injection Attacks (High): Strict message validation prevents attackers from injecting malicious data that could be misinterpreted by the Node.js side.

Impact:

  • RCE: Risk significantly reduced, as the attack surface is limited to the defined message protocol.
  • Data Exfiltration/System Modification: Risk reduced by limiting the available Node.js operations.
  • Injection Attacks: Risk significantly reduced through strict message validation.

Currently Implemented:

  • Basic Preload Script: A basic preload script exists, but it's not fully implemented.
  • Message Handlers: Skeleton message handlers are in place, but they lack robust validation.
  • contextBridge: contextBridge is being used, but the exposed API needs to be reviewed and minimized.

Missing Implementation:

  • Strict Message Protocol: A formal, documented message protocol is needed.
  • Robust Validation: All message handlers need to implement thorough input validation.
  • API Minimization: The API exposed by contextBridge needs to be carefully reviewed and reduced to the absolute minimum.
  • Main Process Communication: If communication with the main process is required, it needs to be implemented with the same security considerations.

Mitigation Strategy: Disable Unnecessary Chromium Features

Mitigation Strategy: Use Chromium command-line switches to disable unneeded features.

Description:

  1. Identify Unnecessary Features: Review the list of Chromium command-line switches (available online). Determine which features your application does not need. Examples include plugins, extensions, WebRTC, remote fonts, etc.
  2. Modify package.json: Add the "chromium-args" field to your package.json. Set its value to a string containing the desired command-line switches, separated by spaces. For example: "chromium-args": "--disable-plugins --disable-extensions". This is NW.js specific, as it leverages the underlying Chromium engine.
  3. Testing: Test your application thoroughly after disabling features to ensure that functionality is not broken.

Threats Mitigated:

  • Vulnerabilities in Chromium Components (Variable Severity): Reduces the attack surface by removing potential vulnerabilities in unused Chromium features. The severity depends on the specific features disabled and the vulnerabilities they might contain.
  • Resource Consumption (Low): Disabling unnecessary features can slightly improve performance and reduce memory usage.

Impact:

  • Vulnerabilities: Risk reduction is variable, but generally beneficial. It's a defense-in-depth measure.
  • Resource Consumption: Minor positive impact.

Currently Implemented:

  • package.json: "chromium-args": "--disable-plugins" is currently set.

Missing Implementation:

  • A comprehensive review of Chromium features is needed to identify other features that can be safely disabled. This should be based on a thorough understanding of the application's requirements.