github-actions[bot] 012e2c7a1b
Create rule S7071 (#4253)
* 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>
2024-09-17 10:17:36 +02:00

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