Без рубрики

How secure are your mobile apps?

Ask any enterprise mobile developer and the answer will almost certainly be that security is a top priority. But smart IT departments should be asking more questions than that, and developers should be prepared to answer them.

Just saying your app encrypts its data isn’t enough.

For organizations to properly evaluate whether the app meets their security needs, you should also be able to communicate when, where, how, and how often encryption is used – not to mention what kind of encryption and how strong it is.

And that’s only the beginning. As organizations grow more aware of the issues around mobile security, they’ll begin asking app developers a whole list of tough questions, such as:

Is data encrypted whenever and wherever it’s stored?

Built-in mobile OS security is only reliable on non-rooted, non-jailbroken devices where the user has set a passcode. In other words, it shouldn’t be trusted.

Developers should be using libraries like Common Crypto and javax.crypto to encrypt sensitive data themselves – including personally identifying information, protected health information, passwords, tokens, cookies, log files, and more.

And that doesn’t just apply to data written to the filesystem. Just for starters, extracting data from the device’s SQLite database is relatively trivial, so anything written to it should also be encrypted using something like SQLCipher. For encryption to be effective, it needs to be pervasive, with no gaps where an attacker can sneak through.

Does the app use HTTPS encryption – and enforce it?

It’s easy to become complacent regarding the security of network communications, too.

Switching on HTTPS is a good first move, but it shouldn’t end there. Apps should always validate the SSL certificate, and to further increase trust, developers should either pin the server’s certificate in their apps or use two-way SSL authentication.

Backend developers, likewise, have a responsibility to ensure that the server only supports strong protocols and ciphers, and that it can’t be made to fall back to less secure ones.

Has the app binary been scrubbed of sensitive information?

App binaries aren’t black boxes. They can be decompiled, reverse engineered, analyzed both statically and at runtime, and dissected using mobile forensic software. Developers should assume that any hard-coded sensitive information like passwords and encryption keys can be retrieved from the binary – so those things shouldn’t be there.

Dynamically generated keys (i.e. via PBKDF2) should be preferred over hard-coded, static ones, and when there’s no other choice, White Box Cryptography techniques should be applied.

Have steps been taken to thwart reverse engineering and analysis?

Developers can take further steps to make their apps harder to inspect, too.

Code and control flows can be obfuscated. Symbols can be stripped or renamed to make code and data harder to identify, and strings can be encrypted. An app can attempt to verify its own resources, to ensure they haven’t been tampered with.

Although often overlooked, such measures can make it much harder to identify an app’s attack surface, while generally having little to no impact on performance.

Is the mobile backend as secure as the app itself?

Also too often overlooked is that mobile security doesn’t end with the app itself. Backend APIs can present huge opportunities for attack, so each one should be tested and hardened. They should be able to validate the presence, length, range, type, and format of all their inputs.

They should also deal gracefully with malformed input, including extra key/value pairs. And developers should ensure that their backend APIs are only accessible by their own apps, unless there’s a very strong reason to leave them open.

Meeting all of these requirements – and potentially more – probably sounds like a tall order, and it is.

Modern mobile apps are typically built by multi-source teams, often including not just an organization’s internal developers and business line staff but also third parties. Organizations will need to set and enforce security standards for each of these teams, and plan to review and update those standards regularly as mobile threats evolve.

Further complicating matters, HTML5 mobile apps and hybrid apps built with frameworks based on Apache Cordova, while popular, simply cannot provide all of these security and privacy mechanisms.

More modern tools and solutions, such as the Kony Mobility Platform, can help developers build robust security into their apps. But developers still need to be aware of the issues and they need to start asking themselves the right questions – because the organizations that consume their apps increasingly will be.

Remember, data is the life’s blood of the enterprise. As more and more enterprise data and workloads move from the data center to devices, the only apps that can be considered successes are the apps that can be considered secure.