How to make mobile apps safe(er)?
"But there's no keyboard on the screen, how are you going to hack my application?"
This is a question we hear from our clients relatively often and it's a good question. On the face of it mobile applications look relatively difficult to attack. With no keyboard on screen, how could an attacker possibly enter unwanted data? From a developer point of view, the feeling can be that once an application is produced, it is bundled up and installed on the mobile platform and is relatively safe from intrusion.
That, however, is potentially a false sense of security. Mobile applications can contain just as many of the same type of security issues as web applications, as well as many that affect only the mobile environment. These range from disclosing sensitive information in the code or logs of an application, being able to interact with elements of the phone such as removable storage, through to old favourites like cross-site scripting, insecure storage and Structured Query Language (SQL) injection (although technically some of these are related to the associated web services, discussed later).
For example, it's possible to easily reverse engineer the codebase of an Android application, which means if it's not obfuscated, any information contained within is available, such as hard coded credentials and API keys. BSI Digital Trust (BSI) have also seen traditional, well known web application issues like cross-site scripting (XSS) which can be used to access the device storage via an application, for example.
How can developers ensure apps are safe(er)?
Knowing these vulnerabilities exist, how they work and how to look for them is a big part of developing more secure applications. Development teams that integrate Secure Software Development Lifecycle (SSDLC) elements are much more likely to catch these vulnerabilities sooner, and therefore produce more secure, robust applications. Not only does building in security improve the overall risk rating of an application but it’s far more cost effective than retrofitting it at a later date, not to mention the cost in reputation and perhaps even fines once a flaw is publicly disclosed.
A big part of making applications safer is for developers to understand how the bad guys work, in effect, to learn how to 'hack' their own applications. Understanding these flaws and actively testing and exploiting them will allow teams to fix them way before they end up in the hands of malicious users who will be doing the same thing.
"OK, I know the most common vulnerabilities, but how do I find them?"
Each mobile platform has its own unique ecosystem which can make it easier or harder for an application to be attacked (or tested), and to carry out any kind of testing requires tools.
There are a great many tools out there for developers to allow them to write more secure code. From open source IDE plugins to commercial code scanning services, the range is large and it is up to an organization to find something to meet their experience and budget.
Overall the Android platform offers more scope to analyse an application and as the platform is less restricted there are a much larger range of tools and techniques to attack applications on this platform.
For hands on Android developers, BSI have developed the Android Secure Testing Framework (ASTF) tool which allows developers to easily use key Android testing tools, with minimal configuration or effort. It has a simple interface to support developers with both static and dynamic analysis of their Android applications, making it easier to discover weaknesses in applications.
It's worth knowing that it's not just the applications themselves that are at risk. Most applications in the app stores today involve some kind of 'account', or shared experience. This often provides the ability to use the application across multiple devices with the same user experience, as well as providing the vendor with an opportunity to send some choice marketing direct to its users.
To facilitate this functionality, these mobile applications will use some kind of web services. With no front-end for users to enter information, these can often be forgotten in terms of protection as it is assumed the only thing that will interact with these is the mobile application itself. Step in an attacker with an intercept proxy and suddenly the requests are not what the web services are expecting.
Conclusion
Mobile applications present a range of different vectors for attack, some that are the same as traditional web applications and some that are unique to the mobile environment. There is no real substitute for professional penetration testing, but developers who are aware of common vulnerabilities and how to test for them are much less likely to have their application exploited once it enters the app stores and attackers can get their hands on them.
