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
 
(One intermediate revision by one other user not shown)
Line 7: Line 7:
 
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
 
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Anyone with access to HTTP/S traffic, cookie data, etc.</td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Anyone or any mobile app with access to HTTP/S traffic, cookie data, etc.</td>
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attack vectors include physical access to the device and network traffic capture</td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Attack vectors include physical access to the device, and network traffic capture, or malware on the mobile device.</td>
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Malicious or accidental session hijacking</td>
+
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In order to facilitate a stateful transaction between a user and a mobile app's backend servers, mobile apps use session tokens to maintain state over stateless protocols like HTTP or SOAP. To maintain state, the mobile app must first authenticate the user through the backend. In response to successful authentication, the server issues a session cookie to the mobile app. The mobile app adds this cookie to all future service transactions between the mobile app and the server. This allows the server to conveniently enforce authentication and authorization for any service requests issued by the mobile app.
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Unauthorized users gaining access to other users' accounts</td>
+
 
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Customers losing control of their accounts and/or data</td>
+
Improper session handling occurs when the session token is unintentionally shared with the adversary during a subsequent transaction between the mobile app and the backend servers.</td>
 +
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>An adversary that has access to the session tokens is able to impersonate the user by submitting the token to the backend server for any sensitive transactions. Hence, the technical impact is dependent upon who is being impersonated and what service is being requested.
 +
 
 +
In the worst-case scenario,the adversary is impersonating an administrative user and issuing a request for administrative functionality that is dangerous in nature.
 +
 
 +
In the average-case scenario, users lose control of their accounts and who is performing authorized functionality on their behalf.</td>
 +
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Improper session handling results in an adversary that can impersonate another user and perform business functionality on their behalf. This may result in:
 +
 
 +
* Fraud;
 +
* Information Theft; or
 +
* Business Interruption.
 +
</td>
 
{{Top_10_2010:SummaryTableEndTemplate}}
 
{{Top_10_2010:SummaryTableEndTemplate}}
  
  
 
{{Top_10_2010:SubsectionColoredTemplate|Am I Vulnerable To Improper Session Handling?||year=2014}}
 
{{Top_10_2010:SubsectionColoredTemplate|Am I Vulnerable To Improper Session Handling?||year=2014}}
The M9 category deals with session handling and the various ways it can be done insecurely.
+
This 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.
+
Improper Session Handling typically results in the same outcomes as poor authentication. Once you are authenticated and given a session, that session allows one access to the mobile application. Mobile app code must protect user sessions just as carefully as its authentication mechanism.
  
 
Here are some examples of how it is often done improperly:
 
Here are some examples of how it is often done improperly:
Line 24: Line 35:
 
==Failure to Invalidate Sessions on the Backend==
 
==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.
+
Many developers invalidate sessions on the mobile app 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 mobile app.
  
 
==Lack of Adequate Timeout Protection==
 
==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.
+
Any mobile app you create must have adequate timeout protection on the backend components. This helps prevent malicious potential for an unauthorized user to gain access to an existing session and assume the role of that user.
  
 
Good timeout periods vary widely according to the sensitivity of the app, one's own risk profile, etc., but some good guidelines are:
 
Good timeout periods vary widely according to the sensitivity of the app, one's own risk profile, etc., but some good guidelines are:
Line 35: Line 46:
 
* 30 minutes for medium security applications
 
* 30 minutes for medium security applications
 
* 1 hour for low security applications
 
* 1 hour for low security applications
 +
 +
There is an increasing trend towards allowing long timeout values on mobile app sessions due to the nature of user interaction with mobile apps. Often, users are doing many things at once when using their mobile apps. Interactions tend to be sporatic, unpredictable, and drawn out over a longer timeframe than with traditional web apps. In some ways, it makes sense that longer timeout sessions are required because the interval between interactions might be longer. However, this increased session timeout window will increase the risk of session stealing if session handling is not done properly. It is important to raise this risk with the powers-that-be to ensure that session handling is handled properly.
  
 
==Failure to Properly Rotate Cookies==
 
==Failure to Properly Rotate Cookies==
Line 52: Line 65:
  
 
{{Top_10_2010:SubsectionColoredTemplate|How Do I Prevent Improper Session Handling?||year=2014}}
 
{{Top_10_2010:SubsectionColoredTemplate|How Do I Prevent Improper Session Handling?||year=2014}}
 
+
To handle sessions properly, ensure that mobile app code creates, maintains, and destroys session tokens properly over the life-cycle of a user's mobile app session. Follow the advice above.
 
 
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}
References
 

Latest revision as of 07:07, 8 October 2014

Back To The Mobile Top Ten Main Page
Improper Session Handling
Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts
Application Specific Exploitability
EASY
Prevalence
COMMON
Detectability
EASY
Impact
SEVERE
Application / Business Specific
Anyone or any mobile app with access to HTTP/S traffic, cookie data, etc. Attack vectors include physical access to the device, and network traffic capture, or malware on the mobile device. In order to facilitate a stateful transaction between a user and a mobile app's backend servers, mobile apps use session tokens to maintain state over stateless protocols like HTTP or SOAP. To maintain state, the mobile app must first authenticate the user through the backend. In response to successful authentication, the server issues a session cookie to the mobile app. The mobile app adds this cookie to all future service transactions between the mobile app and the server. This allows the server to conveniently enforce authentication and authorization for any service requests issued by the mobile app. Improper session handling occurs when the session token is unintentionally shared with the adversary during a subsequent transaction between the mobile app and the backend servers. An adversary that has access to the session tokens is able to impersonate the user by submitting the token to the backend server for any sensitive transactions. Hence, the technical impact is dependent upon who is being impersonated and what service is being requested.

In the worst-case scenario,the adversary is impersonating an administrative user and issuing a request for administrative functionality that is dangerous in nature.

In the average-case scenario, users lose control of their accounts and who is performing authorized functionality on their behalf.
Improper session handling results in an adversary that can impersonate another user and perform business functionality on their behalf. This may result in:
  • Fraud;
  • Information Theft; or
  • Business Interruption.


Am I Vulnerable To Improper Session Handling?

This category deals with session handling and the various ways it can be done insecurely.

Improper Session Handling typically results in the same outcomes as poor authentication. Once you are authenticated and given a session, that session allows one access to the mobile application. Mobile app code must protect user sessions just as carefully as its 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 mobile app 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 mobile app.

Lack of Adequate Timeout Protection

Any mobile app you create must have adequate timeout protection on the backend components. This helps prevent malicious potential for an unauthorized user to gain access to an existing session and assume the role of that 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

There is an increasing trend towards allowing long timeout values on mobile app sessions due to the nature of user interaction with mobile apps. Often, users are doing many things at once when using their mobile apps. Interactions tend to be sporatic, unpredictable, and drawn out over a longer timeframe than with traditional web apps. In some ways, it makes sense that longer timeout sessions are required because the interval between interactions might be longer. However, this increased session timeout window will increase the risk of session stealing if session handling is not done properly. It is important to raise this risk with the powers-that-be to ensure that session handling is handled properly.

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

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.

How Do I Prevent Improper Session Handling?

To handle sessions properly, ensure that mobile app code creates, maintains, and destroys session tokens properly over the life-cycle of a user's mobile app session. Follow the advice above.


References