Secure Mobile Application
Development
Part 2: Transport Layer Security
Jahmel Harris, Technical Director
Attack Scenario: 2, 3
When developing a mobile application, we should put in effort to ensure that the network layer is secure and is therefore not susceptible to eavesdropping. This should be true whether the application connects to the Internet via wifi or through the mobile network. Because of this, care should be taken to make sure all communication is performed over an encrypted channel. Although it could be argued that only sensitive information should be encrypted, due to the risk of accidentally classifying data incorrectly or a vulnerability existing that be exploited by injecting traffic into unencrypted communications, we recommend all network traffic is be encrypted and TLS employed where possible.
This principle should be applied to all communications including bluetooth and NFC where possible.
Consider the following when using TLS:
- All traffic should be encrypted. This includes traffic from third party libraries.
- Correct cipher strength should be used and weak ciphers should be disabled.
- TLS 1.2 should be used and everything weaker should be disabled.
- Certificates should be validated correctly and not weakened for testing purposes.
- Self signed certificates should not be accepted unless certificate pinning is in use.
- For particularly sensitive information, additional encryption should be applied on data before sending over TLS.
- Data sent over secure connections should not be logged.
iOS
App Transport Security was introduced in iOS 9 and forces applications to use TLSv1.2. This should not be weakened unnecessarily. For cases where this is unavoidable, it should be a vulnerability that is risk accepted and only done on a whitelist basis. Wildcards should not be used and nothing weaker than TLS 1.2 should be accepted.
Android
Newer version of Android (API > 24) support Network Security Configuration, allowing us to easily opt out of cleartext traffic. This can be done by specifying