update coverage information (#4859)

Co-authored-by: SonarTech <sonartech@sonarsource.com>

frontend/public/covered_rules.json

@@ -5191,6 +5191,7 @@
     "S1940": "sonar-kotlin 2.0.0.29",
     "S2053": "sonar-kotlin 2.3.0.609",
     "S2068": "sonar-kotlin 2.0.0.29",
+    "S2083": "sonar-security master",
     "S2097": "sonar-kotlin 2.12.0.1956",
     "S2114": "sonar-kotlin 2.12.0.1956",
     "S2116": "sonar-kotlin 2.12.0.1956",
@@ -5222,6 +5223,7 @@
     "S5322": "sonar-kotlin 2.3.0.609",
     "S5324": "sonar-kotlin 2.2.0.499",
     "S5332": "sonar-kotlin 2.0.0.29",
+    "S5344": "sonar-kotlin master",
     "S5527": "sonar-kotlin 2.0.0.29",
     "S5542": "sonar-kotlin 2.0.0.29",
     "S5547": "sonar-kotlin 2.0.0.29",
@@ -5235,6 +5237,7 @@
     "S5867": "sonar-kotlin 2.6.0.862",
     "S5868": "sonar-kotlin 2.6.0.862",
     "S5869": "sonar-kotlin 2.6.0.862",
+    "S6096": "sonar-security master",
     "S6202": "sonar-kotlin 2.4.0.703",
     "S6207": "sonar-kotlin 2.15.0.2579",
     "S6218": "sonar-kotlin 2.4.0.703",
@@ -5257,6 +5260,7 @@
     "S6318": "sonar-kotlin 2.1.0.344",
     "S6362": "sonar-kotlin 2.5.0.754",
     "S6363": "sonar-kotlin 2.5.0.754",
+    "S6384": "sonar-security master",
     "S6432": "sonar-kotlin 2.11.0.1828",
     "S6474": "sonar-kotlin master",
     "S6508": "sonar-kotlin 2.14.0.2352",

rules/S6096/java/how-to-fix-it/java-io-api.adoc

@@ -1,4 +1,4 @@
-== How to fix it in Java SE
+== How to fix it in Java I/O API
 
 === Code examples
 

rules/S6096/java/rule.adoc

@@ -4,7 +4,7 @@ include::../rationale.adoc[]
 
 include::../impact.adoc[]
 
-include::how-to-fix-it/java-se.adoc[]
+include::how-to-fix-it/java-io-api.adoc[]
 
 == Resources
 

rules/S6096/kotlin/how-to-fix-it/java-io-api.adoc

@@ -0,0 +1,90 @@
+== How to fix it in Java I/O API
+
+=== Code examples
+
+:canonicalization_function1: java.io.File.getCanonicalFile
+:canonicalization_function2: java.io.File.getCanonicalPath
+
+include::../../common/fix/code-rationale.adoc[]
+
+==== Noncompliant code example
+
+[source,kotlin,diff-id=1,diff-type=noncompliant]
+----
+class Example {
+    companion object {
+        private const val TARGET_DIRECTORY = "/example/directory/"
+    }
+    fun extractEntry(zipFile: ZipFile) {
+        val entries = zipFile.entries()
+        val entry = entries.nextElement()
+        val inputStream = zipFile.getInputStream(entry)
+        val file = File(TARGET_DIRECTORY + entry.name)
+        inputStream.copyTo(file.outputStream())
+    }
+}
+----
+
+==== Compliant solution
+
+[source,kotlin,diff-id=1,diff-type=compliant]
+----
+class Example {
+    companion object {
+        private const val TARGET_DIRECTORY = "/example/directory/"
+    }
+    fun extractEntry(zipFile: ZipFile) {
+        val entries = zipFile.entries()
+        val entry = entries.nextElement()
+        val inputStream = zipFile.getInputStream(entry)
+        val file = File(TARGET_DIRECTORY + entry.name)
+        val canonicalDestinationPath = file.canonicalPath
+        if (canonicalDestinationPath.startsWith(TARGET_DIRECTORY)) {
+            inputStream.copyTo(file.outputStream())
+        }
+    }
+}
+----
+
+=== How does this work?
+
+include::../../common/fix/how-does-this-work.adoc[]
+
+=== Pitfalls
+
+include::../../common/pitfalls/partial-path-traversal.adoc[]
+
+For example, the following code is vulnerable to partial path injection. Note
+that the string `targetDirectory` does not end with a path separator:
+
+
+[source, kotlin]
+----
+companion object {
+    private const val targetDirectory = "/Users/John"
+}
+
+fun ExtractEntry(zipFile: ZipFile) {
+    val entries = zipFile.entries()
+    val entry = entries.nextElement()
+    val inputStream = zipFile.getInputStream(entry)
+
+    val file = File(entry.name)
+
+    val canonicalDestinationPath = file.canonicalPath
+    if (canonicalDestinationPath.startsWith(targetDirectory)) {
+        Files.copy(inputStream, file.toPath(), StandardCopyOption.REPLACE_EXISTING, LinkOption.NOFOLLOW_LINKS)
+    }
+}
+----
+
+This check can be bypassed because `"/Users/Johnny".startsWith("/Users/John")`
+returns `true`. Thus, for validation, `"/Users/John"` should actually be
+`"/Users/John/"`.
+
+**Warning**: Some functions, such as `.getCanonicalPath`, remove the
+terminating path separator in their return value. +
+The validation code should be tested to ensure that it cannot be impacted by this
+issue.
+
+https://github.com/aws/aws-sdk-java/security/advisories/GHSA-c28r-hw5m-5gv3[Here is a real-life example of this vulnerability.]

rules/S6096/kotlin/metadata.json

@@ -0,0 +1,34 @@
+{
+  "securityStandards": {
+    "CWE": [
+      20,
+      22
+    ],
+    "OWASP": [
+      "A5",
+      "A1"
+    ],
+    "OWASP Top 10 2021": [
+      "A1",
+      "A3"
+    ],
+    "OWASP Mobile Top 10 2024": [
+      "M4"
+    ],
+    "PCI DSS 3.2": [
+      "6.5.1",
+      "6.5.8"
+    ],
+    "PCI DSS 4.0": [
+      "6.2.4"
+    ],
+    "ASVS 4.0": [
+      "12.3.4",
+      "5.1.3",
+      "5.1.4"
+    ],
+    "STIG ASD_V5R3": [
+      "V-222609"
+    ]
+  }
+}

rules/S6096/kotlin/rule.adoc

@@ -0,0 +1,23 @@
+== Why is this an issue?
+
+include::../rationale.adoc[]
+
+include::../impact.adoc[]
+
+include::how-to-fix-it/java-io-api.adoc[]
+
+== Resources
+
+include::../common/resources/articles.adoc[]
+
+include::../common/resources/standards-mobile.adoc[]
+
+ifdef::env-github,rspecator-view[]
+
+'''
+== Implementation Specification
+(visible only on this page)
+
+include::../message.adoc[]
+
+endif::env-github,rspecator-view[]

rules/S6362/see.adoc

@@ -5,3 +5,6 @@
 * OWASP - https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)[Top 10 2017 Category A7 - Cross-Site Scripting (XSS)]
 * OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m8-security-misconfiguration[Mobile Top 10 2024 Category M8 - Security Misconfiguration]
 * CWE - https://cwe.mitre.org/data/definitions/79[CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')]
+
+=== Related rules
+* S7409 - Exposing Java objects through JavaScript interfaces is security-sensitive

rules/S6384/common/resources/docs.adoc

@@ -1,4 +1,4 @@
 === Documentation
 
-* Google Support - https://support.google.com/faqs/answer/9267555?hl=en[Remediation for Intent Redirection Vulnerability]
-* Android Documentation - https://developer.android.com/topic/security/risks/intent-redirection[Intent redirection]
+* https://support.google.com/faqs/answer/9267555?hl=en[support.google.com] - Remediation for Intent Redirection Vulnerability
+https://developer.android.com/topic/security/risks/intent-redirection[developer.android.com] - Intent redirection

rules/S6384/impact.adoc

@@ -1,62 +0,0 @@
-=== What is the potential impact?
-
-An affected component that forwards a malicious externally provided intent does so using the vulnerable application's context. In particular, the new component is created with the same permissions as the application and without limitations on what feature can be reached.
-
-Therefore, an attacker exploiting an intent redirection vulnerability could
-manage to access a private application's components. Depending on the features
-privately exposed, this can lead to further exploitations, sensitive data
-disclosure, or even persistent code execution.
-
-==== Information disclosure
-
-An attacker can use the affected feature as a gateway to access other components
-of the vulnerable application, even if they are not exported. This includes
-features that handle sensitive information.
-
-Therefore, by crafting a malicious intent and submitting it to the vulnerable
-redirecting component, an attacker can retrieve most data exposed by private
-features. This affects the confidentiality of information that is not
-protected by an additional security mechanism, such as an encryption algorithm.
-
-==== Attack surface increase
-
-Because the attacker can access most components of the application, they can
-identify and exploit other vulnerabilities that would be present in them. The
-actual impact depends on the nested vulnerability. Exploitation probability
-depends on the in-depth security level of the application.
-
-==== Privilege escalation
-
-If the vulnerable application has privileges on the underlying devices, an
-attacker exploiting the redirection issue might take advantage of them. For
-example by crafting a malicious intent action, the attacker could be able to
-pass phone calls on behalf of the entitled application.
-
-This can lead to various attack scenarios depending on the exploited
-permissions.
-
-==== Persistent code execution
-
-A lot of applications rely on dynamic code loading to implement a variety of
-features, such as:
-
-* Minor feature updates.
-* Application package size reduction.
-* DRM or other code protection features.
-
-When a component exposes a dynamic code loading feature, an attacker could use
-it during the redirection's exploitation to deploy malicious code into the
-application. The component can be located in the application itself or one of
-its dependencies.
-
-Such an attack would compromise the application execution environment entirely
-and lead to multiple security threats. The malicious code could:
-
-* Intercept and exfiltrate all data used in the application.
-* Steal authentication credentials to third-party services.
-* Change the application's behavior to serve another malicious purpose
-(phishing, ransoming, etc)
-
-Note that in most cases, the deployed malware can persist application or
-hosting device restarts.
-

rules/S6384/java/how-to-fix-it/android.adoc

@@ -8,13 +8,12 @@ include::../../common/fix/code-rationale.adoc[]
 
 [source,java,diff-id=1,diff-type=noncompliant]
 ----
-public class MainActivity extends AppCompatActivity {
+public class Noncompliant extends AppCompatActivity {
     @Override
     protected void onCreate(Bundle savedInstanceState) {
-        super.onCreate(savedInstanceState);
         Intent intent = getIntent();
         Intent forward = (Intent) intent.getParcelableExtra("anotherintent");
-        startActivity(forward);
+        startActivity(forward); // Noncompliant
     }
 }
 ----
@@ -27,10 +26,13 @@ public class MainActivity extends AppCompatActivity {
     @Override
     protected void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);
+
         Intent intent = getIntent();
         Intent forward = (Intent) intent.getParcelableExtra("anotherintent");
+
         ComponentName name = forward.resolveActivity(getPackageManager());
-        if (name.getPackageName().equals("safePackage") && name.getClassName().equals("safeClass")) {
+        if (name.getPackageName().equals("safePackage") &&
+                name.getClassName().equals("safeClass")) {
             startActivity(forward);
         }
     }

rules/S6384/java/rule.adoc

@@ -1,8 +1,77 @@
 == Why is this an issue?
 
-include::../rationale.adoc[]
+Intent redirection vulnerabilities occur when an application publicly exposes a
+feature that uses an externally provided intent to start a new component.
+
+In that case, an application running on the same device as the affected one can
+launch the exposed, vulnerable component and provide it with a specially crafted
+intent. Depending on the application's configuration and logic, this intent will
+be used in the context of the vulnerable application, which poses a security
+threat.
+
+
+=== What is the potential impact?
+
+An affected component that forwards a malicious externally provided intent does so using the vulnerable application's context. In particular, the new component is created with the same permissions as the application and without limitations on what feature can be reached.
+
+Therefore, an attacker exploiting an intent redirection vulnerability could
+manage to access a private application's components. Depending on the features
+privately exposed, this can lead to further exploitations, sensitive data
+disclosure, or even persistent code execution.
+
+==== Information disclosure
+
+An attacker can use the affected feature as a gateway to access other components
+of the vulnerable application, even if they are not exported. This includes
+features that handle sensitive information.
+
+Therefore, by crafting a malicious intent and submitting it to the vulnerable
+redirecting component, an attacker can retrieve most data exposed by private
+features. This affects the confidentiality of information that is not
+protected by an additional security mechanism, such as an encryption algorithm.
+
+==== Attack surface increase
+
+Because the attacker can access most components of the application, they can
+identify and exploit other vulnerabilities that would be present in them. The
+actual impact depends on the nested vulnerability. Exploitation probability
+depends on the in-depth security level of the application.
+
+==== Privilege escalation
+
+If the vulnerable application has privileges on the underlying devices, an
+attacker exploiting the redirection issue might take advantage of them. For
+example by crafting a malicious intent action, the attacker could be able to
+pass phone calls on behalf of the entitled application.
+
+This can lead to various attack scenarios depending on the exploited
+permissions.
+
+==== Persistent code execution
+
+A lot of applications rely on dynamic code loading to implement a variety of
+features, such as:
+
+* Minor feature updates.
+* Application package size reduction.
+* DRM or other code protection features.
+
+When a component exposes a dynamic code loading feature, an attacker could use
+it during the redirection's exploitation to deploy malicious code into the
+application. The component can be located in the application itself or one of
+its dependencies.
+
+Such an attack would compromise the application execution environment entirely
+and lead to multiple security threats. The malicious code could:
+
+* Intercept and exfiltrate all data used in the application.
+* Steal authentication credentials to third-party services.
+* Change the application's behavior to serve another malicious purpose 
+  (phishing, ransoming, etc) 
+
+Note that in most cases, the deployed malware can persist application or
+hosting device restarts.
 
-include::../impact.adoc[]
 
 // How to fix it section
 
@@ -25,10 +94,4 @@ ifdef::env-github,rspecator-view[]
 Change this code to not perform arbitrary intent redirection.
 
 
-endif::env-github,rspecator-view[]
-
-'''
-== Implementation Specification
-(visible only on this page)
-
-include::../message.adoc[]
+endif::env-github,rspecator-view[]

rules/S6384/kotlin/how-to-fix-it/android.adoc

@@ -1,47 +0,0 @@
-== How to fix it in Android
-
-=== Code examples
-
-include::../../common/fix/code-rationale.adoc[]
-
-==== Noncompliant code example
-
-[source,kotlin,diff-id=1,diff-type=noncompliant]
-----
-class MainActivity : AppCompatActivity() {
-    override fun onCreate(savedInstanceState: Bundle?) {
-        super.onCreate(savedInstanceState)
-        val forward = intent.getParcelableExtra("anotherintent") as? Intent
-        startActivity(forward)
-    }
-}
-----
-
-==== Compliant solution
-
-[source,kotlin,diff-id=1,diff-type=compliant]
-----
-class MainActivity : AppCompatActivity() {
-    override fun onCreate(savedInstanceState: Bundle?) {
-        super.onCreate(savedInstanceState)
-        val forward = intent.getParcelableExtra("anotherintent") as? Intent
-        val name = forward?.resolveActivity(packageManager)
-        if (name?.packageName == "safePackage" && name.className == "safeClass")
-            startActivity(forward)
-    }
-}
-----
-
-=== How does this work?
-
-include::../../common/fix/introduction.adoc[]
-
-include::../../common/fix/destination.adoc[]
-
-The example compliant code uses the `resolveActivity` method of the inner intent
-to determine its target component. It then uses the `packageName` and
-`className` properties to validate this destination is not sensitive.
-
-include::../../common/fix/origin.adoc[]
-
-include::../../common/fix/permissions.adoc[]

rules/S6384/kotlin/metadata.json

@@ -1,2 +0,0 @@
-{
-}

rules/S6384/kotlin/rule.adoc

@@ -1,34 +0,0 @@
-== Why is this an issue?
-
-include::../rationale.adoc[]
-
-include::../impact.adoc[]
-
-// How to fix it section
-
-include::./how-to-fix-it/android.adoc[]
-
-== Resources
-
-include::../common/resources/docs.adoc[]
-
-include::../common/resources/standards.adoc[]
-
-ifdef::env-github,rspecator-view[]
-
-'''
-== Implementation Specification
-(visible only on this page)
-
-=== Message
-
-Change this code to not perform arbitrary intent redirection.
-
-
-endif::env-github,rspecator-view[]
-
-'''
-== Implementation Specification
-(visible only on this page)
-
-include::../message.adoc[]

rules/S6384/message.adoc

@@ -1,4 +0,0 @@
-=== Message
-
-Change this code to not perform arbitrary intent redirection.
-

rules/S6384/rationale.adoc

@@ -1,9 +0,0 @@
-Intent redirection vulnerabilities occur when an application publicly exposes a
-feature that uses an externally provided intent to start a new component.
-
-In that case, an application running on the same device as the affected one can
-launch the exposed, vulnerable component and provide it with a specially crafted
-intent. Depending on the application's configuration and logic, this intent will
-be used in the context of the vulnerable application, which poses a security
-threat.
-

rules/S7409/kotlin/metadata.json

@@ -1,5 +1,5 @@
 {
-  "title": "Exposing Java interfaces in WebViews is security-sensitive",
+  "title": "Exposing Java objects through JavaScript interfaces is security-sensitive",
   "type": "SECURITY_HOTSPOT",
   "status": "ready",
   "remediation": {

rules/S7409/kotlin/rule.adoc

@@ -1,15 +1,15 @@
-Using Javascript interfaces in WebViews is unsafe as it allows JavaScript to invoke Java methods,
-potentially giving attackers access to data or sensitive app functionality. WebViews might include
-untrusted sources such as third-party iframes, making this functionality particularly risky. As
-Javascript interfaces are passed to every frame in the WebView, those iframes are also able to
-access the exposed Java methods.
+Using JavaScript interfaces in WebViews to expose Java objects is unsafe. Doing so allows JavaScript
+to invoke Java methods, potentially giving attackers access to data or sensitive app functionality.
+WebViews might include untrusted sources such as third-party iframes, making this functionality
+particularly risky. As JavaScript interfaces are passed to every frame in the WebView, those iframes
+are also able to access the exposed Java object.
 
 == Ask Yourself Whether
 
 * The content in the WebView is fully trusted and secure.
 * Potentially untrusted iframes could be loaded in the WebView.
-* The Javascript interface has to be exposed for the entire lifecycle of the WebView.
-* The exposed Java methods will accept input from potentially untrusted sources.
+* The JavaScript interface has to be exposed for the entire lifecycle of the WebView.
+* The exposed Java object might be called by untrusted sources.
 
 There is a risk if you answered yes to any of these questions.
 
@@ -18,9 +18,9 @@ There is a risk if you answered yes to any of these questions.
 === Disable JavaScript
 
 If it is possible to disable JavaScript in the WebView, this is the most secure option. By default,
-JavaScript is disabled in a WebView, so you do not need to explicitly call
-``webSettings.setJavaScriptEnabled(true)`` in your ``WebSettings`` configuration. Of course, sometimes
-it is necessary to enable JavaScript, in which case the following recommendations should be considered.
+JavaScript is disabled in a WebView, so ``webSettings.setJavaScriptEnabled(false)`` does not need to
+be explicitly called. Of course, sometimes it is necessary to enable JavaScript, in which case the
+following recommendations should be considered.
 
 === Remove JavaScript interface when loading untrusted content
 
@@ -63,7 +63,8 @@ class ExampleActivity : AppCompatActivity() {
 
 == Compliant Solution
 
-The most secure option is to disable JavaScript entirely.
+The most secure option is to disable JavaScript entirely. S6362 further explains why it should not be enabled
+unless absolutely necessary.
 
 [source,kotlin]
 ----
@@ -96,7 +97,8 @@ class ExampleActivity : AppCompatActivity() {
 }
 ----
 
-If a JavaScript bridge must be used, consider using ``WebViewCompat.addWebMessageListener`` instead. This allows you to restrict the origins that can send messages to the JavaScript bridge.
+If a JavaScript bridge must be used, consider using ``WebViewCompat.addWebMessageListener`` instead. This allows you to restrict
+the origins that can send messages to the JavaScript bridge.
 
 [source,kotlin]
 ----
@@ -135,3 +137,6 @@ class ExampleActivity : AppCompatActivity() {
 * OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m4-insufficient-input-output-validation.html[Mobile Top 10 2024 Category M4 - Insufficient Input/Output Validation]
 * OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m8-security-misconfiguration.html[Mobile Top 10 2024 Category M8 - Security Misconfiguration]
 * CWE - https://cwe.mitre.org/data/definitions/79[CWE-79 - Improper Neutralization of Input During Web Page Generation]
+
+=== Related rules
+* S6362 - Enabling JavaScript support for WebViews is security-sensitive