![github-actions[bot]](/assets/img/avatar_default.png)
* Create rule S7071 * Initial draft --------- Co-authored-by: daniel-teuchert-sonarsource <daniel-teuchert-sonarsource@users.noreply.github.com> Co-authored-by: Daniel Teuchert <daniel.teuchert@sonarsource.com> Co-authored-by: daniel-teuchert-sonarsource <141642369+daniel-teuchert-sonarsource@users.noreply.github.com>
110 lines
3.4 KiB
Plaintext
110 lines
3.4 KiB
Plaintext
== Why is this an issue?
|
|
|
|
Chromium uses process sandboxing to separate components that are part of
|
|
its attack surface from the rest of the application. Since Electron uses
|
|
Chromium internally, the same sandboxing principle is used here for the
|
|
renderers and for preload scripts.
|
|
|
|
Renderer sandboxing is a critical component of the security model of
|
|
Electron. Within the renderer, it is only possible to access a limited
|
|
subset of APIs. Any privileged actions, e.g. filesystem interactions or
|
|
spawning subprocesses, have to be executed through IPC with the main
|
|
process. If renderer sandboxing is disabled, then an attacker who gains
|
|
code execution within the renderer (for example through XSS) can pivot
|
|
this easily into file system access and RCE.
|
|
|
|
=== What is the potential impact?
|
|
|
|
If sandboxing is not enabled in an Electron application, the potential
|
|
impact can be severe and multifaceted:
|
|
|
|
==== Security Breaches
|
|
Malicious code running within the application can gain unrestricted access
|
|
to system resources, leading to unauthorized data access, data exfiltration,
|
|
or even complete system compromise.
|
|
|
|
==== Data Integrity
|
|
Without sandboxing, there is a higher risk of data corruption or manipulation,
|
|
as malicious scripts can interfere with the application's data handling processes.
|
|
|
|
==== User Privacy
|
|
Sensitive user information, such as personal data, credentials,
|
|
and other private information, can be exposed to unauthorized access, leading
|
|
to privacy violations.
|
|
|
|
==== Reputation Damage
|
|
Security incidents can lead to a loss of user trust and damage the reputation
|
|
of the organization responsible for the application, resulting in potential
|
|
financial and reputational losses.
|
|
|
|
|
|
== How to fix it
|
|
|
|
=== Code examples
|
|
|
|
==== Noncompliant code example
|
|
|
|
Setting the `sandbox` property of `webPreferences` to false or setting
|
|
`nodeIntegration` to true will result in a configuration that will not be sandboxed.
|
|
|
|
[source,javascript,diff-id=1,diff-type=noncompliant]
|
|
----
|
|
const win = new BrowserWindow({
|
|
webPreferences: {
|
|
sandbox: false // Noncompliant
|
|
}
|
|
})
|
|
----
|
|
|
|
[source,javascript,diff-id=2,diff-type=noncompliant]
|
|
----
|
|
const win = new BrowserWindow({
|
|
webPreferences: {
|
|
nodeIntegration: true // Noncompliant
|
|
}
|
|
})
|
|
----
|
|
|
|
==== Compliant solution
|
|
|
|
[source,javascript,diff-id=1,diff-type=compliant]
|
|
----
|
|
const win = new BrowserWindow({
|
|
webPreferences: {
|
|
sandbox: true
|
|
}
|
|
})
|
|
----
|
|
|
|
[source,javascript,diff-id=2,diff-type=compliant]
|
|
----
|
|
const win = new BrowserWindow({
|
|
webPreferences: {
|
|
nodeIntegration: false
|
|
}
|
|
})
|
|
----
|
|
|
|
=== How does this work?
|
|
|
|
In the compliant examples `sandbox` or `nodeIntegration` are explicitly
|
|
set to their secure value. It is also sufficient to not set any of these
|
|
properties since they will default to secure values.
|
|
|
|
//=== Pitfalls
|
|
|
|
//=== Going the extra mile
|
|
|
|
|
|
== Resources
|
|
=== Documentation
|
|
* Electron Documentation - https://www.electronjs.org/docs/latest/tutorial/sandbox[Process Sandboxing]
|
|
* Electron Documentation - https://www.electronjs.org/docs/latest/tutorial/security#2-do-not-enable-nodejs-integration-for-remote-content[Security - Do not enable NodeJS integration for remote content]
|
|
* Electron Documentation - https://www.electronjs.org/docs/latest/tutorial/security#4-enable-process-sandboxing[Security - Enable process sandboxing]
|
|
|
|
//=== Articles & blog posts
|
|
//=== Conference presentations
|
|
//=== Standards
|
|
//=== External coding guidelines
|
|
//=== Benchmarks
|