This guest column is by Shahid Abbasi
Between mobile devices, wearable and the induction of Internet of Things (IoT), organizations now face the difficult choice of the level of penetration these devices should be safely allowed, into the corporate network.
With almost 74% of organizations adopting the Bring Your Own Device to work culture, ensuring the security of sensitive corporate information is becoming increasingly difficult.
Mobile Application Management (MAM) and Mobile Device Management (MDM) are the tech world’s current version of enterprise mobility security. But, they are often rendered inadequate and restrict organizational productivity. It’s far from being a perfect solution.
State of Cyber Crime
Cybercriminals are targeting startups and mid-market companies in the hopes of finding easy access to their corporate networks. Cyber attacks on midsize companies (with revenues ranging from $100 million to $1 billion) increased by a staggering 64% from 2013-2014. 23% of these attacks came through unsecure mobile applications.
Considering enterprise mobility is still in its infancy, expecting a complete secure solution to the risks and threats it imposes may be a little unreasonable. Therefore, until enterprise security solutions come up to speed with the threats of this era, a new angle to securing corporate data must be undertaken.
And, that is developing secure mobile applications.
According to Gartner, more than 75% apps would fail a basic security test.
Moreover, 78% of the top 100 Android and iOS apps have been hacked.
Emphasis should be put on mobile application developers to stop cutting corners and integrate concrete security protocols into the code, itself.
5 Common Security Pitfalls Most App Developers Overlook
If you’re working with an app developer to build your app, press upon him the need for security. Make sure he uses the best coding practices when it comes to managing sensitive data. Here are the X most common security dangers developers can easily circumvent but don’t, allowing cybercriminals a way in to hack the app. Just making sure your app developer doesn’t skirt around these issues can go a long way in making your app is considerably secure:
Insecure Data Storage – The Starbucks app went from one of the most widely used app for mobile payments to an app people intentionally stayed away from. All because of Starbuck’s insecure data storage practices. Before the fiasco, Starbucks had 10 million customers, within 24 hours of the incident; it was down to 7 million.
The app stored all of its users’ confidential data such as passwords and IDs in plain text format – without any form of encryption. Combine that with the fact most people tend to use the same ID and password across multiple accounts, the thieves who breached the app, got access to other private accounts of the victims, as well.
A few simple precautions go a long way to securing the app, such as:
Storing the user’s credential off-device (on a secure server)
Avoid using encryption libraries for example Commoncrypto
Avoid using NUserDefaults and plists, at all costs
Weak Server Side Controls – the servers your app connects to for retrieving and storing data should have security protocols in place to prevent unauthorized devices/users from accessing it. Weak server side controls invite input attacks. Therefore, input checks and validations should be coded into the apps to minimize the load of the work the servers need to perform. Here are a few ways your app development company can reduce the load on the servers and increase app security:
Input validation (to validate the information entered into the app before being sent to the server)
Canonicalization– input data should be converted into its simplest form to ease data processing
Create a while list for valid data/input.
The output given to the user should be encoded to prevent attacks such as format string attacks.
Insufficient Transport Layer Protection – if the flow of data being exchanged between the client(app) and the server is not encrypted strongly, threat agents can hack into the data stream and view sensitive information while it’s still in limbo (in transit) between the two ends. To ensure sufficient transport layer security; make sure your app development company integrates TLS/SSL encryption with powerful algorithms between communications. Here are a couple ways to enforce proper certification:
Prohibit the required parameters from accepting all certificates (in iOS and Android)
Implement the CFNetwork API that uses the updated SSL and TLS version
Client Side Injection – Applications that are downloaded into the user’s device and run from it can be victims of hostile injections.
Some applications allow openings to accept data from external sources. Attackers can inject text based (such as SQL injections) attacks through these openings to exploit the user’s data. Such apps should have input validation across all application entry points.
Poor Sessions Handling – Remember when you were accessing your bank accounts but got distracted. When you return to it you find a “Session Times Out – Please Login Again” message. This means your bank is implementing a session handling best practice. Application session handling best practices are very similar to those of web application best practices. Here are a few other security measures your app should have to boost sessions handling:
Avoid including device identifiers in to the app such as MAC Address, IMEI, UDID IPs etc)
Protect integrity and confidentially of session tokens via SSL/TSL
The above are not the only security pitfalls 75% app are open to, but they are the most common to be overlooked by inexperienced or careless app developers. Unless you know of these dangers and their advised solutions, you won’t be able to identify whether or not your app is secure. Don’t just take the word of your app developers on it.
Learn from Starbucks’ mistakes and make sure the app developer you’ve hired to build your app writes safer and smarter codes.
Disclaimer: This is a guest post. The statements, opinions and data contained in these publications are solely those of the individual authors and contributors and not of iamwire and the editor(s).
Share your expertise here