App development is becoming more and more popular, as web and software developers are migrating to the mobile industry. Apps have become a part of mainstream culture and entered our everyday lives – at increasing levels. The app economy is comprised of approximately 2 million apps and is expected to continue growing in the years to come.
Secure development on mobile applications, however, has not shown the same level of growth or maturity. As an Information Security firm, we’ve seen quite a few apps suffer from vulnerabilities that are linked to development bad practices, mainly due to lack of awareness. Secure development guidelines do exist in the community, while organisations like OWASP have accumulated a lot of experience in the field and are now offering much of this knowledge for free. In this article we’ll sum up the best practices and show you the best ways to build secure apps. We’ll concentrate on OWASP top 10 (and similar) vulnerabilities, as these are the most common ones found in mobile apps.
So, let’s go through the list of the top 10 mobile app vulnerabilities and how to avoid them.
1. Insecure Data Storage:
This vulnerability occurs because information that is considered confidential is not stored in the device in a secure manner. You shouldn’t assume that the devices themselves are safe. Devices can be stolen and/or tampered with, and the confidential data contained in them may be stolen. Also, you shouldn’t assume that users will protect themselves against this possibility. In order to avoid this vulnerability, the best practices are:
- Never store credentials on the device itself
- Sensitive information such as user authentication credentials should only be stored in the device’s keychain, using the necessary API
Specific guidelines for iOS developers:
- You could avoid using iOS Encryption Libraries such as Commoncrypto
- You should encrypt SQLite databases with SQLcipher
- You might want to avoid NSUserDefaults, as well as plists in general
- Keep in mind that the NSManagedObjects will be stored in an unencrypted database
For Android devs:
- You should use the SD Card Storage the javax.crypto.
- You can use the enterprise Android administration API to force encryption for local files by utilizing “setStorageEncryption”
2. Weak Server Side Controls
You should implement most controls against input attacks on the server side of the application. Nevertheless, app design should include input validation checks and controls, in order to reduce the load of work to be done by the server. Therefore, you could ensure that both the server side and the mobile client development security requirements include at minimum:
- Input validation. You can use this kind of data validation in order to detect, and therefore prevent, unauthorized input before it gets processed by the app itself
- Canonicalization. Data input in the app should be converted to its canonical (simplest) form in order to be processed by it
- White lists on allowable data. The white list validation approach allows only specific types of data as input to the application; everything else that’s not included in this list, is not authorized.
- Output encoding. You should encode the output that is presented to the user in order to prevent different kinds of attacks (e.g. XSS[1][2], format string attacks).
3. Insufficient Transport Layer Protection:
You should enforce the TLS/SSL encryption with strong algorithms between communications. A common development mistake is unencrypted connections from the application to 3d party companies. You should program your apps to display any certificate error or warning messages, so that the user is informed of the quality of the encrypted connection.
For iOS developers:
- Use the CFNetwork API that utilizes NSStreamSocketSecurityLevelSSLv3 / TLSv1.2.
- You should use,the setAllowsAnyHTTPSCertificate parameter to prohibit accepting all certificates
For Android developers:
- You should set the AllowAllHostnameVerifier parameter to prohibit accepting all certificates
4. Client Side Injection
This category is comprised of a wide variety of input attacks against the application itself. General best practices for mitigation of client side injection vulnerabilities include the input validation of the application entry points, on the server side.
For iOS developers:
- You should consider using parameterized queries (e.g. ? instead of %@, libXML2 instead of NSXMLParser)
- In addition, you should avoid functions that are known to be prone to code vulnerabilities, such as strcat, strcpy, etc.
Android developers:
- You should use parameterized queries
- You should disable Javascript and plugin support for Webviews
- You should also disable file system access for Webviews
- You might consider using input validated intent filters between Activities
5. Poor Authorization and Authentication
These vulnerabilities are controlled mostly on the server side. The best practices that you should follow are the same with web applications. In addition to these rules, specifically for app development, device identifiers should be avoided (UDID, IPs, MAC Addresses, IMEI) since devices can be stolen and tampered with. Finally, out-of-band authentication tokens should not be sent to the same device.
6. Improper Session Handling
Although session handling mechanisms are mainly applied at the server side of the applications, secure session management practices can be applied at the devices themselves. As with the Authorization and Authentication, you should apply the web application Best Practices for session handling. Same as with authorisation and authentication best practices, device identifiers should be avoided here as well and you should implement safe mechanisms to revoke session on lost/stolen devices. Finally, the Confidentiality and Integrity of session tokens should be protected at all times (secure transmission via SSL/TLS connections, etc).
7. Security Decisions Via Untrusted Inputs
While these issues mainly affect Android-based applications, there has been precedent for iOS apps too. In general, the Best Practices that you should follow are the same with the web application ones. Specifically, input validation, output escaping, authorization controls and canonicalization should be carefully examined. Also, you should exercise extra caution when validating and accepting URL schemes.
8. Side Channel Data Leakage
This category involves data exchange that usually enhances app performance (e.g.: keystroke logging, web caches). As with Insecure Data Storage, you should build your app under the assumption that the device might be stolen. All side channels and 3rd party libraries included should be identified and enumerated for any possible data leakage that might occur. The application should be dynamically tested in order to verify that it doesn’t leak data during runtime.
iOS developers:
- You might consider disabling screenshots, along with cut-and-paste buffers. It is also recommended to disable keystroke logging from within the application.
9. Broken Cryptography
Crypto-keys should never be hard-coded in any construct (plaintext, property files, compiled binaries) and should be controlled at the server side.
10. Sensitive Information Disclosure
Different kinds of information may be considered sensitive in an app, as application logic/business purposes define that. You should keep mind that apps can be reverse-engineered and information like this might be exposed. The best practices in this case suggest avoiding storing private data inside the device; unless absolutely necessary.
The vulnerabilities presented here are not an exhaustive list – they’re just the tip of the iceberg!During the past year, we’ve witnessed numerous attacks against apps by direct code exploitation that usually leads to the device becoming compromised. We’ve also seen attacks that leverage various app weaknesses in order to hijack legitimate user sessions and steal information and money.
Since the app market is constantly growing, we expect to see an increase in the number of attacks against mobile devices themselves. So, if you want to keep up with the times, you should build your next apps with app security in mind.
For more insights, get in touch.
– George
Note: This article was first published on www.DeveloperEconomics.com