Update rule S7409: Clarify rule title and rule text (SONARKT-637) (#4826)

* Update rule title and text according to previous discussion

* Fix typo

* Add references to S6362 and S7409 in both rules' descriptions
This commit is contained in:
Egon Okerman 2025-03-28 13:55:14 +01:00 committed by GitHub
parent cc01781c31
commit ae0dfb3126
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
3 changed files with 21 additions and 13 deletions

View File

@ -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

View File

@ -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": {

View File

@ -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