206ec4612b
* Create rule S7080 * Add rule description for S7080 * Fixes following review * Add securityStandards --------- Co-authored-by: sebastien-andrivet-sonarsource <sebastien-andrivet-sonarsource@users.noreply.github.com> Co-authored-by: Sebastien Andrivet <sebastien.andrivet@sonarsource.com>
187 lines
6.4 KiB
Plaintext
187 lines
6.4 KiB
Plaintext
The Content Security Policy (CSP) is a computer security standard that serves as
|
|
an additional layer of protection against various types of attacks.
|
|
|
|
== Why is this an issue?
|
|
|
|
The Content Security Policy (CSP) helps protect against various types of attacks,
|
|
including Cross-Site Scripting (XSS) and clickjacking. It provides a set of standard
|
|
procedures for loading resources by user agents, which can help to mitigate the
|
|
risk of content injection vulnerabilities.
|
|
|
|
However, it is important to note that CSP is not a primary line of defense, but
|
|
rather a safety net that catches attempts to exploit vulnerabilities that exist
|
|
in the application despite other protective measures. An insecure CSP does not
|
|
automatically imply that the website is vulnerable, but it does mean that this
|
|
additional layer of protection is weakened.
|
|
|
|
A CSP can be considered insecure if it allows potentially harmful practices,
|
|
such as inline scripts or loading resources from arbitrary domains. These
|
|
practices can increase the risk of content injection attacks.
|
|
|
|
=== What is the potential impact?
|
|
|
|
An insecure Content Security Policy (CSP) can increase the potential severity of
|
|
other vulnerabilities in the application. For instance, if an attacker manages to
|
|
exploit a Cross-Site Scripting (XSS) vulnerability, an insecure CSP might not
|
|
provide the intended additional protection.
|
|
|
|
==== Code Execution
|
|
|
|
XSS can be used to perform actions on behalf of the user without their
|
|
consent, such as changing their email address or password, or making
|
|
transactions. This can lead to unauthorized access and potential loss of control
|
|
over user accounts.
|
|
|
|
==== Phishing Attacks
|
|
|
|
Attackers can create convincing phishing pages within the application.
|
|
These pages can trick users into providing sensitive information, believing
|
|
they are interacting with a legitimate part of the application.
|
|
|
|
==== Data leakage
|
|
|
|
XSS allows an attacker to inject malicious scripts into webviews. These scripts can
|
|
then be used to steal sensitive information like session cookies, personal data,
|
|
or credit card details, leading to identity theft or financial fraud.
|
|
|
|
In addition, an insecure CSP that allows loading resources from arbitrary
|
|
domains could potentially expose sensitive user data to untrusted sources. This
|
|
could lead to data breaches, which can have serious legal and reputational
|
|
consequences.
|
|
|
|
== How to fix it in Electron
|
|
|
|
CSP's preferred delivery mechanism is an HTTP header. However, if is not possible
|
|
(like when loading a resource using the `+file://+` protocol), it is possible to set
|
|
a policy of a page directly in the markup using a `+<meta>+` tag.
|
|
|
|
=== Code examples
|
|
|
|
==== Noncompliant code example
|
|
|
|
[source,javascript,diff-id=1,diff-type=noncompliant]
|
|
----
|
|
app.whenReady().then(() => {
|
|
createWindow()
|
|
})
|
|
----
|
|
|
|
[source,html,diff-id=2,diff-type=noncompliant]
|
|
----
|
|
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8" />
|
|
<title>An example</title>
|
|
</head> <!-- Noncompliant -->
|
|
<body>
|
|
...
|
|
</body>
|
|
</html>
|
|
----
|
|
|
|
|
|
==== Compliant solution
|
|
|
|
[source,javascript,diff-id=1,diff-type=compliant]
|
|
----
|
|
app.whenReady().then(() => {
|
|
session.defaultSession.webRequest.onHeadersReceived((details, callback) => {
|
|
callback({responseHeaders: {
|
|
...details.responseHeaders,
|
|
'Content-Security-Policy': ['default-src \'self\'; script-src \'self\' https://demo.demo1.org']
|
|
}})
|
|
})
|
|
createWindow()
|
|
})
|
|
----
|
|
|
|
[source,html,diff-id=2,diff-type=compliant]
|
|
----
|
|
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8" />
|
|
<meta
|
|
http-equiv="Content-Security-Policy"
|
|
content="default-src 'self'; script-src 'self' https://demo.demo1.org"
|
|
/>
|
|
<title>An example</title>
|
|
</head>
|
|
<body>
|
|
...
|
|
</body>
|
|
</html>
|
|
----
|
|
|
|
|
|
=== How does this work?
|
|
|
|
Content Security Policy (CSP) can either be enabled in HTML code with a `+<meta>+`
|
|
tag or in the Javascript code of the Electron application by declaring a `+onHeadersReceived()+`
|
|
handler. When loading a resource using the `+file://+` protocol, the CSP has to be
|
|
set using a `+<meta>+` tag.
|
|
|
|
CSP should adhere to the principle of least privilege. This principle states
|
|
that an application should be given
|
|
the minimum levels of access necessary to complete its tasks. In the context
|
|
of CSP, this means restricting the sources from which content can be loaded to
|
|
the minimum necessary.
|
|
|
|
Here are some steps to secure your CSP:
|
|
|
|
* Avoid 'unsafe-inline' and 'unsafe-eval': These settings allow inline scripts
|
|
and script evaluation, which can open the door for executing malicious scripts.
|
|
Instead, use script hashes, nonces, or strict dynamic scripting if scripts must
|
|
be used.
|
|
* Specify exact sources: Rather than using a wildcard (*) which allows any domain,
|
|
specify the exact domains from which resources can be loaded. This reduces the
|
|
risk of loading resources from potentially malicious sources.
|
|
* Use 'self' cautiously: While 'self' is safer than a wildcard, it can still lead
|
|
to vulnerabilities if your own site has been compromised or hosts user-uploaded
|
|
content. Be sure to validate and sanitize all user content.
|
|
|
|
== Resources
|
|
|
|
=== Documentation
|
|
|
|
* Electron Documentation - https://www.electronjs.org/docs/latest/tutorial/security#7-define-a-content-security-policy[Security - Define a Content Security Policy]
|
|
* MDN web docs - https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP[Content Security Policy (CSP)]
|
|
* CSP docs - https://content-security-policy.com/hash/[Using a hash with CSP]
|
|
|
|
//=== Articles & blog posts
|
|
//=== Conference presentations
|
|
|
|
=== Standards
|
|
|
|
* OWASP - https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[Top 10 2021 Category A5 - Security Misconfiguration]
|
|
* OWASP - https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration.html[Top 10 2017 Category A6 - Security Misconfiguration]
|
|
* CWE - https://cwe.mitre.org/data/definitions/693[CWE-693 - Protection Mechanism Failure]
|
|
* STIG Viewer - https://stigviewer.com/stig/application_security_and_development/2023-06-08/finding/V-222602[Application Security and Development: V-222602] - The application must protect from Cross-Site Scripting (XSS) vulnerabilities.
|
|
|
|
=== External coding guidelines
|
|
|
|
* Google - https://csp-evaluator.withgoogle.com/[CSP Evaluator]
|
|
|
|
//=== Benchmarks
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
* Add a Content Security Policy (CSP).
|
|
|
|
=== Highlighting
|
|
|
|
Highlight the `</header>` closing tag in web pages.
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
endif::env-github,rspecator-view[]
|