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.
[Still going rogue in the cloud]
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.
7. Don't allow modified requests.
Rather than repeating a request, an attacker may choose to modify it. For example, the attacker may transfer money to a different account altogether. This can be prevented by using a shared secret or a cryptographic keypair. Creating an HMAC of the request and sending it to the server with the request allows the server to confirm that the request has not been modified.
Conclusion
In order to build robust mobile applications, developers must check each measure off this list. Any single one left unaddressed leaves an application open for attack or abuse. However, it is easy to see how they all work together: By distrusting the client (no. 1) or assuming that an attacker is eavesdropping on communications (no. 2), the developer will want to limit the amount of time an attacker has to attack the application (no. 3). A secret key (no. 4) can be used to sign the content (no. 7), including the time stamp (no. 5) and the NONCE (no. 6) to ensure that none of those three data points are modified.
Dan Kuykendall is co-CEO and CTO of NT OBJECTives, Inc. His talk, "Revenge of the Geeks: Hacking Fantasy Sports Sites," will be one of the highlights of AppSec USA 2013, Nov. 18-21, NYC.