Mobile Top 10 2014-M9
|Threat Agents||Attack Vectors||Security Weakness||Technical Impacts||Business Impacts|
|Application / Business Specific|
|Anyone with access to HTTP/S traffic, cookie data, etc.||Attack vectors include physical access to the device and network traffic capture||Malicious or accidental session hijacking||Unauthorized users gaining access to other users' accounts||Customers losing control of their accounts and/or data|
The M9 category deals with session handling and the various ways it can be done insecurely.
Improper Session Handling should be considered extremely similar to poor authentication. This is because once you are authenticated and given a session, that session allows one access to the application in question. In short, you must protect your sessions just as carefully as you protect your authentication mechanism.
Here are some examples of how it is often done improperly:
Failure to Invalidate Sessions on the Backend
Many developers invalidate sessions on the client side and not on the server side, leaving a major window of opportunity for attackers who are using HTTP manipulation tools. Ensure that all session invalidation events are executed on the server side and not just on the client.
Lack of Adequate Timeout Protection
Any mobile application you create must have adequate timeout protection on the backend components. This helps prevent both malicious and accidental potential for an unauthorized user to gain access to an existing session and assume the role of an authorized user.
Good timeout periods vary widely according to the sensitivity of the app, one's own risk profile, etc., but some good guidelines are:
- 15 minutes for high security applications
- 30 minutes for medium security applications
- 1 hour for low security applications
Failure to Properly Rotate Cookies
Another major problem with session management implementations is the failure to properly reset cookies during authentication state changes. Authentication state changes include events like:
- Switching from an anonymous user to a logged in user
- Switching from any logged in user to another logged in user
- Switching from a regular user to a privileged user
For each of these event types, it is critical that sessions are destroyed on the server side and that the cookies presented as part of the previous sessions are no longer accepted. Ideally, your application would even detect any use of said cookies and would report that to the appropriate security team.
Insecure Token Creation
In addition to properly invalidating tokens (on the server side) during key application events, it's also crucial that the tokens themselves are generated properly. Just as with encryption algorithms, developers should use well-established and industry-standard methods of created tokens. They should be sufficiently long, complex, and pseudo-random so as to be resistant to guessing/anticipation attacks.