I am looking for secure coding guidelines especially for mobile devices (Android and iOS). The languages I am interested in are Objective-C, JAVA and HTML5.
Would it be a good approach to use a "classic" security framework like the ESAPI for JAVA?
Asked
Active
Viewed 2,177 times
3 Answers
7
The issues are mostly the same as for secure software development in general.
Note that the most critical issue for secure software development is (1) integrating security into your software development lifecycle (so security is integrated into each step of the process: design, implementation, maintenance, ops), and (2) training of developers. It is a mistake to think that a software library or framework will magically ensure the security of your systems.
Mobile-specific issues. That said, here are some issues that are worth special attention in the mobile space:
Use secure communication channels. Be wary of HTTP or other unencrypted communications from the mobile app to servers elsewhere. Mobile phone users often use open Wifi networks for network connectivity, and those are at high risk for eavesdropping and man-in-the-middle attacks. Therefore, if you are sending anything confidential or security-critical at all (personal information, session cookies, authentication tokens), you should be using HTTPS, not HTTP. For custom network protocols, use TLS.
In general, if in doubt, be skeptical of any use of cleartext communications. Several high-profile apps had vulnerabilities of this form (they sent session tokens over cleartext HTTP); don't make the same mistake.
Store security-critical data securely. If you have a security-critical app, be wary of storing highly sensitive data on the mobile phone. For instance, you wouldn't want to store online banking passwords or that sort of thing on the mobile phone, and you might want to be careful about things like credit cards -- because if the mobile phone is stolen, that information becomes accessible to the thief. Theft and physical security are especially relevant, as it is so easy to steal, lose, or borrow a mobile phone.
Be careful about where to store application data. When storing application data, be careful about where you store it and what permissions you use. You don't want to inadvertently make sensitive information available to others apps. For instance, on Android, apps can store app-specific data in internal storage, on the SD card, or in a Content Provider. These have different security implications. Internal storage is secure by default (no other app can view the data) and is a good standard choice. The SD card is visible to other apps by default, and thus you need to use more care. If you store data on the SD card, at least set the file permissions so other apps can't read it, unless the data is intended to be shared. Content Providers can be protected using Android permissions.
Be respectful of user privacy. Don't do things that will creep your users out, if they find them out. Be up-front about what you app does. For instance, don't grab a copy of the user's address book and upload it to your servers (even if you have good intentions, like helping them connect with their friends) without user consent. Don't upload photos to a server behind the user's back.
One technique, when dealing with unique identifiers like device IDs or email addresses or phone numbers, that sometimes helps is to hash these identifiers before letting them leave the mobile phone. Don't just upload them to your server. Instead, hash them together with some app-specific value, then upload the hashes. In some cases, this can help improve user privacy.
Static analysis. Consider using static analysis tools that know about mobile-specific risks. For commercial tools, Fortify has a good reputation for this. For free tools, Comdroid and Stowaway check for a few risks that are specific to Android applications. However, beware that the free tools are not as comprehensive or polished as commercial offerings like Fortify.
Know your platform. Educate yourself about security risks specific to your particular mobile platform. For instance:
On Android, watch out for Webview related vulnerabilities. If you use webviews in your application, and you expose any of your application via the Javascript interface (e.g.,
webview.addJavascriptInterface(),webview.setWebViewClient()), then there are subtle security risks.On Android, watch out for Intent-related vulnerabilities. Android Intents are great; they allow for flexible cross-application communication. However, they also introduce new security risks. In particular, they share many of the potential risks of other communication channels: eavesdropping, spoofing, and man-in-the-middle attacks.
To avoid these problems, you know the risks. When using Intents for communications internal to your app, use only explicit intents (not implicit intents), and make sure all your intent receivers are internal only and are not exported to the world (beware that under some circumstances, Android will implicitly export components; you want to avoid that for ones which might receive your internal intents). When using Intents for cross-application communication, beware that Intents can be injected and eavesdropped if you are not careful. Therefore, when receiving an Intent that may have come from another application, treat its contents as untrusted and apply proper input validation/sanitization; you may want to check the sender of each Intent you receive, too. When sending implicit Intents that could be received by other apps, beware that they can be intercepted by malicious apps, so you should avoid including any sensitive or confidential information in the Intent. Avoid mixing internal communications with external communications.
For an introduction to Intent-related vulnerabilities, read here and here. More technical details can be found in the technical paper.
On Android, avoid permission re-delegation attacks. A permission re-delegation vulnerability is one where your app has a permission P, and is willing to respond to requests from other apps by performing operations that require permission P. If the other apps don't have permission P, you've just leaked the privileges associated with P to those other apps.
On Android, beware SQL injection vulnerabilities. On Android, Content Providers can be accessed through SQL queries. You'll want to avoid classic SQL injection vulnerabilities. In addition, if you build your own Content Provider and implement your own methods (like
delete,execSQL,rawQuery,update,updateWithNoConflict) to handle queries on the Content Provider, be careful when implementing those methods to avoid inadvertently introducing SQL injection vulnerabilities -- experience has shown that developers often introduce problems when implementing those methods. The best way to avoid these problems is the same as on non-mobile platforms: use parametrized queries (prepared statements).
Other resources. For Android, I highly recommend the following presentation:
For mobile security in general, I also recommend looking through the following questions:
2
I am not aware of any, but I also don't think its needed. The mobile platform is nothing new. At the end of the day a lot of the same vulnerabilities affect this platform. A lot of mobile apps are just web applications where the client side of the code is written entirely in HTML/JavaScript.
That being said Mobile developers violate CWE-602 more than developers for any other platform. To be honest its rather baffling because the vulnerability is so obvious. A good example is Super Meat Boy directly connected to a MySQL backend. There is a mobile version of this game, but its also a plain old desktop application, and they are both vulnerable to the same attack!
rook
- 46,916
- 10
- 92
- 181
2
Quite a few things have been published since the question was asked back in January, including:
- ENISA Smartphone Secure Development Guidelines for App Developers
- viaForensics Secure Mobile Development Best Practices (you need to register to download the PDF version)
- W3C Mobile Web Application Best Practices: W3C Recommendation 14 December 2010
- Denim Group: Secure Mobile Application Development Reference uTest: A Guide to Mobile App Testing Klocwork: Threat Modeling for Secure Embedded Software
There are also online courses available from Threadstrong.
Scott Pack
- 15,167
- 5
- 61
- 91
K.M. Goertzel
- 21
- 1