http://jvn.jp/en/jp/JVN39218538/Android apps that use SSL/TLS protocols for secure communication should properly verify server certificates. The basic verification includes:
...
A developer has the freedom to customize their SSL implementation, and thus has a responsibility to properly use SSL depending on . The developer should properly use SSL as appropriate to the intent of the app as well as app and the environment the apps are used in. If the SSL is not correctly used, a user's sensitive data may leak via the vulnerable SSL communication channel.
Fahl et al [Fahl 2012] summarises describes the following patterns of the insecure use of SSL:
- Trusting All Certificates
...
- : The developer implements the TrustManager interface so that it will trust all the server certificate (regardless of who signed it, what is the CN etc.)
- Allowing All Hostnames
...
- : The app does not verify if the certificate is issued for the URL the client is connecting to.
...
- For example, when a client connects to
example.com, it will accept a server certificate issued forsome-other-domain.com. - Mixed-Mode/No SSL
...
- : A developer mixes secure and insecure connections in the same app or does not use SSL at all.
On Android, using HttpURLConnection is recommended for HTTP client implementation.
Noncompliant Code Example
The following code implements a custom MySSLSocketFactory class that inherits javax.net.ssl.SSLContext:
...
sAllowAllSSL, which is a static member of the DefineRelease class, is initialized to true in its static constructor. This will enable the use of SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. As a result, host name verification that should take place when establishing an SSL connection is disabled and will lead to the same situation as all the certificate is trusted.
Compliant Solution
The compliant solution may vary, depending on the actual implementation. For examples of secure implementation such as using a self-signed server certificate, please refer to "Android Application Secure Design/Secure Coding Guidebook", Section 5.4 Communicate by HTTPS.
Risk Assessment
Not properly verifying the server certificate on SSL/TLS may allow apps to connect to an imposter site, while fooling the user into thinking that the user is connected to an intended site. One example of associated risks is that this could expose a user's sensitive data.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
DRD19-J | highHigh | probableProbable | mediumMedium | P12 | L1 |
Automated Detection
It is possible to automatically detect whether an application uses one of the three Android SDK packages named for establishing network connections, and to check if any of the methods from those classes are overriden by the application. It is not feasible to automatically determine the intent of the app or the environment the apps are used in.
Related Vulnerabilities
- VU#582497 Multiple Android applications fail to properly validate SSL certificates
- JVN#39218538 Pizza Hut Japan Official Order App for Android has a problem whereby it fails to verify SSL server certificates.
- JVN#75084836 Yome Collection for Android has a problem with management of IMEI.
- JVN#68156832 Yafuoku! contains an issue where it fails to verify SSL server certificates.
Related Guidelines
5.4 Communicate by Communicating via HTTPS |
...