From ef80aeb0bf50a2d7cad32e6a53f427b4256d5883 Mon Sep 17 00:00:00 2001 From: hendrik-buchwald-sonarsource <64110887+hendrik-buchwald-sonarsource@users.noreply.github.com> Date: Tue, 23 Aug 2022 16:23:58 +0200 Subject: [PATCH] [Education] Modify rule S5131: Improve language (#1177) --- rules/S5131/common/fix/data_encoding.adoc | 10 +++++----- rules/S5131/common/pitfalls/validation.adoc | 2 +- rules/S5131/impact.adoc | 2 +- rules/S5131/java/how-to-fix-it/thymeleaf.adoc | 2 +- rules/S5131/rationale.adoc | 4 ++-- rules/S5131/threats.adoc | 5 ++++- 6 files changed, 14 insertions(+), 11 deletions(-) diff --git a/rules/S5131/common/fix/data_encoding.adoc b/rules/S5131/common/fix/data_encoding.adoc index 1ad5da7a8c..4b96aab404 100644 --- a/rules/S5131/common/fix/data_encoding.adoc +++ b/rules/S5131/common/fix/data_encoding.adoc @@ -1,9 +1,9 @@ ==== Encode data according to the HTML context -The best approach to protect against XSS is to systematically encode data that are written to HTML documents. -The goal is to leave the data intact from the end user's point of view but makes it uninterpretable by web browsers. +The best approach to protect against XSS is to systematically encode data that is written to HTML documents. +The goal is to leave the data intact from the end user's point of view but make it uninterpretable by web browsers. -XSS exploitation techniques vary depending on the HTML context where malicious inputs are injected. For each HTML context, there is a specific encoding to prevent JavaScript code from being interpreted. +XSS exploitation techniques vary depending on the HTML context where malicious input is injected. For each HTML context, there is a specific encoding to prevent JavaScript code from being interpreted. The following table summarizes the encoding to apply for each HTML context. [options="header",cols="a,a,a,a"] @@ -85,7 +85,7 @@ HTML entity encoding: replace the following characters with HTML-safe sequences. ... ---- -| *Dangerous context*: no output encoding will prevent XSS fully. +| *Dangerous context*: HTML output encoding will not prevent XSS fully. | In a URL attribute @@ -124,7 +124,7 @@ HTML entity encoding: replace the following characters with HTML-safe sequences. alert(1) ---- -| *Dangerous context*: no output encoding will prevent XSS fully. +| *Dangerous context*: HTML output encoding will not prevent XSS fully. To pass values to a JavaScript context, the recommended way is to use a data attribute: [source,html] diff --git a/rules/S5131/common/pitfalls/validation.adoc b/rules/S5131/common/pitfalls/validation.adoc index 27f253501b..78ce3a8c69 100644 --- a/rules/S5131/common/pitfalls/validation.adoc +++ b/rules/S5131/common/pitfalls/validation.adoc @@ -2,7 +2,7 @@ Validation of user inputs is a good practice to protect against various injection attacks. But for XSS, validation on its own is not the recommended approach. -As an example, filtering out user inputs based on a deny-list will never fully prevent XSS vulnerability from being exploited. This practice is sometimes used by web application firewalls. It's only a matter of time for malicious users to find the exploitation payload that will defeat the filters. +As an example, filtering out user inputs based on a deny-list will never fully prevent XSS vulnerability from being exploited. This practice is sometimes used by web application firewalls. It is only a matter of time for malicious users to find the exploitation payload that will defeat the filters. Another example is applications that allow users or third-party services to send HTML content to be used by the application. A common approach is trying to parse HTML and strip sensitive HTML tags. Again, this deny-list approach is vulnerable by design: maintaining a list of sensitive HTML tags, in the long run, is very difficult. diff --git a/rules/S5131/impact.adoc b/rules/S5131/impact.adoc index da095a19f5..07937e04d1 100644 --- a/rules/S5131/impact.adoc +++ b/rules/S5131/impact.adoc @@ -2,7 +2,7 @@ A well-intentioned user opens a malicious link that injects data into the web application. This data can be text, but it can also be arbitrary code that can -be interpreted by the target user's browser, such as HTML, CSS, or Javascript. +be interpreted by the target user's browser, such as HTML, CSS, or JavaScript. Below are some real-world scenarios that illustrate the various effects of an attacker exploiting the vulnerability. diff --git a/rules/S5131/java/how-to-fix-it/thymeleaf.adoc b/rules/S5131/java/how-to-fix-it/thymeleaf.adoc index bb64c542f2..0af687e56a 100644 --- a/rules/S5131/java/how-to-fix-it/thymeleaf.adoc +++ b/rules/S5131/java/how-to-fix-it/thymeleaf.adoc @@ -30,7 +30,7 @@ h| Compliant solution include::../../common/fix/data_encoding.adoc[] -For HTML encoding, Javascript encoding, and CSS encoding, the documentation +For HTML encoding, JavaScript encoding, and CSS encoding, the documentation allows the use of `unescaped text`, in only two different ways: * with the attribute `th:utext`. diff --git a/rules/S5131/rationale.adoc b/rules/S5131/rationale.adoc index e79d598c48..0aefef4bd4 100644 --- a/rules/S5131/rationale.adoc +++ b/rules/S5131/rationale.adoc @@ -1,7 +1,7 @@ -Reflected cross-site scripting (XSS) occurs in a web application when the application retrieves data (e.g., parameters or headers) from an incoming HTTP request and inserts it into its HTTP response without first sanitizing it. The most common cause is the insertion of GET parameters. +Reflected cross-site scripting (XSS) occurs in a web application when the application retrieves data like parameters or headers from an incoming HTTP request and inserts it into its HTTP response without first sanitizing it. The most common cause is the insertion of GET parameters. // image:common/images/browser.png[] -When a well-intentioned user opens a link to a page that is vulnerable to reflected XSS, they are exposed to attacks that target their own browser. +When well-intentioned users open a link to a page that is vulnerable to reflected XSS, they are exposed to attacks that target their own browser. A user with malicious intent carefully crafts the link beforehand. // Here is an example: diff --git a/rules/S5131/threats.adoc b/rules/S5131/threats.adoc index c63be9743d..9bcff14870 100644 --- a/rules/S5131/threats.adoc +++ b/rules/S5131/threats.adoc @@ -5,16 +5,19 @@ the user who is the victim. This may result in loss of integrity and theft of the benevolent user's data. ==== Identity spoofing + The forged link injects malicious code into the web application. The code enables identity spoofing thanks to cookie theft. ==== Record user activity + The forged link injects malicious code into the web application. To leak confidential information, attackers can inject code that records keyboard activity (keylogger) and even requests access to other devices, such as the camera or microphone. -==== Chaining XSS with other vulnerabilities +==== Chaining XSS with other vulnerabilities + In many cases, bug hunters and attackers chain cross-site scripting vulnerabilities with other vulnerabilities to maximize their impact. + For example, an XSS can be used as the first step to exploit more dangerous