You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by kerrishotts <gi...@git.apache.org> on 2017/05/08 15:22:57 UTC

[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

GitHub user kerrishotts opened a pull request:

    https://github.com/apache/cordova-docs/pull/703

    CB-12770: revise security documentation

    This is a *rough* first pass at revising the security documentation. Comments are very welcome!
    
    ** NOT READY FOR MERGE YET **
    
    ### What does this PR do?
    
    Update security documentation
    
    ### Checklist
    - [X] [Reported an issue](http://cordova.apache.org/contribute/issues.html) in the JIRA database
    - [X] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/kerrishotts/cordova-docs CB-12770

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/cordova-docs/pull/703.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #703
    
----
commit 012f3f92e5bf1d4394b0d50f0f2e2bc7d2982bcc
Author: Kerri Shotts <ke...@gmail.com>
Date:   2017-05-08T15:19:19Z

    CB-12770: revise security documentation

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by devgeeks <gi...@git.apache.org>.
Github user devgeeks commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r117873392
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    --- End diff --
    
    "Stored" is a better choice. i.e.: `localStorage`, sqlite, etc.
    
    As for the threat model, mostly device-in-hand, but also XSS. If the user Jailbreaks or Roots... the horse has bolted... not sure there is any way to protect that, heh.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by filmaj <gi...@git.apache.org>.
Github user filmaj commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115320846
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    --- End diff --
    
    I feel like this statement is a little alarmist without providing concrete examples. It would also depend on what one means by "caching." Have you seen or heard of instances of this kind of attack happening in Cordova apps?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by filmaj <gi...@git.apache.org>.
Github user filmaj commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115321095
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    --- End diff --
    
    Maybe we can qualify the "it is possible to reverse engineer a Cordova app" statement? E.g. "an iOS or Android application can be simply unpacked and unzipped to reveal its web assets such as HTML and JS."


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by jcesarmobile <gi...@git.apache.org>.
Github user jcesarmobile commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115360483
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    +
    +> **Tip**: If you need to include advertising, use any of the many third-party plugins for Cordova. These are safer than executing arbitrary JavaScript from advertisers.
    +
    +## Content Security Policy
    +
    +The Content Security Policy `meta` tag, or CSP for short, is a very powerful mechanism you can use to control trusted sources of content. You can restrict various content types and restrict the domains from which content can be loaded. You can also disable unsafe and risky HTML and JavaScript, which can further increase the security of your app. The CSP tag should be placed in your app's `index.html` file.
    +
    +> **Note**: If your app has multiple HTML files and navigates between them using the browser's navigation features, you should include the CSP in each file. If using a framework, you only need to include the CSP on `index.html`.
    +
    +The CSP that Cordova typically uses in its templates looks like this (indented for clarity):
    +
    +```html
    +<meta http-equiv="Content-Security-Policy"
    +      content="default-src 'self' data: gap: https://ssl.gstatic.com;
    +               style-src 'self' 'unsafe-inline';
    +               media-src *">
    +```
    +
    +The above CSP enforces the following:
    +
    +* Media can be loaded from anywhere
    +* Styles can only be loaded from the app itself (`'self'`)
    +* Inline styles are permitted (`'unsafe-inline'`)
    +* All other network requests can only be from (or to) the app itself, `data:` URLs, the iOS Cordova bridge (`gap:`), or to Android's TalkBack accessibility feature (`https://ssl.gstatic.com`)
    +
    +By defalt, using this CSP will prevent _inline JavaScript_ and `eval()`. There are occasions, unfortunately, where a library may need one or the other, but this is rare and becoming moreso. If you must override this functionality, you can do so using the `script-src` directive.
    +
    +You should fully understand the CSP tag and the various directives that can be specified. More documentation is available at [Content Security Policy](https://developers.google.com/web/fundamentals/security/csp/) (via Google Developers) and Mozilla's [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) article.
    +
    +> **Warning**: Failure to include `gap:` in `default-src` may result in the app failing to work properly on iOS.
    +
    +> **Tip**: If you're using web sockets, include `ws:` (`wss:` if using SSL) in the `connect-src` directive.
    +
    +### Debugging the CSP
    +
    +Chances are good that when you add a CSP to your app, you'll encounter some problems. Thankfully both Google Chrome's developer tools and Safari's web inspector will make it glaringly obvious when the CSP has been violated. Watch the console for any violations, and fix accordingly. Generally the error messages are pretty verbose, indicating exactly what resource was rejected, and why.
    +
    +TODO: include example
    +
     ## Whitelist
     
    -* Read and understand the [Whitelist Guide](../whitelist/index.html)
    +The CSP is very useful for restricting what resources can be requested, but this doesn't eliminate the need for the whitelist. The whitelist is configured in `config.xml`. You should read and understand the [Whitelist Guide](../whitelist/index.html).
     
    -* Domain whitelisting does not work on Android API 10 and below, and WP8 for iframes and XMLHttpRequest. This means an attacker can load any domain in an iframe and any script on that page within the iframe can directly access Cordova JavaScript objects and the corresponding native Java objects. You should take this into consideration when building applications for these platforms. In practice this means making sure you target an Android API higher than 10, and that if possible you do not use an iframe to load external content - use the inAppBrowser plugin or other third-party plugins.
    +The Whitelist has several tags:
     
    -## Iframes and the Callback Id Mechanism
    +* `allow-navigation` tags control the resources to which the webview is allowed to navigate (top-level navigations only)
    +* `allow-intent` tags control the intents that can be used &mdash; for example, `tel:*` might be used to allow the dialoer to be displayed when the user taps a telephone link. This setting applies only to hyperlinks and `window.open()`.
    --- End diff --
    
    dialoer -> dialer


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by kerrishotts <gi...@git.apache.org>.
Github user kerrishotts commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115358440
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    +
    +> **Tip**: If you need to include advertising, use any of the many third-party plugins for Cordova. These are safer than executing arbitrary JavaScript from advertisers.
    +
    +## Content Security Policy
    +
    +The Content Security Policy `meta` tag, or CSP for short, is a very powerful mechanism you can use to control trusted sources of content. You can restrict various content types and restrict the domains from which content can be loaded. You can also disable unsafe and risky HTML and JavaScript, which can further increase the security of your app. The CSP tag should be placed in your app's `index.html` file.
    +
    +> **Note**: If your app has multiple HTML files and navigates between them using the browser's navigation features, you should include the CSP in each file. If using a framework, you only need to include the CSP on `index.html`.
    --- End diff --
    
    Yep, you're right. I'll change that. :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by devgeeks <gi...@git.apache.org>.
Github user devgeeks commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r117873777
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    +
    +> **Tip**: If you need to include advertising, use any of the many third-party plugins for Cordova. These are safer than executing arbitrary JavaScript from advertisers.
    +
    +## Content Security Policy
    +
    +The Content Security Policy `meta` tag, or CSP for short, is a very powerful mechanism you can use to control trusted sources of content. You can restrict various content types and restrict the domains from which content can be loaded. You can also disable unsafe and risky HTML and JavaScript, which can further increase the security of your app. The CSP tag should be placed in your app's `index.html` file.
    +
    +> **Note**: If your app has multiple HTML files and navigates between them using the browser's navigation features, you should include the CSP in each file. If using a framework, you only need to include the CSP on `index.html`.
    +
    +The CSP that Cordova typically uses in its templates looks like this (indented for clarity):
    +
    +```html
    +<meta http-equiv="Content-Security-Policy"
    +      content="default-src 'self' data: gap: https://ssl.gstatic.com;
    +               style-src 'self' 'unsafe-inline';
    +               media-src *">
    +```
    +
    +The above CSP enforces the following:
    +
    +* Media can be loaded from anywhere
    +* Styles can only be loaded from the app itself (`'self'`)
    +* Inline styles are permitted (`'unsafe-inline'`)
    +* All other network requests can only be from (or to) the app itself, `data:` URLs, the iOS Cordova bridge (`gap:`), or to Android's TalkBack accessibility feature (`https://ssl.gstatic.com`)
    +
    +By defalt, using this CSP will prevent _inline JavaScript_ and `eval()`. There are occasions, unfortunately, where a library may need one or the other, but this is rare and becoming moreso. If you must override this functionality, you can do so using the `script-src` directive.
    +
    +You should fully understand the CSP tag and the various directives that can be specified. More documentation is available at [Content Security Policy](https://developers.google.com/web/fundamentals/security/csp/) (via Google Developers) and Mozilla's [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) article.
    +
    +> **Warning**: Failure to include `gap:` in `default-src` may result in the app failing to work properly on iOS.
    +
    +> **Tip**: If you're using web sockets, include `ws:` (`wss:` if using SSL) in the `connect-src` directive.
    +
    +### Debugging the CSP
    +
    +Chances are good that when you add a CSP to your app, you'll encounter some problems. Thankfully both Google Chrome's developer tools and Safari's web inspector will make it glaringly obvious when the CSP has been violated. Watch the console for any violations, and fix accordingly. Generally the error messages are pretty verbose, indicating exactly what resource was rejected, and why.
    +
    +TODO: include example
    --- End diff --
    
    @kerrishotts ping me if I can help with an example


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by filmaj <gi...@git.apache.org>.
Github user filmaj commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115321603
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    --- End diff --
    
    Any recommendations on libraries to use for sanitization?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by filmaj <gi...@git.apache.org>.
Github user filmaj commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115322501
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    +
    +> **Tip**: If you need to include advertising, use any of the many third-party plugins for Cordova. These are safer than executing arbitrary JavaScript from advertisers.
    +
    +## Content Security Policy
    +
    +The Content Security Policy `meta` tag, or CSP for short, is a very powerful mechanism you can use to control trusted sources of content. You can restrict various content types and restrict the domains from which content can be loaded. You can also disable unsafe and risky HTML and JavaScript, which can further increase the security of your app. The CSP tag should be placed in your app's `index.html` file.
    +
    +> **Note**: If your app has multiple HTML files and navigates between them using the browser's navigation features, you should include the CSP in each file. If using a framework, you only need to include the CSP on `index.html`.
    +
    +The CSP that Cordova typically uses in its templates looks like this (indented for clarity):
    +
    +```html
    +<meta http-equiv="Content-Security-Policy"
    +      content="default-src 'self' data: gap: https://ssl.gstatic.com;
    +               style-src 'self' 'unsafe-inline';
    +               media-src *">
    +```
    +
    +The above CSP enforces the following:
    +
    +* Media can be loaded from anywhere
    +* Styles can only be loaded from the app itself (`'self'`)
    +* Inline styles are permitted (`'unsafe-inline'`)
    +* All other network requests can only be from (or to) the app itself, `data:` URLs, the iOS Cordova bridge (`gap:`), or to Android's TalkBack accessibility feature (`https://ssl.gstatic.com`)
    +
    +By defalt, using this CSP will prevent _inline JavaScript_ and `eval()`. There are occasions, unfortunately, where a library may need one or the other, but this is rare and becoming moreso. If you must override this functionality, you can do so using the `script-src` directive.
    +
    +You should fully understand the CSP tag and the various directives that can be specified. More documentation is available at [Content Security Policy](https://developers.google.com/web/fundamentals/security/csp/) (via Google Developers) and Mozilla's [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) article.
    +
    +> **Warning**: Failure to include `gap:` in `default-src` may result in the app failing to work properly on iOS.
    +
    +> **Tip**: If you're using web sockets, include `ws:` (`wss:` if using SSL) in the `connect-src` directive.
    +
    +### Debugging the CSP
    +
    +Chances are good that when you add a CSP to your app, you'll encounter some problems. Thankfully both Google Chrome's developer tools and Safari's web inspector will make it glaringly obvious when the CSP has been violated. Watch the console for any violations, and fix accordingly. Generally the error messages are pretty verbose, indicating exactly what resource was rejected, and why.
    +
    +TODO: include example
    --- End diff --
    
    Yeah an example would be rad! 💃 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by kerrishotts <gi...@git.apache.org>.
Github user kerrishotts commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115358385
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    --- End diff --
    
    OWASP has one that supports many different platforms: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Home



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by kerrishotts <gi...@git.apache.org>.
Github user kerrishotts commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115361265
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    +
    +> **Tip**: If you need to include advertising, use any of the many third-party plugins for Cordova. These are safer than executing arbitrary JavaScript from advertisers.
    +
    +## Content Security Policy
    +
    +The Content Security Policy `meta` tag, or CSP for short, is a very powerful mechanism you can use to control trusted sources of content. You can restrict various content types and restrict the domains from which content can be loaded. You can also disable unsafe and risky HTML and JavaScript, which can further increase the security of your app. The CSP tag should be placed in your app's `index.html` file.
    +
    +> **Note**: If your app has multiple HTML files and navigates between them using the browser's navigation features, you should include the CSP in each file. If using a framework, you only need to include the CSP on `index.html`.
    +
    +The CSP that Cordova typically uses in its templates looks like this (indented for clarity):
    +
    +```html
    +<meta http-equiv="Content-Security-Policy"
    +      content="default-src 'self' data: gap: https://ssl.gstatic.com;
    +               style-src 'self' 'unsafe-inline';
    +               media-src *">
    +```
    +
    +The above CSP enforces the following:
    +
    +* Media can be loaded from anywhere
    +* Styles can only be loaded from the app itself (`'self'`)
    +* Inline styles are permitted (`'unsafe-inline'`)
    +* All other network requests can only be from (or to) the app itself, `data:` URLs, the iOS Cordova bridge (`gap:`), or to Android's TalkBack accessibility feature (`https://ssl.gstatic.com`)
    +
    +By defalt, using this CSP will prevent _inline JavaScript_ and `eval()`. There are occasions, unfortunately, where a library may need one or the other, but this is rare and becoming moreso. If you must override this functionality, you can do so using the `script-src` directive.
    +
    +You should fully understand the CSP tag and the various directives that can be specified. More documentation is available at [Content Security Policy](https://developers.google.com/web/fundamentals/security/csp/) (via Google Developers) and Mozilla's [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) article.
    +
    +> **Warning**: Failure to include `gap:` in `default-src` may result in the app failing to work properly on iOS.
    +
    +> **Tip**: If you're using web sockets, include `ws:` (`wss:` if using SSL) in the `connect-src` directive.
    +
    +### Debugging the CSP
    +
    +Chances are good that when you add a CSP to your app, you'll encounter some problems. Thankfully both Google Chrome's developer tools and Safari's web inspector will make it glaringly obvious when the CSP has been violated. Watch the console for any violations, and fix accordingly. Generally the error messages are pretty verbose, indicating exactly what resource was rejected, and why.
    +
    +TODO: include example
    +
     ## Whitelist
     
    -* Read and understand the [Whitelist Guide](../whitelist/index.html)
    +The CSP is very useful for restricting what resources can be requested, but this doesn't eliminate the need for the whitelist. The whitelist is configured in `config.xml`. You should read and understand the [Whitelist Guide](../whitelist/index.html).
     
    -* Domain whitelisting does not work on Android API 10 and below, and WP8 for iframes and XMLHttpRequest. This means an attacker can load any domain in an iframe and any script on that page within the iframe can directly access Cordova JavaScript objects and the corresponding native Java objects. You should take this into consideration when building applications for these platforms. In practice this means making sure you target an Android API higher than 10, and that if possible you do not use an iframe to load external content - use the inAppBrowser plugin or other third-party plugins.
    +The Whitelist has several tags:
     
    -## Iframes and the Callback Id Mechanism
    +* `allow-navigation` tags control the resources to which the webview is allowed to navigate (top-level navigations only)
    +* `allow-intent` tags control the intents that can be used &mdash; for example, `tel:*` might be used to allow the dialoer to be displayed when the user taps a telephone link. This setting applies only to hyperlinks and `window.open()`.
    --- End diff --
    
    nice catch!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by piotrowski <gi...@git.apache.org>.
Github user piotrowski commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r117999300
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    --- End diff --
    
    Link to InAppBrowser would be great here


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by piotrowski <gi...@git.apache.org>.
Github user piotrowski commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r118000396
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    +
    +> **Tip**: If you need to include advertising, use any of the many third-party plugins for Cordova. These are safer than executing arbitrary JavaScript from advertisers.
    +
    +## Content Security Policy
    +
    +The Content Security Policy `meta` tag, or CSP for short, is a very powerful mechanism you can use to control trusted sources of content. You can restrict various content types and restrict the domains from which content can be loaded. You can also disable unsafe and risky HTML and JavaScript, which can further increase the security of your app. The CSP tag should be placed in your app's `index.html` file.
    +
    +> **Note**: If your app has multiple HTML files and navigates between them using the browser's navigation features, you should include the CSP in each file. If using a framework, you only need to include the CSP on `index.html`.
    +
    +The CSP that Cordova typically uses in its templates looks like this (indented for clarity):
    +
    +```html
    +<meta http-equiv="Content-Security-Policy"
    +      content="default-src 'self' data: gap: https://ssl.gstatic.com;
    +               style-src 'self' 'unsafe-inline';
    +               media-src *">
    +```
    +
    +The above CSP enforces the following:
    +
    +* Media can be loaded from anywhere
    +* Styles can only be loaded from the app itself (`'self'`)
    +* Inline styles are permitted (`'unsafe-inline'`)
    +* All other network requests can only be from (or to) the app itself, `data:` URLs, the iOS Cordova bridge (`gap:`), or to Android's TalkBack accessibility feature (`https://ssl.gstatic.com`)
    +
    +By defalt, using this CSP will prevent _inline JavaScript_ and `eval()`. There are occasions, unfortunately, where a library may need one or the other, but this is rare and becoming moreso. If you must override this functionality, you can do so using the `script-src` directive.
    --- End diff --
    
    typo "defalt" => "default"


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by filmaj <gi...@git.apache.org>.
Github user filmaj commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115322154
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    +
    +> **Tip**: If you need to include advertising, use any of the many third-party plugins for Cordova. These are safer than executing arbitrary JavaScript from advertisers.
    +
    +## Content Security Policy
    +
    +The Content Security Policy `meta` tag, or CSP for short, is a very powerful mechanism you can use to control trusted sources of content. You can restrict various content types and restrict the domains from which content can be loaded. You can also disable unsafe and risky HTML and JavaScript, which can further increase the security of your app. The CSP tag should be placed in your app's `index.html` file.
    +
    +> **Note**: If your app has multiple HTML files and navigates between them using the browser's navigation features, you should include the CSP in each file. If using a framework, you only need to include the CSP on `index.html`.
    --- End diff --
    
    I feel like the 'if using a framework' line could be misinterpreted by someone with a bit less experience. I would change "if using a framework" to "if your app is a single-page application" or something like that. My intention with that change is to reinforce the already-made point that CSPs are per-page.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by kerrishotts <gi...@git.apache.org>.
Github user kerrishotts commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115357795
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    --- End diff --
    
    Yes, this needs to be worded better and have some concrete examples. :-) I think "caching" is the wrong word here (this was copied from the previous version) -- "store" is probably more accurate.
    
    I _think_ attacks would either have to be device-in-hand attacks (since you'd need to get into the file system -- that's when you hope the device is protected with a pin & is encrypted!) or malware / viruses that abused some security hole (or ran amuck on a rooted/JB'd device). OR, if the app stored data in a public area on the file system (say, on Android), that would be risky too. (Hopefully no one would do that, though...!) So yes... more examples of what is meant by this would be good.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by kerrishotts <gi...@git.apache.org>.
Github user kerrishotts commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115358538
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    +
    +> **Tip**: If you need to include advertising, use any of the many third-party plugins for Cordova. These are safer than executing arbitrary JavaScript from advertisers.
    +
    +## Content Security Policy
    +
    +The Content Security Policy `meta` tag, or CSP for short, is a very powerful mechanism you can use to control trusted sources of content. You can restrict various content types and restrict the domains from which content can be loaded. You can also disable unsafe and risky HTML and JavaScript, which can further increase the security of your app. The CSP tag should be placed in your app's `index.html` file.
    +
    +> **Note**: If your app has multiple HTML files and navigates between them using the browser's navigation features, you should include the CSP in each file. If using a framework, you only need to include the CSP on `index.html`.
    +
    +The CSP that Cordova typically uses in its templates looks like this (indented for clarity):
    +
    +```html
    +<meta http-equiv="Content-Security-Policy"
    +      content="default-src 'self' data: gap: https://ssl.gstatic.com;
    +               style-src 'self' 'unsafe-inline';
    +               media-src *">
    +```
    +
    +The above CSP enforces the following:
    +
    +* Media can be loaded from anywhere
    +* Styles can only be loaded from the app itself (`'self'`)
    +* Inline styles are permitted (`'unsafe-inline'`)
    +* All other network requests can only be from (or to) the app itself, `data:` URLs, the iOS Cordova bridge (`gap:`), or to Android's TalkBack accessibility feature (`https://ssl.gstatic.com`)
    +
    +By defalt, using this CSP will prevent _inline JavaScript_ and `eval()`. There are occasions, unfortunately, where a library may need one or the other, but this is rare and becoming moreso. If you must override this functionality, you can do so using the `script-src` directive.
    +
    +You should fully understand the CSP tag and the various directives that can be specified. More documentation is available at [Content Security Policy](https://developers.google.com/web/fundamentals/security/csp/) (via Google Developers) and Mozilla's [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) article.
    +
    +> **Warning**: Failure to include `gap:` in `default-src` may result in the app failing to work properly on iOS.
    +
    +> **Tip**: If you're using web sockets, include `ws:` (`wss:` if using SSL) in the `connect-src` directive.
    +
    +### Debugging the CSP
    +
    +Chances are good that when you add a CSP to your app, you'll encounter some problems. Thankfully both Google Chrome's developer tools and Safari's web inspector will make it glaringly obvious when the CSP has been violated. Watch the console for any violations, and fix accordingly. Generally the error messages are pretty verbose, indicating exactly what resource was rejected, and why.
    +
    +TODO: include example
    --- End diff --
    
    ;-) Will do :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by kerrishotts <gi...@git.apache.org>.
Github user kerrishotts commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r115357887
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    --- End diff --
    
    Mmm -- I like that much better. :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


[GitHub] cordova-docs pull request #703: CB-12770: revise security documentation

Posted by piotrowski <gi...@git.apache.org>.
Github user piotrowski commented on a diff in the pull request:

    https://github.com/apache/cordova-docs/pull/703#discussion_r118000286
  
    --- Diff: www/docs/en/dev/guide/appdev/security/index.md ---
    @@ -27,69 +27,155 @@ description: Information and tips for building a secure application.
     The following guide includes some security best practices that you should consider when developing a Cordova application. Please be aware that security is a very complicated topic and therefore this guide is not exhaustive. If you believe you can contribute to this guide, please feel free to file an issue in Cordova's bug tracker under ["Documentation"](https://issues.apache.org/jira/browse/CB/component/12316407).  This guide is designed to be applicable to general Cordova development (all platforms) but special platform-specific considerations will be noted.
     
     ## This guide discusses the following topics:
    +
    +* General Tips
    +* Plugins and Security
    +* Content Security Policy
     * Whitelist
    -* Iframes and the Callback Id Mechanism
     * Certificate Pinning
     * Self-signed Certificates
    +* Wrapping external sites and hot code push
     * Encrypted storage
    -* General Tips
     * Recommended Articles and Other Resources
     
    +## General Tips
    +
    +### Use InAppBrowser for outside links
    +
    +Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser's security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.
    +
    +### Validate all user input
    +
    +Always validate any and all input that your application accepts. This includes usernames, passwords, dates, uploaded media, etc. Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like `chrome://inspect`), this validation should also be performed on your server, especially before handing the data off to any backend service.
    +
    +> **Tip**: Other sources where data should be validated: user documents, contacts, push notifications
    +
    +### Do not cache sensitive data
    +
    +If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.
    +
    +### Don't use eval()
    +
    +The JavaScript function eval() has a long history of being abused. Using it incorrectly can open your code up for injection attacks, debugging difficulties, and slower code execution.
    +
    +### Do not assume that your source code is secure
    +
    +Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application.
    +
    +A sampling of what you should not include in your code:
    +
    +* Authentication information (usernames, passwords, keys, etc.)
    +* Encryption keys
    +* Trade secrets
    +
    +### Do not assume storage containers are secure
    +
    +Even if a device itself is encrypted, if someone has access to the device and can unlock it, you should not assume that data stored in various formats and containers is safe. Even SQLite databases are easily human readable once access is gained.
    +
    +As long as you're storing non-sensitive information, this isn't a big deal. But if you were storing passwords, keys, and other sensitive information, the data could be easily extracted, and depending on what was stored, could be used against your app and remote servers.
    +
    +For example, on iOS, if you store data in `localStorage`, the data itself is easily readable to anyone who has access to the device. This is because `localStorage` is backed by an unencrypted SQLite database. The underlying storage of the device may in fact be encrypted (and so it would be inaccessible while the device is locked), but once the device decrypts the file, the contents themselves are mostly in the clear. As such, the contents of `localStorage` can be easily read and even changed.
    +
    +## Plugins and Security
    +
    +Due to the way the native portion of Cordova communicates with your web code, it is possible for any code executing within the main webview context to communicate with any installed plugins. This means that you should _never_ permit untrusted content within the primary webview. This can include third-party advertisements, sites within an `iframe`, and even content injected via `innerHTML`.
    +
    +If you must inject content into the primary webview, be certain that it has been properly sanitized so that no JavaScript can be executed. _Do not try to sanitize content on your own; use a vetted third-party library instead!_
    +
    +> **Tip**: If you need to include advertising, use any of the many third-party plugins for Cordova. These are safer than executing arbitrary JavaScript from advertisers.
    +
    +## Content Security Policy
    +
    +The Content Security Policy `meta` tag, or CSP for short, is a very powerful mechanism you can use to control trusted sources of content. You can restrict various content types and restrict the domains from which content can be loaded. You can also disable unsafe and risky HTML and JavaScript, which can further increase the security of your app. The CSP tag should be placed in your app's `index.html` file.
    +
    +> **Note**: If your app has multiple HTML files and navigates between them using the browser's navigation features, you should include the CSP in each file. If using a framework, you only need to include the CSP on `index.html`.
    +
    +The CSP that Cordova typically uses in its templates looks like this (indented for clarity):
    +
    +```html
    +<meta http-equiv="Content-Security-Policy"
    +      content="default-src 'self' data: gap: https://ssl.gstatic.com;
    +               style-src 'self' 'unsafe-inline';
    +               media-src *">
    +```
    +
    +The above CSP enforces the following:
    +
    +* Media can be loaded from anywhere
    --- End diff --
    
    Reverse order of explanations to match the example meta tag


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org