0

I am performing a security research on a development framework for thick client & mobile applications. The framework allows developers to inject custom JavaScript in the DOM of any origin.

This functionality is not evident to the user. As per my understanding, unless the end user has given consent to control the DOM and the data in it, the application should not perform such actions. (Explicitly stated browser like applications can be considered an exception here.)

As per my understanding, this is a security flaw. Can anyone help me understand if this is an issue or not?

I wish I could share the exact scenario with more details, but if this is a security issue then I need to disclose it to the responsible party first.

Anders
  • 64,406
  • 24
  • 178
  • 215
Aditya Chaudhary
  • 149
  • 1
  • 1
  • 5
  • answers here may help you https://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important – Soufiane Tahiri Feb 25 '19 at 16:12
  • You're going to need to provide a lot more information. What kind of product/platform is this? (Normally, nothing except a browser, browser extension, or intercepting proxy could do this.) Who controls what scripts get executed where, and how secure is that control? (It's probably no big deal if only the user controls it; you can do that yourself with the browser dev tools or by typing a javascript: URI on any domain.) Is this the explicit purpose of the software (such as the GreaseMonkey/TamperMonkey browser extensions) or is this functionality unintended or hidden from the user? – CBHacking Feb 26 '19 at 00:39

1 Answers1

1

It sounds like what you're saying is that an app development framework supports injecting arbitrary scripts into webviews displaying arbitrary origins. This is nothing new; they all do this. While a malicious app written using such a framework could potentially steal sensitive information, there are several things you need to consider:

  1. By default, the app won't have access to any sensitive data. Because the user would install an app that is independent of any other app (such as a browser), the app would start out with no cookies, stored passwords, or other credentials or session tokens. A user might choose to enter their credentials, but in that case the user is making an explicit choice to trust the app with those credentials. Whether or not the application is "browser-like" doesn't really matter here.
  2. This is definitely not a vulnerability in the framework. Indeed, it is essential functionality for a huge number of apps. In a browser (or browser-containing) app, it might be used for ad and tracker removal, password and form auto-fill, and integration with other non-web app functionality. In a non-browser-type app, it could provide a bridge between web-based and "native" UIs, or simply be used to (legitimately) obtain the session token after a user completes an OAuth login flow (which may be the only browser-based part of an app).
  3. Yes, it could be used maliciously, but so could any code you run (heck, there's websites that will use your browser's JS engine to try to mine cryptocurrencies for the site owner). There's no reason to privilege this particular case of "could be used maliciously" over others. Ultimately, it is the responsibility of the user to not install or run malicious apps, not of the framework developer to make it impossible to write untrustworthy apps on that framework (which is, again, impossible).
CBHacking
  • 40,303
  • 3
  • 74
  • 98