Proper session management is an ongoing challenge for mobile application developers. It’s not uncommon for mobile apps to have multiple session management errors, putting the application at risk. In my presentation this week at OWASP AppSecUSA 2013, I talk about a vulnerability in the Yahoo! Fantasy Football app that is exemplary of what we are seeing across the industry.
During vulnerability testing we found that previous versions of the Yahoo! Fantasy Football mobile app are vulnerable to session hijacking – the process of authenticating the user and ensuring an attacker isn’t impersonating a user or eavesdropping on a service. The vulnerability allows an attacker to impersonate another player on message boards and manipulate other players’ lineups. Yahoo was notified of the vulnerability and the newest version now requires SSL, which renders the traffic between the mobile app and the Yahoo! Fantasy Football API unreadable. However, the vulnerability still exists for mobile users who have not updated the application.
The Yahoo! Fantasy Football app is just one of many apps I have analyzed to determine where developers “drop the ball” when building mobile applications. My ongoing research continues to unearth patterns in session management vulnerabilities. Based on that research, here are the top seven measures 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 don’t 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 security for convenience.
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 key pair. 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. In most cases, a vulnerability in any single area isn’t a significant liability. However, the more mistakes that are made, the easier it is to attack the application. While the Yahoo! Fantasy Football app vulnerability is relatively benign, that won’t always be the case. As a whole, we need to start paying more attention to security during development and testing to eradicate these vulnerabilities.
Dan Kuykendall | NT OBJECTives
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.