7 Characteristics of a Secure Mobile App
When it comes to building secure mobile applications, errors most often occur in session management. By themselves, these mistakes do not present a significant risk, but the more mistakes made, the more vulnerable the application. And therein lies the problem: I often find several of these errors in any given app.
Tue, September 24, 2013
CSO — When it comes to building secure mobile applications, errors most often occur in session management. By themselves, these mistakes do not present a significant risk, but the more mistakes made, the more vulnerable the application. And therein lies the problem: I often find several of these errors in any given app.
In my upcoming talk at OWASP AppSecUSA 2013, I will detail one example of a vulnerable mobile app, in this case, a popular fantasy football application that when hacked, allowed individuals to change team line-ups and post imposter comments. Users who have not updated their mobile app to the most recent version are at risk of having their line-ups manipulated by other league managers or troublemaking hackers. Of course, this was fun for me, but also enlightening. My ongoing research continues to unearth patterns in session management vulnerabilities.
In the meantime, here is a checklist based on common mistakes that developers and security professionals can use to ensure proper session management of their mobile applications.
1. Don't trust the client.
The server should distrust every request from the application, treating it as a possible attack payload. Thus, the server should confirm the authenticity of every request.
2. Require encryption.
To prevent attackers from being able to read wireless communications from a mobile device, use SSL to encrypt the client and require a mobile certificate that can be validated.
3. Expire sessions.
Developers often allow mobile application sessions to remain active for a very long time so that users do not have to log back in. However, as long as the session is active, attackers can make malicious requests to the server. Developers are, in essence, trading away security in favor of a minor inconvenience to users.
4. Keep secrets.
A shared secret known only by the client and server, and used by the client to sign requests, prevents the server from accepting those that have been modified.
5. Limit the amount of time a request is valid.
The longer a request is valid, the greater the risk of an attacker intercepting and modifying or eavesdropping on it. All requests should be time stamped on the client side and expire after a period of time as defined on the server side.
6. Don't allow repeat requests.
Attackers can replay intercepted requests. The resulting impact can range from being merely annoying (as in the case of a repeat Tweet) to having dire consequences (for example, when a request to transfer money is re-sent). Developers can prevent repeat requests by using a NONCE (number used once.) The client generates a random number for each request. The server keeps track of these numbers to ensure that the requests are true and not being re-executed. If a repeat NONCE occurs, then the server knows that the request is invalid. The list of NONCEs stored on the server can be minimized by using a timestamp, as explained in number five.