I have spent 12 years working in Mobility with many mobile platforms one could think of like BREW, Windows, QT, Symbian, J2ME, OEM proprietary mobile platforms, SHP, Android, iOS. It has been an amazing journey. Started with devices with few KB of RAM to devices now running 4 GB RAM and above.
All these years and for all mobile platforms there has always been a significant common ground. It was valid then, valid today and will be valid forever – Mobile Security.
Many businesses today are adopting mobility to streamline process, increase employee productivity, aiming at rapid growth. Gartner report shows that companies which are adopting mobility have simply increasing their reach by 18%. Mobility is playing such an important role, what starts bothering the enterprises is the security. Gartner reports suggest that about 75% of Mobile Applications are prone to security breaches due to wrong security practices adopted while developing a mobile application. This prediction is alarming and makes it compulsory for the developers to be well aware of the threats and methods to mitigate the risks.
Below I am listing some common pitfalls and how I went about alleviating them.
1) Weaker server side API: While writing one of the web-service using Express and NodeJS recently, I forgot to build security for my API’s exposed for the Mobile Client. Anyone who is aware of the API could exploit it. It made my server immediately prone to a variety of DoS attacks 1
Here I provided the hackers with a plated opportunity for Man-in-the-Middle (MITM) attacks.
I immediately patched this up using secure coding practices, limiting API access to authenticated users only.
2) Susceptible data on the move: While developing the web service I made one more error. I used HTTP exposing my server once again to (MITM) attacks. Most developers believe that just by using HTTPS this problem will be solved but they are wrong. This problem should be solved by using certificates signed by a valid CA, Certificate pinning or HTTP Strict Transport Security. In a typical SSL usage scenario, a server should be configured with a certificate containing a public key as well as a matching private key.
I have seen many application developers when using HTTPS will accept all certificates as shown below:
| SSLContext sc = SSLContext.getInstance(“TLS”);
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory()); |
Do not trust all certificates and don’t use self-signed certificates. For a good understanding, you can refer documentation2.
Payment, banking, and enterprise application developers should make sure that they rely on above mentioned methods for rendering their data safe when in transit.
Weak Authentication: Use Digest authentication over Basic authentication. Digest authentication communicates credentials in an encrypted form by applying a hash function to the username, the password, a server supplied nonce value, the HTTP method, and the requested URL. Whereas, Basic authentication uses unencrypted base64 encoding.
Basic authentication is generally used where transport layer security is provided such as https.
Try to safeguard your API with authentication such as token-based authentications. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record. For example, if you have a RESTful API for a library, it’s not okay to allow anonymous users to DELETE book catalog entries, but it’s fine for them to GET a book catalog entry. On the other hand, for the librarian, both of these are valid uses.
3) Susceptible data at Rest: Programmers often believe that no one can have access to their application database. Like in Android, usually application database resides in the /data folder which is not visible to a normal user. Rooted devices easily provide free access to this database. Hackers can also get hold of this data using platform vulnerabilities.
Developers can use various encryptions to safeguard data at rest.
4) Susceptible visible data: What I mean here by visible data is the text, image, any mime type rendered on a screen which a user can see. Sometimes enterprises don’t want their data like emails to be copy pasted, forwarded, cached, etc. Programmers should be sympathetic with such needs and utilize Mobile device management features. iOS, Android and Windows platforms boast of a robust set of MDM features.
5) In-app vulnerabilities: Native applications on Android and iOS are sandboxed normally giving them a comfortable secure environment. I was once working for a big security company and learnt running a cron application validator or a data validator a good option to safeguard an application against malicious intents. Programmers need to be extra careful when developing on hybrid or cross platforms. These platforms can also inject security vulnerabilities of their own. For eg: hackers increasingly aim for cross-platform vulnerabilities. When using Webview we need to be well aware of this3.
6) Not using Proguard: Prevent your mobile application from reverse engineering and malicious injection. Proguard should be enabled for all your mobile applications in production.
This blog is just an introduction on above discussed points. My aim was to keep it simple and easy to remember. It will soon follow-up with detailed write-ups on each topic. Please feel free to inbox me.
References:
1) https://en.wikipedia.org/wiki/Denial-of-service_attack
2) https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
3) https://securityledger.com/2015/08/the-challenge-of-securing-rest-apis/
4) https://www.google.co.in/work/android/
