Mobile Top 10 2014-M9 - Revision history

Stephencor at 07:07, 8 October 2014

2014-10-08T07:07:32Z

Jonathan Carter at 01:00, 10 April 2014

2014-04-10T01:00:29Z

Jason Haddix at 09:57, 27 January 2014

2014-01-27T09:57:33Z

Jason Haddix at 09:55, 27 January 2014

2014-01-27T09:55:48Z

Daniel Miessler at 09:22, 27 January 2014

2014-01-27T09:22:41Z

Daniel Miessler at 09:21, 27 January 2014

2014-01-27T09:21:37Z

Daniel Miessler at 09:18, 27 January 2014

2014-01-27T09:18:37Z

Daniel Miessler at 07:34, 27 January 2014

2014-01-27T07:34:29Z

Daniel Miessler: Created page with "{{Top_10_2010:SummaryTableHeaderBeginTemplate}} {{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}} {{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}..."

2014-01-27T07:29:36Z

Created page with "{{Top_10_2010:SummaryTableHeaderBeginTemplate}} {{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}} {{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}..."

New page

{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Anyone with access to data that has been encrypted improperly</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attack vectors include physical access to the device and network traffic capture</td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Encryption of mobile application data that can be successfully returned to plaintext by an unauthorized party</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Return of sensitive data to plaintext</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Loss of customer data, sensitive IP, or other critical information</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10_2010:SubsectionColoredTemplate|Am I Vulnerable to Weak Cryptography?||year=2014}}
The M6 category covers the various ways that insecure cryptography is used within mobile applications.

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:

<ol>
<li>The Creation and Use of Custom Encryption Algorithms</li>
<li>Use of Insecure and/or Deprecated Algorithms</li>
<li>Poor Key Management</li>
</ol>

==Creation and Use of Custom Encryption Protocols==

There is no easier way to mishandle encryption--mobile or otherwise--than to try to create and use your own encryption algorithms or protocols.

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.

==Use of Insecure and/or Deprecated Algorithms==

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:

* RC2
* MD4
* MD5
* SHA1

==Poor Key Management==

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

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}
References

@@ Line 9: / Line 9: @@
       <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, or malware on the mobile device.</td>
-      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In order to faciliate 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 mobie app.
+      <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.
 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>
@@ Line 65: / Line 65: @@
 {{Top_10_2010:SubsectionColoredTemplate|How Do I Prevent Improper Session Handling?||year=2014}}
-To handle sessions properly, ensure that moble app code creates, maintains, and destroys session tokens properly over the lifecycle of a user's mobile app session. Follow the advice above.
+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}}

@@ Line 7: / Line 7: @@
 {{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
 {{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 faciliate 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 mobie 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>
 {{Top_10_2010:SummaryTableEndTemplate}}
 {{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:
@@ Line 24: / Line 35: @@
 ==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==
-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:
@@ Line 35: / Line 46: @@
 * 30 minutes for medium security applications
 * 1 hour for low security applications
 ==Failure to Properly Rotate Cookies==
@@ Line 52: / Line 65: @@
 {{Top_10_2010:SubsectionColoredTemplate|How Do I Prevent Improper Session Handling?||year=2014}}
+To handle sessions properly, ensure that moble app code creates, maintains, and destroys session tokens properly over the lifecycle 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}}

← Older revision		Revision as of 09:57, 27 January 2014
Line 21:		Line 21:

	Here are some examples of how it is often done improperly:		Here are some examples of how it is often done improperly:
−
−	~~<ol>~~
−	~~<li>Failure to Invalidate Sessions on the Backend</li>~~
−	~~<li>Lack of Adequate Timeout Protection</li>~~
−	~~<li>Failure to Properly Rotate Cookies</li>~~
−	~~<li>Insecure Token Creation</li>~~
−	~~</ol>~~

	==Failure to Invalidate Sessions on the Backend==		==Failure to Invalidate Sessions on the Backend==

@@ Line 1: / Line 1: @@
 {{Top_10_2010:SummaryTableHeaderBeginTemplate}}
 {{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
@@ Line 13: / Line 15: @@
-{{Top_10_2010:SubsectionColoredTemplate|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.
@@ Line 55: / Line 57: @@
 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.
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}
 References

@@ Line 33: / Line 33: @@
 ==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
+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:

@@ Line 14: / Line 14: @@
 {{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.
 <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>
 </ol>
-==Creation and Use of Custom Encryption Protocols==
+==Failure to Invalidate Sessions on the Backend==
-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
-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
-* 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.
-==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: