This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Mobile Top 10 2014-M9"

From OWASP
Jump to: navigation, search
Line 14: Line 14:
  
 
{{Top_10_2010:SubsectionColoredTemplate|Improper Session Handling||year=2014}}
 
{{Top_10_2010:SubsectionColoredTemplate|Improper Session Handling||year=2014}}
−
The M9 category deals with session handling and the various ways it can be handled insecurely.
+
The M9 category deals with session handling and the various ways it can be done insecurely.
 
   
 
   
−
Insecure use of cryptography is common in most any application that uses encryption, and there are two mistakes in this area that lead to the most insecurity:
+
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:
  
 
<ol>
 
<ol>
−
<li>The Creation and Use of Custom Encryption Algorithms</li>
+
<li>Failure to Invalidate Sessions on the Backend</li>
−
<li>Use of Insecure and/or Deprecated Algorithms</li>
+
<li>Lack of Adequate Timeout Protection</li>
−
<li>Poor Key Management</li>
+
<li>Failure to Properly Rotate Cookies</li>
 +
<li>Insecure Token Creation</li>
 
</ol>
 
</ol>
  
−
==Creation and Use of Custom Encryption Protocols==
+
==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:
  
−
There is no easier way to mishandle encryption--mobile or otherwise--than to try to create and use your own encryption algorithms or protocols.
+
* 15 minutes for high security applications
 +
* 30 minutes for medium security applications
 +
* 1 hour for low security applications
  
−
Always use modern algorithms that are accepted as strong by the security community, and whenever possible leverage the state of the art encryption APIs within your mobile platform.
+
==Failure to Properly Rotate Cookies==
  
−
==Use of Insecure and/or Deprecated Algorithms==
+
Another major problem with session management implementations is the failure to properly reset cookies during authentication state changes. Authentication state changes include events like:
  
−
Many cryptographic algorithms and protocols should not be used because they have been shown to have significant weaknesses or are otherwise insufficient for modern security requirements. These include:
+
* 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
 +
* Timeouts
  
−
* RC2
+
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.
−
* MD4
 
−
* MD5
 
−
* SHA1
 
  
−
==Poor Key Management==
+
==Insecure Token Creation==
  
 
The best algorithms don't matter if you mishandle your keys. Many make the mistake of using the correct encryption algorithm, but implementing their own protocol for employing it. Some examples of problems here include:
 
The best algorithms don't matter if you mishandle your keys. Many make the mistake of using the correct encryption algorithm, but implementing their own protocol for employing it. Some examples of problems here include:

Revision as of 09:18, 27 January 2014

Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts
Application Specific Exploitability
EASY		 Prevalence
COMMON		 Detectability
EASY		 Impact
SEVERE		 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


Improper Session Handling

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:

  1. Failure to Invalidate Sessions on the Backend
  2. Lack of Adequate Timeout Protection
  3. Failure to Properly Rotate Cookies
  4. Insecure Token Creation

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
  • Timeouts

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

The best algorithms don't matter if you mishandle your keys. Many make the mistake of using the correct encryption algorithm, but implementing their own protocol for employing it. Some examples of problems here include:

  • Including the keys in the same attacker-readable directory as the encrypted content
  • Making the keys otherwise available to the attacker
  • Failing to use built-in encryption functionality

References

References

Retrieved from "https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M9&oldid=166726"