Update metadata (#4124)

css-sonarpedia/sonarpedia.json

@@ -3,7 +3,7 @@
   "languages": [
     "CSS"
   ],
-  "latest-update": "2023-08-22T10:03:45.701595900Z",
+  "latest-update": "2023-09-01T11:54:21.651165Z",
   "options": {
     "no-language-in-filenames": true
   }

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2699.html

@@ -8,7 +8,7 @@ <h2>Why is this an issue?</h2>
 <p>Without assertions, a unit test doesn’t actually verify anything, making it ineffective in catching potential bugs or regressions. It will always
 pass, regardless of the implementation of the unit. This can lead to a false sense of security, as you may believe that your code is working correctly
 when it might not be.</p>
-<p>This rule raises an issue when the assertion library <code>chai</code> is imported but no assertion is used in a test.</p>
+<p>This rule raises an issue when the assertion library <code>chai</code> or <code>sinon</code> is imported but no assertion is used in a test.</p>
 <pre data-diff-id="1" data-diff-type="noncompliant">
 const expect = require("chai").expect;
 
@@ -34,5 +34,6 @@ <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
   <li> <a href="https://www.chaijs.com/api/">Chai.js - API Reference</a> </li>
+  <li> <a href="https://sinonjs.org/releases/latest/assertions/">Sinon.JS - Assertions</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5689.html

@@ -1,36 +1,50 @@
-<p>Disclosing technology fingerprints allows an attacker to gather information about the technologies used to develop the web application and to
-perform relevant security assessments more quickly (like the identification of known vulnerable components).</p>
+<p>Disclosure of version information, usually overlooked by developers but disclosed by default by the systems and frameworks in use, can pose a
+significant security risk depending on the production environement.</p>
+<p>Once this information is public, attackers can use it to identify potential security holes or vulnerabilities specific to that version.</p>
+<p>Furthermore, if the published version information indicates the use of outdated or unsupported software, it becomes easier for attackers to exploit
+known vulnerabilities. They can search for published vulnerabilities related to that version and launch attacks that specifically target those
+vulnerabilities.</p>
 <h2>Ask Yourself Whether</h2>
 <ul>
-  <li> The <code>x-powered-by</code> HTTP header or similar is used by the application. </li>
-  <li> Technologies used by the application are confidential and should not be easily guessed. </li>
+  <li> Version information is accessible to end users. </li>
+  <li> Internal systems do not benefit from timely patch management workflows. </li>
 </ul>
 <p>There is a risk if you answered yes to any of these questions.</p>
 <h2>Recommended Secure Coding Practices</h2>
-<p>It’s recommended to not disclose technologies used on a website, with <code>x-powered-by</code> HTTP header for example.</p>
-<p>In addition, it’s better to completely disable this HTTP header rather than setting it a random value.</p>
+<p>In general, it is recommended to keep internal technical information within internal systems to control what attackers know about the underlying
+architectures. This is known as the "need to know" principle.</p>
+<p>The most effective solution is to remove version information disclosure from what end users can see, such as the "x-powered-by" header.<br> This
+can be achieved directly through the web application code, server (nginx, apache) or firewalls.</p>
+<p>Disabling the server signature provides additional protection by reducing the amount of information available to attackers. Note, however, that
+this does not provide as much protection as regular updates and patches.<br> Security by obscurity is the least foolproof solution of all. It should
+never be the only defense mechanism and should always be combined with other security measures.</p>
 <h2>Sensitive Code Example</h2>
-<p><a href="https://www.npmjs.com/package/express">Express.js</a> name is disclosed by default into the <code>x-powered-by</code> HTTP header:</p>
+<p>In <a href="https://www.npmjs.com/package/express">Express.js</a>, version information is disclosed by default in the <code>x-powered-by</code>
+HTTP header:</p>
 <pre>
 let express = require('express');
-let app = express(); // Sensitive
 
-app.get('/', function (req, res) {
-  res.send('hello')
+let example = express(); // Sensitive
+
+example.get('/', function (req, res) {
+  res.send('example')
 });
 </pre>
 <h2>Compliant Solution</h2>
 <p><code>x-powered-by</code> HTTP header should be disabled in <a href="https://www.npmjs.com/package/express">Express.js</a> with
-<code>app.disable</code> or with helmet <a href="https://www.npmjs.com/package/helmet">hidePoweredBy</a> middleware:</p>
+<code>app.disable</code>:</p>
 <pre>
 let express = require('express');
 
-let app1 = express();  // Compliant
-app1.disable("x-powered-by");
-
+let example = express();
+example.disable("x-powered-by");
+</pre>
+<p>Or with helmet’s <a href="https://www.npmjs.com/package/helmet">hidePoweredBy</a> middleware:</p>
+<pre>
 let helmet = require("helmet");
-let app2 = express(); // Compliant
-app2.use(helmet.hidePoweredBy());
+
+let example = express();
+example.use(helmet.hidePoweredBy());
 </pre>
 <h2>See</h2>
 <ul>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5876.html

@@ -1,31 +1,88 @@
+<p>An attacker may trick a user into using a predetermined session identifier. Consequently, this attacker can gain unauthorized access and
+impersonate the user’s session. This kind of attack is called session fixation, and protections against it should not be disabled.</p>
 <h2>Why is this an issue?</h2>
-<p>Session fixation attacks occur when an attacker can force a legitimate user to use a session ID that he knows. To avoid fixation attacks, it’s a
-good practice to generate a new session each time a user authenticates and delete/invalidate the existing session (the one possibly known by the
-attacker).</p>
-<h3>Noncompliant code example</h3>
-<p>For <a href="http://www.passportjs.org/">Passport.js</a>:</p>
-<pre>
+<p>Session fixation attacks take advantage of the way web applications manage session identifiers. Here’s how a session fixation attack typically
+works:</p>
+<ul>
+  <li> When a user visits a website or logs in, a session is created for them. </li>
+  <li> This session is assigned a unique session identifier, stored in a cookie, in local storage, or through URL parameters. </li>
+  <li> In a session fixation attack, an attacker tricks a user into using a predetermined session identifier controlled by the attacker. For example,
+  the attacker sends the victim an email containing a link with this predetermined session identifier. </li>
+  <li> When the victim clicks on the link, the web application does not create a new session identifier but uses this identifier known to the
+  attacker. </li>
+  <li> At this point, the attacker can hijack and impersonate the victim’s session. </li>
+</ul>
+<h3>What is the potential impact?</h3>
+<p>Session fixation attacks pose a significant security risk to web applications and their users. By exploiting this vulnerability, attackers can gain
+unauthorized access to user sessions, potentially leading to various malicious activities. Some of the most relevant scenarios are the following:</p>
+<h4>Impersonation</h4>
+<p>Once an attacker successfully fixes a session identifier, they can impersonate the victim and gain access to their account without providing valid
+credentials. This can result in unauthorized actions, such as modifying personal information, making unauthorized transactions, or even performing
+malicious activities on behalf of the victim. An attacker can also manipulate the victim into performing actions they wouldn’t normally do, such as
+revealing sensitive information or conducting financial transactions on the attacker’s behalf.</p>
+<h4>Data Breach</h4>
+<p>If an attacker gains access to a user’s session, they may also gain access to sensitive data associated with that session. This can include
+personal information, financial details, or any other confidential data that the user has access to within the application. The compromised data can
+be used for identity theft, financial fraud, or other malicious purposes.</p>
+<h4>Privilege Escalation</h4>
+<p>In some cases, session fixation attacks can be used to escalate privileges within a web application. By fixing a session identifier with higher
+privileges, an attacker can bypass access controls and gain administrative or privileged access to the application. This can lead to unauthorized
+modifications, data manipulation, or even complete compromise of the application and its underlying systems.</p>
+<h2>How to fix it in Passport</h2>
+<h3>Code examples</h3>
+<p>Upon user authentication, it is crucial to regenerate the session identifier to prevent fixation attacks. Passport provides a mechanism to achieve
+this by using the <code>req.session.regenerate()</code> method. By calling this method after successful authentication, you can ensure that each user
+is assigned a new and unique session ID.</p>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 app.post('/login',
   passport.authenticate('local', { failureRedirect: '/login' }),
   function(req, res) {
-    // Sensitive - no session.regenerate after login
+    // Noncompliant - no session.regenerate after login
     res.redirect('/');
   });
 </pre>
-<h3>Compliant solution</h3>
-<p>For <a href="http://www.passportjs.org/">Passport.js</a>:</p>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 app.post('/login',
   passport.authenticate('local', { failureRedirect: '/login' }),
   function(req, res) {
     let prevSession = req.session;
-    req.session.regenerate((err) =&gt; {  // Compliant
+    req.session.regenerate((err) =&gt; {
       Object.assign(req.session, prevSession);
       res.redirect('/');
     });
   });
 </pre>
+<h3>How does this work?</h3>
+<p>The protection works by ensuring that the session identifier, which is used to identify and track a user’s session, is changed or regenerated
+during the authentication process.</p>
+<p>Here’s how session fixation protection typically works:</p>
+<ol>
+  <li> When a user visits a website or logs in, a session is created for them. This session is assigned a unique session identifier, which is stored
+  in a cookie or passed through URL parameters. </li>
+  <li> In a session fixation attack, an attacker tricks a user into using a predetermined session identifier controlled by the attacker. This allows
+  the attacker to potentially gain unauthorized access to the user’s session. </li>
+  <li> To protect against session fixation attacks, session fixation protection mechanisms come into play during the authentication process. When a
+  user successfully authenticates, this mechanism generates a new session identifier for the user’s session. </li>
+  <li> The old session identifier, which may have been manipulated by the attacker, is invalidated and no longer associated with the user’s session.
+  This ensures that any attempts by the attacker to use the fixed session identifier are rendered ineffective. </li>
+  <li> The user is then assigned the new session identifier, which is used for subsequent requests and session tracking. This new session identifier
+  is typically stored in a new session cookie or passed through URL parameters. </li>
+</ol>
+<p>By regenerating the session identifier upon authentication, session fixation protection helps ensure that the user’s session is tied to a new,
+secure identifier that the attacker cannot predict or control. This mitigates the risk of an attacker gaining unauthorized access to the user’s
+session and helps maintain the integrity and security of the application’s session management process.</p>
 <h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> <a href="http://expressjs.com/en/resources/middleware/session.html">express-session</a> </li>
+</ul>
+<h3>Articles &amp; blog posts</h3>
+<ul>
+  <li> <a href="https://medium.com/passportjs/fixing-session-fixation-b2b68619c51d">Fixing Session Fixation</a> </li>
+</ul>
+<h3>Standards</h3>
 <ul>
   <li> <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">OWASP Top 10 2021 Category A7</a> - Identification and
   Authentication Failures </li>