You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cordova.apache.org by mr...@apache.org on 2014/05/20 21:00:20 UTC
[2/2] docs commit: Tweaks after buildling
Tweaks after buildling
Project: http://git-wip-us.apache.org/repos/asf/cordova-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/cordova-docs/commit/bf97ed85
Tree: http://git-wip-us.apache.org/repos/asf/cordova-docs/tree/bf97ed85
Diff: http://git-wip-us.apache.org/repos/asf/cordova-docs/diff/bf97ed85
Branch: refs/heads/master
Commit: bf97ed85d01513a3fc23c87017bd3ac4b46958f5
Parents: 7e6d5b9
Author: Mike Billau <mi...@gmail.com>
Authored: Tue May 20 14:53:08 2014 -0400
Committer: mbillau <mi...@gmail.com>
Committed: Tue May 20 14:58:37 2014 -0400
----------------------------------------------------------------------
docs/en/edge/guide/appdev/security/index.md | 41 ++++++++++++------------
1 file changed, 20 insertions(+), 21 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/cordova-docs/blob/bf97ed85/docs/en/edge/guide/appdev/security/index.md
----------------------------------------------------------------------
diff --git a/docs/en/edge/guide/appdev/security/index.md b/docs/en/edge/guide/appdev/security/index.md
index 6263aad..eaec34c 100644
--- a/docs/en/edge/guide/appdev/security/index.md
+++ b/docs/en/edge/guide/appdev/security/index.md
@@ -17,18 +17,18 @@ license: Licensed to the Apache Software Foundation (ASF) under one
under the License.
---
-# Security and Whitelist Guide
+# Security Guide
-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.
+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:
-Whitelist
-iframes and the callback id mechanism
-Certificate Pinning
-Self-signed Certificates
-Encrypted storage
-General Tips
-
+* Whitelist
+* Iframes and the Callback Id Mechanism
+* Certificate Pinning
+* Self-signed Certificates
+* Encrypted storage
+* General Tips
+* Recommended Articles and Other Resources
## Whitelist
@@ -37,7 +37,7 @@ General Tips
* By default, the Whitelist on a newly created app will allow access to every domain through the `<access>` tag:
`<access origin="*">`
If you want network requests to be evaluated against the whitelist, then it is important to change this and only allow the domains to which you need access. This can be done by editing the application-level config file located at:
- `{project}/config.xml� (recent projects) or �{project}/www/config.xml` (older projects)
+ `{project}/config.xml` (recent projects) or `{project}/www/config.xml` (older projects)
* Android's Whitelist on Cordova 2.9.x is considered secure, however, it was discovered that if foo.com is included in the whitelist, foo.com.evil.com would be able to pass the whitelist test. This was fixed in Cordova 3.x.
@@ -46,13 +46,13 @@ If you want network requests to be evaluated against the whitelist, then it is i
## Iframes and the Callback Id Mechanism
-If content is served in an iframe from a whitelisted domain, that domain will have access to the native Cordova bridge. This means that if you whitelist a third-party advertising network and serve those ads through an iframe, it is possible that a malicious ad will be able to break out of the iframe and perform malicious actions. Because of this, you should generally not use iframes unless you control the server that hosts the iframe content. Also note that there are third party plugins available to support advertising networks. Note: This statement is not true for iOS, which intercepts everything including iframe connections.
+If content is served in an iframe from a whitelisted domain, that domain will have access to the native Cordova bridge. This means that if you whitelist a third-party advertising network and serve those ads through an iframe, it is possible that a malicious ad will be able to break out of the iframe and perform malicious actions. Because of this, you should generally not use iframes unless you control the server that hosts the iframe content. Also note that there are third party plugins available to support advertising networks. Note that this statement is not true for iOS, which intercepts everything including iframe connections.
## Certificate Pinning
-Cordova does not support true certificate pinning. The main barrier to this is a lack of native APIs in Android for intercepting SSL connections to perform the check of the server�s certificate. (Although it is possible to do certificate pinning on Android in Java using JSSE, the webview on Android is written in C++, and server connections are handled for you by the webview, so it is not possible to use Java and JSSE there.) Since Apache Cordova is meant to offer consistent APIs across multiple platforms, not having a capability in a major platform breaks that consistency.
+Cordova does not support true certificate pinning. The main barrier to this is a lack of native APIs in Android for intercepting SSL connections to perform the check of the server's certificate. (Although it is possible to do certificate pinning on Android in Java using JSSE, the webview on Android is written in C++, and server connections are handled for you by the webview, so it is not possible to use Java and JSSE there.) Since Apache Cordova is meant to offer consistent APIs across multiple platforms, not having a capability in a major platform breaks that consistency.
-There are ways to approximate certificate pinning, such as checking the server�s public key (fingerprint) is the expected value when your application starts or at other various times during your application�s lifetime. There are third-party plugins available for Cordova that can do that. However, this is not the same as true certificate pinning which automatically verifies the expected value on every connection to the server.
+There are ways to approximate certificate pinning, such as checking the server's public key (fingerprint) is the expected value when your application starts or at other various times during your application's lifetime. There are third-party plugins available for Cordova that can do that. However, this is not the same as true certificate pinning which automatically verifies the expected value on every connection to the server.
## Self-signed Certificates
@@ -62,7 +62,7 @@ The reason is that accepting self-signed certificates bypasses the certificate c
The principles described here are not specific to Apache Cordova, they apply to all client-server communication.
-When running Cordova on Android, using `android:debuggable=�true�` in the application manifest will permit SSL errors such as certificate chain validation errors on self-signed certs. So you can use self-signed certs in this configuration, but this is not a configuration that should be used when your application is in production. It is meant to be used only during application development.
+When running Cordova on Android, using `android:debuggable="true"` in the application manifest will permit SSL errors such as certificate chain validation errors on self-signed certs. So you can use self-signed certs in this configuration, but this is not a configuration that should be used when your application is in production. It is meant to be used only during application development.
## Encrypted storage
@@ -72,11 +72,11 @@ When running Cordova on Android, using `android:debuggable=
### Do not use Android Gingerbread!
* Set your min-target-sdk level higher than 10. API 10 is Gingerbread, and Gingerbread is no longer supported by Google or device manufacturers, and is therefore not recommend by the Cordova team.
-* Gingerbread has been shown to be insecure and one of the most targeted mobile OSs [http://www.mobilemag.com/2012/11/06/andriod-2-3-gingerbread-security/, http://bgr.com/2012/11/06/android-security-gingerbread-malware/].
+* Gingerbread has been shown to be insecure and one of the most targeted mobile OSs [http://www.mobilemag.com/2012/11/06/andriod-2-3-gingerbread-security/](http://bgr.com/2012/11/06/android-security-gingerbread-malware/).
* The Whitelist on Android does not work with Gingerbread or lower. This means an attacker can load malicious code in an iframe that would then have access to all of the Cordova APIs and could use that access to steal personal data, send SMS messages to premium-rate numbers, and perform other malicious acts.
### 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.
+* 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.
@@ -91,9 +91,8 @@ When running Cordova on Android, using `android:debuggable=
### 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.
-## Recommended Articles and other Resources
+## Recommended Articles and Other Resources
-HTML5 Security cheat sheet, detailing how to secure your HTML5 application: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet
-Phonegap's article on device security, such as using encrypted data:
-https://github.com/phonegap/phonegap/wiki/Platform-Security
-Whitepaper about well known security flaws in Webview based hybrid applications: http://www.cis.syr.edu/~wedu/Research/paper/webview_acsac2011.pdf
+* [HTML5 Security cheat sheet, detailing how to secure your HTML5 application](https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet)
+* [Phonegap's article on device security, such as using encrypted data](https://github.com/phonegap/phonegap/wiki/Platform-Security)
+* [Whitepaper about well known security flaws in Webview based hybrid applications](http://www.cis.syr.edu/~wedu/Research/paper/webview_acsac2011.pdf)