SONARXML-198 Update rule metadata (#309)

Author: dorian-burihabwa-sonarsource

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S1120.html

@@ -1,6 +1,67 @@
+<p>Indentation should be consistent to make the code easy to read, review and modify. To fix this issue, change the indentation so that the text
+starts at the expected column.</p>
 <h2>Why is this an issue?</h2>
-<p>Proper indentation is a simple and effective way to improve the code’s readability. Consistent indentation among the developers within a team also
-reduces the differences that are committed to source control systems, making code reviews easier.</p>
-<p>By default this rule checks that each block of code is indented, although it does not check the size of the indent. Parameter "indentSize" allows
-the expected indent size to be defined. Only the first line of a badly indented section is reported.</p>
+<p>Consistent indentation is a simple and effective way to improve the code’s readability. It reduces the differences that are committed to source
+control systems, making code reviews easier.</p>
+<p>This rule raises an issue when the indentation does not match the configured value. Only the first line of a badly indented section is
+reported.</p>
+<h3>What is the potential impact?</h3>
+<p>The readability is decreased. It becomes more tedious to review and modify the code.</p>
+<h2>How to fix it</h2>
+<p>Change the indentation so that the text starts at the expected column. The expected column should be the configured indent size multiplied by the
+level at which the code block is nested.</p>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
+<p>With an indent size of 2:</p>
+<pre data-diff-id="1" data-diff-type="noncompliant">
+&lt;?xml version="1.0"?&gt;
+&lt;catalog&gt;
+  &lt;book id="bk101"&gt;
+    &lt;author&gt;Gambardella, Matthew&lt;/author&gt;
+     &lt;title&gt;XML Developer's Guide&lt;/title&gt;  &lt;!-- Noncompliant, expected to start at column 4 --&gt;
+    &lt;genre&gt;Computer&lt;/genre&gt;
+    &lt;price&gt;44.95&lt;/price&gt;
+    &lt;publish_date&gt;2000-10-01&lt;/publish_date&gt;
+    &lt;description&gt;An in-depth look at creating applications
+    with XML.&lt;/description&gt;
+  &lt;/book&gt;
+    &lt;book id="bk102"&gt;  &lt;!-- Noncompliant, expected to start at column 2 --&gt;
+      &lt;author&gt;Ralls, Kim&lt;/author&gt;
+      &lt;title&gt;Midnight Rain&lt;/title&gt;
+      &lt;genre&gt;Fantasy&lt;/genre&gt;
+      &lt;price&gt;5.95&lt;/price&gt;
+      &lt;publish_date&gt;2000-12-16&lt;/publish_date&gt;
+      &lt;description&gt;A former architect battles corporate zombies,
+      an evil sorceress, and her own childhood to become queen
+      of the world.&lt;/description&gt;
+    &lt;/book&gt;
+&lt;/catalog&gt;
+</pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
+&lt;?xml version="1.0"?&gt;
+&lt;catalog&gt;
+  &lt;book id="bk101"&gt;
+    &lt;author&gt;Gambardella, Matthew&lt;/author&gt;
+    &lt;title&gt;XML Developer's Guide&lt;/title&gt;
+    &lt;genre&gt;Computer&lt;/genre&gt;
+    &lt;price&gt;44.95&lt;/price&gt;
+    &lt;publish_date&gt;2000-10-01&lt;/publish_date&gt;
+    &lt;description&gt;An in-depth look at creating applications
+    with XML.&lt;/description&gt;
+  &lt;/book&gt;
+  &lt;book id="bk102"&gt;
+    &lt;author&gt;Ralls, Kim&lt;/author&gt;
+    &lt;title&gt;Midnight Rain&lt;/title&gt;
+    &lt;genre&gt;Fantasy&lt;/genre&gt;
+    &lt;price&gt;5.95&lt;/price&gt;
+    &lt;publish_date&gt;2000-12-16&lt;/publish_date&gt;
+    &lt;description&gt;A former architect battles corporate zombies,
+    an evil sorceress, and her own childhood to become queen
+    of the world.&lt;/description&gt;
+  &lt;/book&gt;
+&lt;/catalog&gt;
+</pre>
+<h3>Going the extra mile</h3>
+<p>You can adopt a tool or configure your IDE to take care of code formatting automatically.</p>
 

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S1134.html

@@ -13,6 +13,6 @@ <h2>Why is this an issue?</h2>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546 - Suspicious Comment</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a> </li>
 </ul>
 

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S1135.html

@@ -1,7 +1,20 @@
 <h2>Why is this an issue?</h2>
-<p><code>TODO</code> tags are commonly used to mark places where some more code is required, but which the developer wants to implement later.</p>
-<p>Sometimes the developer will not have the time or will simply forget to get back to that tag.</p>
-<p>This rule is meant to track those tags and to ensure that they do not go unnoticed.</p>
+<p>Developers often use <code>TODO</code> tags to mark areas in the code where additional work or improvements are needed but are not implemented
+immediately. However, these <code>TODO</code> tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This rule aims to
+identify and address unattended <code>TODO</code> tags to ensure a clean and maintainable codebase. This description explores why this is a problem
+and how it can be fixed to improve the overall code quality.</p>
+<h3>What is the potential impact?</h3>
+<p>Unattended <code>TODO</code> tags in code can have significant implications for the development process and the overall codebase.</p>
+<p>Incomplete Functionality: When developers leave <code>TODO</code> tags without implementing the corresponding code, it results in incomplete
+functionality within the software. This can lead to unexpected behavior or missing features, adversely affecting the end-user experience.</p>
+<p>Missed Bug Fixes: If developers do not promptly address <code>TODO</code> tags, they might overlook critical bug fixes and security updates.
+Delayed bug fixes can result in more severe issues and increase the effort required to resolve them later.</p>
+<p>Impact on Collaboration: In team-based development environments, unattended <code>TODO</code> tags can hinder collaboration. Other team members
+might not be aware of the intended changes, leading to conflicts or redundant efforts in the codebase.</p>
+<p>Codebase Bloat: The accumulation of unattended <code>TODO</code> tags over time can clutter the codebase and make it difficult to distinguish
+between work in progress and completed code. This bloat can make it challenging to maintain an organized and efficient codebase.</p>
+<p>Addressing this code smell is essential to ensure a maintainable, readable, reliable codebase and promote effective collaboration among
+developers.</p>
 <h3>Noncompliant code example</h3>
 <pre>
 &lt;!-- TODO Drop this dependency --&gt;
@@ -13,6 +26,6 @@ <h3>Noncompliant code example</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546</a> - Suspicious Comment </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a> </li>
 </ul>
 

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S1135.json

@@ -24,5 +24,5 @@
       546
     ]
   },
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S125.html

@@ -1,4 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>Programmers should not comment out code as it bloats programs and reduces readability.</p>
-<p>Unused code should be deleted and can be retrieved from source control history if required.</p>
+<p>Commented-out code distracts the focus from the actual executed code. It creates a noise that increases maintenance code. And because it is never
+executed, it quickly becomes out of date and invalid.</p>
+<p>Commented-out code should be deleted and can be retrieved from source control history if required.</p>
 

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S2068.html

@@ -62,13 +62,12 @@ <h2>Compliant Solution</h2>
 </pre>
 <h2>See</h2>
 <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>
-  <li> <a href="https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication
+  <li> OWASP - <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">Top 10 2021 Category A7 - Identification and
+  Authentication Failures</a> </li>
+  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication">Top 10 2017 Category A2 - Broken Authentication</a>
   </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/798">CWE-798 - Use of Hard-coded Credentials</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/259">CWE-259 - Use of Hard-coded Password</a> </li>
   <li> Derived from FindSecBugs rule <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
 </ul>
 

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S2260.json

@@ -13,5 +13,5 @@
   "ruleSpecification": "RSPEC-2260",
   "sqKey": "S2260",
   "scope": "All",
-  "quickfix": "unknown"
+  "quickfix": "infeasible"
 }

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S2647.html

@@ -1,40 +1,92 @@
+<p>This rule is deprecated, and will eventually be removed.</p>
+<p>Basic authentication is a vulnerable method of user authentication that should be avoided. It functions by transmitting a Base64 encoded username
+and password. As Base64 is easy to recognize and reverse, sensitive data may be leaked this way.</p>
 <h2>Why is this an issue?</h2>
-<p>Basic authentication’s only means of obfuscation is Base64 encoding. Since Base64 encoding is easily recognized and reversed, it offers only the
-thinnest veil of protection to your users, and should not be used.</p>
-<h3>Noncompliant code example</h3>
-<pre>
-// in web.xml
-&lt;web-app  ...&gt;
-  &lt;!--  ...  --&gt;
+<p>Basic authentication is a simple and widely used method of user authentication for HTTP requests. When a client sends a request to a server that
+requires authentication, the client includes the username and password (concatenated together and Base64 encoded) in the "Authorization" header of the
+HTTP request. The server verifies the credentials and grants access if they are valid. Every request sent to the server to a protected endpoint must
+include these credentials.</p>
+<p>Basic authentication is considered insecure for several reasons:</p>
+<ul>
+  <li> It transmits user credentials in plain text, making them susceptible to interception and eavesdropping. </li>
+  <li> It relies solely on the server’s ability to verify the provided credentials. There is no mechanism for additional security measures like
+  multi-factor authentication or account lockouts after multiple failed login attempts. </li>
+  <li> It does not provide a way to manage user sessions securely. The client typically includes the credentials in every request, which creates more
+  opportunities for an attacker to steal these credentials. </li>
+</ul>
+<p>These security limitations make basic authentication an insecure choice for authentication or authorization over HTTP.</p>
+<h3>What is the potential impact?</h3>
+<p>Basic authentication transmits passwords in plain text, which makes it vulnerable to interception by attackers.</p>
+<h4>Session hijacking and man-in-the-middle attack</h4>
+<p>If an attacker gains access to the network traffic, they can easily capture the username and password. Basic authentication does not provide any
+mechanism to protect against session hijacking attacks. Once a user is authenticated, the session identifier (the username and password) is sent in
+clear text with each subsequent request. If attackers can intercept one request, they can use it to impersonate the authenticated user, gaining
+unauthorized access to their account and potentially performing malicious actions.</p>
+<h4>Brute-force attacks</h4>
+<p>Basic authentication does not have any built-in protection against brute-force attacks. Attackers can repeatedly guess passwords until they find
+the correct one, especially if weak or commonly used passwords are used. This can lead to unauthorized access to user accounts and potential data
+breaches.</p>
+<h2>How to fix it in Java EE</h2>
+<h3>Code examples</h3>
+<p>The following code uses basic authentication to protect web server endpoints.</p>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="201" data-diff-type="noncompliant">
+&lt;!-- web.xml --&gt;
+&lt;web-app&gt;
   &lt;login-config&gt;
     &lt;auth-method&gt;BASIC&lt;/auth-method&gt;
   &lt;/login-config&gt;
 &lt;/web-app&gt;
 </pre>
-<h3>Exceptions</h3>
-<p>The rule will not raise any issue if HTTPS is enabled, on any URL-pattern.</p>
-<pre>
-&lt;web-app  ...&gt;
-  &lt;!--  ...  --&gt;
-  &lt;security-constraint&gt;
-    &lt;web-resource-collection&gt;
-      &lt;web-resource-name&gt;HTTPS enabled&lt;/web-resource-name&gt;
-      &lt;url-pattern&gt;/*&lt;/url-pattern&gt;
-    &lt;/web-resource-collection&gt;
-    &lt;user-data-constraint&gt;
-      &lt;transport-guarantee&gt;CONFIDENTIAL&lt;/transport-guarantee&gt;
-    &lt;/user-data-constraint&gt;
-  &lt;/security-constraint&gt;
+<h4>Compliant solution</h4>
+<pre data-diff-id="201" data-diff-type="compliant">
+&lt;!-- web.xml --&gt;
+&lt;web-app&gt;
+  &lt;login-config&gt;
+    &lt;auth-method&gt;FORM&lt;/auth-method&gt;
+    &lt;form-login-config&gt;
+      &lt;form-login-page&gt;/login.jsp&lt;/form-login-page&gt;
+      &lt;form-error-page&gt;/login-error.jsp&lt;/form-error-page&gt;
+    &lt;/form-login-config&gt;
+  &lt;/login-config&gt;
 &lt;/web-app&gt;
 </pre>
+<h3>How does this work?</h3>
+<h4>Token-based authentication and OAuth</h4>
+<p>Token-based authentication is a safer alternative than basic authentication. A unique token is generated upon successful authentication and sent to
+the client, which is then included in subsequent requests. Therefore, it eliminates the need to transmit sensitive credentials with each request.
+OAuth also works by authenticating users via tokens. It gives even more flexibility on top of this by offering scopes, which limit an application’s
+access to a user’s account.</p>
+<p>Additionally, both token-based authentication and OAuth support mechanisms for token expiration, revocation, and refresh. This gives more
+flexibility than basic authentication, as compromised tokens carry much less risk than a compromised password.</p>
+<p>The Jakarta EE Security API offers robust and standardized methods to handle authentication and authorization in Jakarta EE applications. In the
+example, form-based authentication is applied to the <code>web.xml</code> configuration file. After a user successfully logs into the application, a
+session is created for the user. A session token is stored in a cookie and is used for subsequent requests.</p>
+<h4>Integrate with an Identity and Access Management (IAM) System</h4>
+<p>For more advanced authentication and authorization capabilities, consider integrating the backend with an IAM system. Doing so gives access to
+features like single sign-on (SSO), role-based access control, and centralized user management. As of Jakarta EE 10, support for OpenID Connect (OIDC)
+is included. Using this authentication method, several OIDC providers can be integrated easily, such as Auth0, Okta, and Azure Active Directory.</p>
+<h4>SSL encryption for HTTP requests</h4>
+<p>With basic authentication, user credentials are transmitted in plain text, which makes them vulnerable to interception and eavesdropping. However,
+when HTTPS is employed, the data is encrypted before transmission, making it significantly more difficult for attackers to intercept and decipher the
+credentials. If no other form of authentication is possible for this code, then every request must be sent over HTTPS to ensure credentials are kept
+safe.</p>
+<p>In Jakarta EE, HTTPS traffic can be enabled by setting the <code>transportGuarantee</code> attribute to <code>CONFIDENTIAL</code> in
+<code>web.xml</code>.</p>
 <h2>Resources</h2>
+<h3>Documentation</h3>
+<ul>
+  <li> MDN web docs - <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication">HTTP authentication</a> </li>
+</ul>
+<h3>Standards</h3>
 <ul>
-  <li> <a href="https://owasp.org/Top10/A04_2021-Insecure_Design/">OWASP Top 10 2021 Category A4</a> - Insecure Design </li>
-  <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
-  Exposure </li>
+  <li> OWASP - <a href="https://owasp.org/Top10/A04_2021-Insecure_Design/">Top 10 2021 Category A4 - Insecure Design</a> </li>
+  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
+  Exposure</a> </li>
   <li> <a href="https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#user-authentication">OWASP Web Service Security
   Cheat Sheet</a> </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/522">MITRE, CWE-522</a> - Insufficiently Protected Credentials </li>
-  <li> <a href="https://www.sans.org/top25-software-errors/#cat3">SANS Top 25</a> - Porous Defenses </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/522">CWE-522 - Insufficiently Protected Credentials</a> </li>
+  <li> STIG Viewer - <a href="https://stigviewer.com/stig/application_security_and_development/2023-06-08/finding/V-222533">Application Security and
+  Development: V-222533</a> - The application must authenticate all network connected endpoint devices before establishing any connection. </li>
 </ul>
 

sonar-xml-plugin/src/main/resources/org/sonar/l10n/xml/rules/xml/S2647.json

@@ -5,16 +5,14 @@
     "impacts": {
       "SECURITY": "HIGH"
     },
-    "attribute": "COMPLETE"
+    "attribute": "TRUSTWORTHY"
   },
-  "status": "ready",
+  "status": "deprecated",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "2h"
   },
-  "tags": [
-    "cwe"
-  ],
+  "tags": [],
   "defaultSeverity": "Critical",
   "ruleSpecification": "RSPEC-2647",
   "sqKey": "S2647",
@@ -37,6 +35,9 @@
     ],
     "ASVS 4.0": [
       "2.10.3"
+    ],
+    "STIG ASD_V5R3": [
+      "V-222533"
     ]
   },
   "quickfix": "unknown"