This is the first of two parts with best practices for writing secure code for mobile apps.
Hypertext Transfer Protocol Secure (HTTPS) is a more secure way to access the web. It’s a combination of two different protocols: Hypertext Transfer Protocol (HTTP) and SSL/TLS protocol and is a more a secure way of sending requests to a server from a client. Also, the communication is entirely encrypted, which means no one can know what you are looking for.
Also HTTPS Encryption defeats sniffing attacks by concealing the traffic’s meaning from everyone except those who know the secret of decrypting it. The traffic remains visible to the sniffer, but it appears as streams of random bytes rather than the plain text form of JSON/XML body, HTML, links, cookies, passwords, etc.
So, developers must restrain from using HTTP URLs in their apps. The server must enforce the use of HTTPS to prevent unsecure connections from being established.
The HTTP POST method does not expose information via the URL. With GET, actual information is passed as part of the URL, thus exposing information in server logs, browser history, or caches.
Also, sending sensitive information via GET parameters makes it easy to alter the data submitted to the server in sniffing attacks. Yet another security threat with GET is a situation in which a third party sends a link to the end user. As a rule, you cannot email a link that will force a POST request, but you most certainly can send a link with a malicious GET request.
The security should not rely on one channel of communication. It is best practice to use separate channels of communication for sharing sensitive information such as a PIN or password. For example, you can use an HTTPS network connection to share encrypted data between the client and server, and then use APNS/GCM or SMS to share the PIN or token/key with the client app.
That way, even if one channel of communication is compromised, the security of the overall system remains intact.
The SSL certificate from a provider that your app trusts means that there is verification to say that you are what you say you are. Otherwise, anyone can make their own certificate for google.com or thebank.com and pretend to be someone else.
For this reason, your HTTPS connection must reject all SSL certificates that are invalid for any reason.
Every platform publishes and promotes the use of an extensive set of secure coding practices and guidelines.Mobile App developers must be aware of and follow these known secure coding practices. More importantly they should be the part of the code review checklist.
Secure coding practices includes performing input validation, being careful with memory management, not using insecure C functions, avoiding the use of immutable containers when storing sensitive data, etc. But remember that this is just a subset of extensive list provided by the respective platforms.
Jailbroken and rooted devices are prone to a number of security threats, and can compromise a user’s personal or company data in many ways.
Some of these threats are; brute force attacks on passcodes; a malicious app with privileged access may drain battery life or destabilize the operating system; remote attackers can exploit a secure shell server on such a device, get access to your application’s sandbox, and copy sensitive data.
All apps must be able to detect jailbroken or rooted status of the device and must limit its functionality, erase data completely, or silently notify the authorities.
Examining the integrity and authenticity of the data and files transferred between your app and server can be of great importance to your app’s security. Simple implementation of hash functions for this can add great value to security.
Although when using hash functions for integrity, check the files and make sure you are using a different communication channel to deliver the hash than that used for data and files.
To learn more about writing secure code for mobile apps, read Part II of the blog.