Update rule metadata (#1446)

Co-authored-by: yasen-pavlov-sonarsource <yasen-pavlov-sonarsource>

Author: github-actions[bot]

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S100.html

@@ -39,7 +39,8 @@ <h3>Exceptions</h3>
  */
 function myFunc(){...}      // Compliant by exception
 </pre>
-<h2>References</h2>
+<h2>Resources</h2>
+<h3>Documentation</h3>
 <ul>
   <li> <a href="https://www.drupal.org/docs/develop/standards/php/php-coding-standards#s-functions-and-variables">Drupal - Naming Conventions -
   Functions and variables</a> </li>

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1313.html

@@ -1,7 +1,7 @@
 <p>Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:</p>
 <ul>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5901">CVE-2006-5901</a> </li>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3725">CVE-2005-3725</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2006-5901">CVE-2006-5901</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2005-3725">CVE-2005-3725</a> </li>
 </ul>
 <p>Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always
 have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development,

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1523.html

@@ -1,7 +1,7 @@
 <p>Executing code dynamically is security-sensitive. It has led in the past to the following vulnerabilities:</p>
 <ul>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9807">CVE-2017-9807</a> </li>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9802">CVE-2017-9802</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2017-9807">CVE-2017-9807</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2017-9802">CVE-2017-9802</a> </li>
 </ul>
 <p>Some APIs enable the execution of dynamic code by providing it as strings at runtime. These APIs might be useful in some very specific
 meta-programming use-cases. However most of the time their use is frowned upon as they also increase the risk of <a

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S1854.html

@@ -7,7 +7,7 @@ <h3>Exceptions</h3>
 <p>This rule ignores initializations to <code>-1</code>, <code>0</code>, <code>1</code>, <code>null</code>, <code>true</code>, <code>false</code>,
 <code>""</code>, <code>[]</code> and <code>array()</code>.</p>
 <h2>How to fix it</h2>
-<p>Remove the unnecesarry assignment, then test the code to make sure that the right-hand side of a given assignment had no side effects (e.g. a
+<p>Remove the unnecessary assignment, then test the code to make sure that the right-hand side of a given assignment had no side effects (e.g. a
 method that writes certain data to a file and returns the number of written bytes).</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S2068.html

@@ -2,8 +2,8 @@
 for applications that are distributed or that are open-source.</p>
 <p>In the past, it has led to the following vulnerabilities:</p>
 <ul>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13466">CVE-2019-13466</a> </li>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15389">CVE-2018-15389</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2019-13466">CVE-2019-13466</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2018-15389">CVE-2018-15389</a> </li>
 </ul>
 <p>Credentials should be stored outside of the code in a configuration file, a database, or a management service for secrets.</p>
 <p>This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S2245.html

@@ -7,9 +7,9 @@
 values that must remain confidential and resistant to guessing attacks.</p>
 <p>For example, the use of non-cryptographic PRNGs has led to vulnerabilities such as:</p>
 <ul>
-  <li> <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6386">CVE-2013-6386</a> </li>
-  <li> <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3419">CVE-2006-3419</a> </li>
-  <li> <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4102">CVE-2008-4102</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2013-6386">CVE-2013-6386</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2006-3419">CVE-2006-3419</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2008-4102">CVE-2008-4102</a> </li>
 </ul>
 <p>When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that
 will be generated, and use this guess to impersonate another user or access sensitive information. Therefore, it is critical to use CSPRNGs in any

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S2255.html

@@ -1,8 +1,8 @@
 <p>This rule is deprecated, and will eventually be removed.</p>
 <p>Using cookies is security-sensitive. It has led in the past to the following vulnerabilities:</p>
 <ul>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11639">CVE-2018-11639</a> </li>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6537">CVE-2016-6537</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2018-11639">CVE-2018-11639</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2016-6537">CVE-2016-6537</a> </li>
 </ul>
 <p>Attackers can use widely-available tools to read cookies. Any sensitive information they may contain will be exposed.</p>
 <p>This rule flags code that writes cookies.</p>

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S4426.html

@@ -16,9 +16,9 @@ <h2>Why is this an issue?</h2>
 <p>Note that depending on the algorithm, the term <strong>key</strong> refers to a different mathematical property. For example:</p>
 <ul>
   <li> For RSA, the key is the product of two large prime numbers, also called the <strong>modulus</strong>. </li>
-  <li> For AES and Elliptic Curve Cryptography (ECC), the key is only a sequence of randomly generated bytes.
+  <li> For Elliptic Curve Cryptography (ECC), the key is only a sequence of randomly generated bytes.
     <ul>
-      <li> In some cases, AES keys are derived from a master key or a passphrase using a Key Derivation Function (KDF) like PBKDF2 (Password-Based Key
+      <li> In some cases, keys are derived from a master key or a passphrase using a Key Derivation Function (KDF) like PBKDF2 (Password-Based Key
       Derivation Function 2) </li>
     </ul>  </li>
 </ul>
@@ -74,11 +74,6 @@ <h4>RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Algorithm)</h4>
 <p>The security of these algorithms depends on the difficulty of attacks attempting to solve their underlying mathematical problem.</p>
 <p>In general, a minimum key size of <strong>2048</strong> bits is recommended for both. It provides 112 bits of security. A key length of
 <strong>3072</strong> or <strong>4096</strong> should be preferred when possible.</p>
-<h4>AES (Advanced Encryption Standard)</h4>
-<p>AES supports three key sizes: 128 bits, 192 bits and 256 bits. The security of the AES algorithm is based on the computational complexity of trying
-all possible keys.<br> A larger key size increases the number of possible keys and makes exhaustive search attacks computationally infeasible.
-Therefore, a 256-bit key provides a higher level of security than a 128-bit or 192-bit key.</p>
-<p>Currently, a minimum key size of <strong>128 bits</strong> is recommended for AES.</p>
 <h4>Elliptic Curve Cryptography (ECC)</h4>
 <p>Elliptic curve cryptography is also used in various algorithms, such as ECDSA, ECDH, or ECMQV. The length of keys generated with elliptic curve
 algorithms is mentioned directly in their names. For example, <code>secp256k1</code> generates a 256-bits long private key.</p>

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S4508.html

@@ -1,9 +1,9 @@
 <p>This rule is deprecated, and will eventually be removed.</p>
 <p>Deserializing objects is security-sensitive. For example, it has led in the past to the following vulnerabilities:</p>
 <ul>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17672">CVE-2017-17672</a>: vBulletin: Unserialize PHP Code Execution </li>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000167">CVE-2018-1000167</a>: Jenkins Pipeline: arbitrary code execution
-  vulnerability </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2017-17672">CVE-2017-17672</a>: vBulletin: Unserialize PHP Code Execution </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2018-1000167">CVE-2018-1000167</a>: Jenkins Pipeline: arbitrary code execution vulnerability
+  </li>
 </ul>
 <p>Object deserialization from an untrusted source can lead to unexpected code execution. Deserialization takes a stream of bits and turns it into an
 object. If the stream contains the type of object you expect, all is well. But if you’re deserializing data coming from untrusted input, and an

php-checks/src/main/resources/org/sonar/l10n/php/rules/php/S4784.html

@@ -1,9 +1,9 @@
 <p>This rule is deprecated; use {rule:phpsecurity:S2631} instead.</p>
 <p>Using regular expressions is security-sensitive. It has led in the past to the following vulnerabilities:</p>
 <ul>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16021">CVE-2017-16021</a> </li>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-13863">CVE-2018-13863</a> </li>
-  <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8926">CVE-2018-8926</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2017-16021">CVE-2017-16021</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2018-13863">CVE-2018-13863</a> </li>
+  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2018-8926">CVE-2018-8926</a> </li>
 </ul>
 <p>Evaluating regular expressions against input strings is potentially an extremely CPU-intensive task. Specially crafted regular expressions such as
 <code>/(a+)+s/</code> will take several seconds to evaluate the input string <code>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaabs</code>. The problem is that with