iOS and Android Mobile App Developers do not think about mobile app security enough. They believe because their apps run inside containers, like Dalvik, they do not have the same security weaknesses as Windows, where low-level I/O is exposed. And because their apps do not run inside browsers like Chrome, they do not have as many exploitable flaws as browser extensions like Adobe Flash.

That is true. But gaining access to the OS in a zero-day type of attack is only one aspect of security. That kind of attack is usually associated with state cyber attacks. So it is quite rare.

That approach to security we can say is the inside-out view. What is more important to check is outside-in, as it is more common and easier to exploit.

The biggest every day concerns mobile App Developers face are inspecting which domains their app is connecting to, whether the SSL certificate has been compromised, and whether the frameworks they use contain any malicious code or vulnerabilities. The best way to do that is to use a third party service that tracks malicious code and domains and have them perform a security assessment on your  app.

Here we look at five areas mobile app developers should pay attention to. These are just some of what the security assessment will be looking for.

Encrypt the Secret Key

When you connect to, for example Twitter, you need two keys: an API key and a secret key. In the worst possible situation, a hacker can steal both of those. Then they can pretend to be your app. At MI3 security, we have found such replay attacks and have reported them to Facebook and others.

Open Source Libraries and GitHub

Most code uses external libraries and frameworks. This makes it easy to do things like parse JSON objects. With Java, the language used on Android, the problem is there is no third party checking these repositories like there are with, for example Python modules and Ubuntu apps. Instead the developer just downloads and integrates 3^rd party libraries and trusts that someone has vetted it.

It is necessary to check these frameworks and blacklist those with vulnerabilities that can be compromised by hackers. Hackers can contribute code to open source frameworks just like the regular developers. So it particularly important to check those frameworks when their mechanism for self-policing is not secure.

Connecting to Unpatched and Blacklisted Servers

Public and private companies, like SpamHaus.org, crowdsource IP addresses and domains that have security flaws and risky behavior.

These flagged servers include spambots, open smtp servers, DNS resolvers, malware distribution and sites with vulnerabilities.

A server can be come vulnerable overnight with a zero day attack so there is the need to monitor your app and see where it is connecting and continually monitor the server end points. Companies use Mi3 Security to do that continual monitoring for them.

SSL Chain of Trust

Traffic from the mobile app to the REST webservice in the cloud needs to be encrypted. But just having an SSL certificate on the server does not mean there are no security issues.

A hacker can forge a fake SSL certificate and perform a MITM attack. But what they cannot do effectively is fake the chain of trust.

Take a look at the certificate shown below for the Wellsfargo.com website. That certificate was issued by Symantec. A hacker cannot issue and sign a certificate and pretend to be Symantec. But they can write their own root certificate into the certificate store on the device if they find a way to exploit that.

Poisoned Advertising and Data Brokers APIs

There is the need to check the advertising domains to which your app is connecting and remove those that have been blacklisted from your code. The reason is not everyone uses just DoubleClick, which is Google’s ad business, or other trusted sites. There are many other data brokers, advertisers, trend monitors, widgets, social media plugins, video players, etc. Mobile app developers need to be security minded and research which APIs you integrate as you do not always know where they are sending your user data just by looking at code.

You can see the inherent risk by looking at an example from a browser.

A popular web browser extension is Ghostery, shown below. It shows all the sites that a website is connecting to and lets you block any of those.

Take a look below. It is remarkable that when you go to the the website of, for example, the Huffington Post, you can see that single domain has opened connections to 12 other domains. The average person would be angry to find out that 12 other companies are tracking them. Are all of those companies honest or careful with their security?

Mobile app developers use advertising frameworks the like Amazon Mobile Ad Network or DoubleClick Ad Exchange. The mobile developer cannot know whether those ad companies and data brokers are doing business with reputable firms. So it is necessary to monitor and audit that.

Mobile app developers cannot be expected to police all of these issues. They need to use the same approach that anti-spam engines do, which is to consult third-party repositories. And they need to follow common sense best practices like keeping their API keys hidden.

The best common sense practice is to have a security assessment performed on your code during SDLC.

The post Five Areas of Security Mobile App Developers Overlook appeared first on .