[
https://issues.apache.org/jira/browse/CB-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094364#comment-14094364
]
Ian Clelland commented on CB-7291:
----------------------------------
[Link to email discussion thread|http://markmail.org/message/fqmbd2bbspmv4wzm]
I love the idea of using CSP for this, especially because it handles things
that our whitelist intercept code can't, like <video> tags and WebSockets.
The problem that I've found with it is that we can only enforce it for
single-page apps. We can inject our own CSP headers into the application's
start page very easily, but if the user can leave that page and load another,
then the headers will no longer apply. The WebView interface won't let use add
headers to subsequent pages, so it's up to the developer to include them in a
<meta> tag instead. (and malicious attackers, of course, won't)
For now, I would encourage devs to include that <meta> tag on *all* of the
pages in their apps, but we can't do it automatically.
If it turns out that we can, then I'd be on board with including that in the
4.0 branch. It's a much better way to do it. Then we'd only need the second
whitelist for launching intents, I think.
> Externally-launchable applications should be configurable
> ---------------------------------------------------------
>
> Key: CB-7291
> URL: https://issues.apache.org/jira/browse/CB-7291
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
> Affects Versions: 3.5.0
> Reporter: Ian Clelland
> Priority: Critical
> Fix For: 3.6.0
>
>
> Cordova Android versions up to 3.5.0 would launch any and all external
> applications by URL. Any URL not explicitly whitelisted was sent to the
> Android intent system for handling. This was the cause of the security
> vulnerabilities reported by IBM and disclosed in CVE-2014-3502.
> Cordova Android 3.5.1 was released to fix this, which it did by disabling
> explicit intents, and explaining how to use a plugin to block other URL
> schemes if desired.
> We want to have a better official solution than this, so that developers can
> easily configure which applications (sms, email, maps, etc) should be
> launchable from their Cordova app.
> *Proposal*
> The proposed solution is to maintain a second whitelist within the app, for
> URL patterns which may be used to launch external applications. Then, on URL
> loading, these tests will occur (in order):
> # URLs which are whitelisted internally (existing list) will cause internal
> navigation
> # URLs which are whitelisted externally (new list) will attempt to launch an
> intent to handle it
> # URLs which are not whitelisted at all (in neither list) will be blocked.
> *Configuration*
> URLs can be added to the new (external) whitelist through an extension to the
> {{config.xml}} whitelist syntax:
> {code}
> <access origin="sms:*" launch-external="yes" />
> {code}
> (Any non-empty value for the {{launch-external}} attribute will be considered
> "true" when parsing the {{config.xml}} file)
> *Open questions* (one about forward-thinking security, the other about
> backwards-compatibility):
> # What should the default external whitelist be in the application template
> that we ship? This will be the case for new apps build with 3.6.0.
> # What should the default external whitelist be when there are no {{<access
> launch-external="yes">}} tags in {{config.xml}}? This will be the case for
> apps which are upgrading to 3.6.0.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
