breautek commented on PR #276:
URL: https://github.com/apache/cordova-js/pull/276#issuecomment-2272505284
After discussing this with a colleague we determined that the changes in
this PR is high risk of breaking plugins and/or applications with low
reward/value. As a result we will be declining this PR.
There's a couple of reasons why we consider this low reward/value and I'll
list them.
### 1. The PR doesn't actually prevents "hijacking" of events.
The PR aims to isolate an object containing global event listeners because
if an hypothetical malicious actor could replace the stored function with
another. By removing this object from the global namespace, you remove the
ability to replace the handler function.
The reality is, hypothetical malicious actors do not need this object. They
could simply attach an click event (or any other event) on the document. They
can go as far as use the `Capture` phase so that their event is triggered
before most other events (which by default uses the bubble phase), escaping
propagation prevention.
```javascript
document.addEventListener('click', function(e) { ... }, true);
```
Is all that is needed to listen for click events on any target and inspect
what is actually being clicked.
This is true even with standard browser APIs that isn't being overwritten.
### 2. standard window/document properties can simply be replaced
A hypothetical malicious actor who wants to hijack events can do so by
replacing the cordova's implementation with their own. This is true even if
Cordova doesn't overwrite the addEventListener itself.
The reality of webviews cannot load untrusted code. Any the attempts at
hardening doesn't really do anything to deter or prevent a malicious actor in
this case, hijack events. Once untrusted code is loaded, the app is at risk and
at that point there is very little the application can do to "harden" itself.
This is because the nature of the javascript engine is very dynamic and the
runtime can be customized in the runtime on the fly. Webview environments
aren't like other environments where you can minimize impact by implementing
permission models or limiting access to resources, etc. The JS runtime can
simply change anything it wants. As noted in the security email thread, there
are best practices to follow to prevent unauthorized code from executing and if
users follow them they are expected to be safe. For reference these guidelines
can be found
[here](https://cordova.apache.org/docs/en/12.x/guide/appdev/security/index.html)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
