You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cordova.apache.org by GitBox <gi...@apache.org> on 2020/04/07 11:24:14 UTC
[GitHub] [cordova-plugin-whitelist] kdrcetintas opened a new issue #53:
JavaScript Interface
kdrcetintas opened a new issue #53: JavaScript Interface
URL: https://github.com/apache/cordova-plugin-whitelist/issues/53
# Feature Request
## Motivation Behind Feature
People sometimes needs to be, dynamically add or remove url to navigation whitelist based on api responses at the application.
## Feature Description
addToNavigation
removeToNavigation
addToAccessOrigin
removeFromAccessOrigin
addToIntent
removeFromIntent
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cordova.apache.org
For additional commands, e-mail: commits-help@cordova.apache.org
[GitHub] [cordova-plugin-whitelist] kdrcetintas commented on issue #53:
JavaScript Interface
Posted by GitBox <gi...@apache.org>.
kdrcetintas commented on issue #53: JavaScript Interface
URL: https://github.com/apache/cordova-plugin-whitelist/issues/53#issuecomment-611924987
>
>
> I'm a little concerned about adding these APIs because having the ability to modify these during runtime I think will undermine the entire point of having a whitelist plugin.
>
> To summarise, the whitelist API protects your app by restricting javascript code that runs in your app from communicating with external servers unless you otherwise explicitly state so. Realistically this would probably never happen within your own code base, so this is more-or-less a line of defence if somehow your code base became compromised by reducing the potential attack vector by mitigating what malicious code can do.
>
> Should malicious code find its way into your codebase, they may be able to use device APIs and gain information. With a properly configured whitelist plugin, (hopefully) that is all they'll be able to do; they wouldn't be able to export that information to a remote server of their choosing. So by adding those APIs, you provide the tools required to bypass the intention of this plugin, which is to mitigate damage.
>
> Another feature that is similar to this plugin, but implemented at the browser level is the [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP). Which is also intended to mitigate XSS attacks and you cannot modify these policies during runtime either. They get parsed either from the HTTP header, or from the `meta` tag on load and do not get re-evaluated again during the lifetime of that page.
@breautek,
These are reasonable reasons to bypass this feature, but imagine that,
A dev need to create a webview application for a website, and needs to be dynamically change the website domain from the api level without send any update the cordova app. There is no alternative at cordova platform for build this kind of structre.
What is your suggestion?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cordova.apache.org
For additional commands, e-mail: commits-help@cordova.apache.org
[GitHub] [cordova-plugin-whitelist] breautek edited a comment on issue #53:
JavaScript Interface
Posted by GitBox <gi...@apache.org>.
breautek edited a comment on issue #53: JavaScript Interface
URL: https://github.com/apache/cordova-plugin-whitelist/issues/53#issuecomment-610383606
I'm a little concerned about adding these APIs because having the ability to modify these during runtime I think will undermine the entire point of having a whitelist plugin.
To summarise, the whitelist API protects your app by restricting javascript code that runs in your app from communicating with external servers unless you otherwise explicitly state so. Realistically this would probably never happen within your own code base, so this is more-or-less a line of defence if somehow your code base became compromised by reducing the potential attack vector by mitigating what malicious code can do.
Should malicious code find its way into your codebase, they may be able to use device APIs and gain information. With a properly configured whitelist plugin, (hopefully) that is all they'll be able to do; they wouldn't be able to export that information to a remote server of their choosing. So by adding those APIs, you provide the tools required to bypass the intention of this plugin, which is to mitigate damage.
Another feature that is similar to this plugin, but implemented at the browser level is the [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP). Which is also intended to mitigate XSS attacks and you cannot modify these policies during runtime either. They get parsed either from the HTTP header, or from the `meta` tag on load and do not get re-evaluated again during the lifetime of that page.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cordova.apache.org
For additional commands, e-mail: commits-help@cordova.apache.org
[GitHub] [cordova-plugin-whitelist] breautek commented on issue #53:
JavaScript Interface
Posted by GitBox <gi...@apache.org>.
breautek commented on issue #53: JavaScript Interface
URL: https://github.com/apache/cordova-plugin-whitelist/issues/53#issuecomment-610383606
I'm a little concerned about adding these APIs because having the ability to modify these during runtime I think will undermine the entire point of having a whitelist API.
To summarise, the whitelist API protects your app by restricting javascript code that runs in your app from communicating with external servers unless you otherwise explicitly state so. Realistically this would probably never happen within your own code base, so this is more-or-less a line of defence if somehow your code base became compromised by reducing the potential attack vector by mitigating what malicious code can do.
Should malicious code find its way into your codebase, they may be able to use device APIs and gain information, with a properly configured whitelist plugin, (hopefully) that is all they'll be able to do. They wouldn't be able to export that information to a remote server of their choosing. So by adding those APIs, you provide the tools required to bypass the intention of this plugin, which is to mitigate damage.
Another feature that is similar to this plugin, but implemented at the browser level is the [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP). Which is also intended to mitigate XSS attacks and you cannot modify these policies during runtime either. They get parsed either from the HTTP header, or from the `meta` tag on load and do not get re-evaluated again during the lifetime of that page.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cordova.apache.org
For additional commands, e-mail: commits-help@cordova.apache.org
[GitHub] [cordova-plugin-whitelist] breautek edited a comment on issue #53:
JavaScript Interface
Posted by GitBox <gi...@apache.org>.
breautek edited a comment on issue #53: JavaScript Interface
URL: https://github.com/apache/cordova-plugin-whitelist/issues/53#issuecomment-610383606
I'm a little concerned about adding these APIs because having the ability to modify these during runtime I think will undermine the entire point of having a whitelist plugin.
To summarise, the whitelist API protects your app by restricting javascript code that runs in your app from communicating with external servers unless you otherwise explicitly state so. Realistically this would probably never happen within your own code base, so this is more-or-less a line of defence if somehow your code base became compromised by reducing the potential attack vector by mitigating what malicious code can do.
Should malicious code find its way into your codebase, they may be able to use device APIs and gain information, with a properly configured whitelist plugin, (hopefully) that is all they'll be able to do. They wouldn't be able to export that information to a remote server of their choosing. So by adding those APIs, you provide the tools required to bypass the intention of this plugin, which is to mitigate damage.
Another feature that is similar to this plugin, but implemented at the browser level is the [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP). Which is also intended to mitigate XSS attacks and you cannot modify these policies during runtime either. They get parsed either from the HTTP header, or from the `meta` tag on load and do not get re-evaluated again during the lifetime of that page.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cordova.apache.org
For additional commands, e-mail: commits-help@cordova.apache.org
[GitHub] [cordova-plugin-whitelist] breautek commented on issue #53:
JavaScript Interface
Posted by GitBox <gi...@apache.org>.
breautek commented on issue #53: JavaScript Interface
URL: https://github.com/apache/cordova-plugin-whitelist/issues/53#issuecomment-612311102
> What is your suggestion?
Thought about this a bit, but I honestly cannot give a good answer. Bypassing and/or removing the whitelist plugin is not something I would recommend because like I said, you're making your app potentially vulnerable. Allowing your app to connect to anything (which is effectively what the suggested APIs will make possible) is like the equivalent to disabling your firewall.
To be clear, the vulnerability I'm talking about is only really a problem if malicious code find its way into your code base (which would be a problem in itself), the whitelist plugin (and the CSP) is kind of like your last line of defence. Even if you had malicious code, it cannot collect information and send it to a remote server to its choosing, unless of course the server is whitelisted. So the damage that it can do to you and your users is mitigated. I hope I'm explaining this part is clearly.
Ideally you would add every possible domain that you trust, but I understand that you say this needs to be dynamic and this is something that I cannot really provide any recommendations on because I don't know **why** it needs to be dynamic.
One idea that comes to mind that may pick the best of both worlds is having a proxy server. This way your app always connects to a single domain (or a group of subdomains) that you can trust, and the server can pull down your dynamic list of domains that it needs to redirect the original request to. This way the app itself is still locked down to trusted domains and the app cannot arbitrary allow access to random domains, but the proxy acts as an access control layer, allowing communication to certain endpoints as long as it is inside your dynamic list.
I know this may sound complicated solution, but it sounds like you have a complicated architecture :man_shrugging: Do take it with a grain of salt, obviously I lack a lot of knowledge about your project.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cordova.apache.org
For additional commands, e-mail: commits-help@cordova.apache.org