Mobile Top 10 2014-M5 - Revision history

Barbarafox: Duplicated sentence

2015-10-08T18:29:59Z

Duplicated sentence

Barbarafox: spelling and grammar

2015-10-08T18:29:21Z

spelling and grammar

Marco Lancini: Removed duplicated paragraph

2015-01-08T17:43:12Z

Removed duplicated paragraph

Stephencor at 07:05, 8 October 2014

2014-10-08T07:05:30Z

Jonathan Carter at 00:39, 10 April 2014

2014-04-10T00:39:09Z

Jason Haddix at 08:49, 27 January 2014

2014-01-27T08:49:01Z

Jason Haddix at 07:34, 27 January 2014

2014-01-27T07:34:37Z

Jason Haddix: 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-27T06:51:37Z

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}}>Threat Description </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attack Vector Description </td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Security Weakness Description </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Technical Impacts</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Business Impacts </td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=5}}
Avoid the following Insecure Mobile Application Authentication Design Patterns:

* Authentication requires that mobile applications should match the security protections that of the web application component. Therefore, it should not be possible to authenticate through with less authentication factors then it would be possible through the web browser.
* Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through runtime manipulation or modification of the binary.
* Ensure all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication.
* If client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials. This will ensure that the stored application data will only accessible upon successfully entering the correct credentials.
* Persistent authentication (Remember Me) functionality implemented within mobile applications should never be implemented by storing a user’s password on the device.
* Ideally, mobile applications should utilize a device-specific authentication token, which can be revoked within the web application by the user. This will ensure that unauthorized access can be mitigated in the event of a stolen/lost device.
* Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-location.
* Persistent authentication within mobile applications should be implemented as opt-in and not enabled by default
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=5}}
Developers should assume all client-side authorization controls can be bypassed by malicious users. Authorization controls should be re-enforced server-side whenever possible.

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=5}}
Example Scenarios
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=5}}
References

@@ Line 8: / Line 8: @@
 {{Top_10_2010:SummaryTableHeaderEndTemplate}}
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat agents that exploit authentication vulnerabilities typically do so through automated attacks that use available or custom-built tools.
 </td>
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Once the adversary understands how the authentication scheme is vulnerable, they fake or bypass authentication by submitting service requests to the mobile app's backend server and bypass any direct interaction with the mobile app. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.</td>
       <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Poor or missing authentication schemes allow an adversary to anonymously execute functionality within the mobile app or backend server used by the mobile app. Weaker authentication for mobile apps is fairly prevalent due to a mobile device's input form factor. The form factor highly encourages short passwords that are often purely based on 4-digit PINs.

@@ Line 10: / Line 10: @@
 Threat agents that exploit authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools.</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Once the adversary understands how the authentication scheme is vulnerable, they fake or bypass authentication by submitting service requests to the mobile app's backend server and bypass any direct interaction with the moblie app. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.</td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Once the adversary understands how the authentication scheme is vulnerable, they fake or bypass authentication by submitting service requests to the mobile app's backend server and bypass any direct interaction with the mobile app. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.</td>
       <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Poor or missing authentication schemes allow an adversary to anonymously execute functionality within the mobile app or backend server used by the mobile app. Weaker authentication for mobile apps is fairly prevalent due to a mobile device's input form factor. The form factor highly encourages short passwords that are often purely based on 4-digit PINs.
-Authentication requirements for mobile apps can be quite different to traditional web authentication schemes due to availability requirements.
+Authentication requirements for mobile apps can be quite different from traditional web authentication schemes due to availability requirements.
 In traditional web apps, users are expected to be online and authenticate in real-time with a backend server. Throughout their session, there is a reasonable expectation that they will have continuous access to the Internet.

@@ Line 10: / Line 10: @@
 Threat agents that exploit authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools.</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Once the adversary understands how the authentication scheme is vulnerable, they fake or bypass authentication by submitting service requests to the mobile app's backend server and bypass any direct interaction with the moblie app. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Once the adversary understands how the authentication scheme is vulnerable, they fake or bypass authentication by submitting service requests to the mobile app's backend server and bypass any direct interaction with the moblie app. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.</td>
       <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Poor or missing authentication schemes allow an adversary to anonymously execute functionality within the mobile app or backend server used by the mobile app. Weaker authentication for mobile apps is fairly prevalent due to a mobile device's input form factor. The form factor highly encourages short passwords that are often purely based on 4-digit PINs.

@@ Line 7: / Line 7: @@
 {{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
 {{Top_10_2010:SummaryTableHeaderEndTemplate}}
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat agents that expolit authentication vulnerabilities typically do so through automated attacks that use available or custom-built tools.
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat agents that exploit authentication vulnerabilities typically do so through automated attacks that use available or custom-built tools.
 Threat agents that exploit authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools.</td>
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Once the adversary understands how the authentication scheme is vulnerable, they fake or bypass authentication by submitting service requests to the mobile app's backend server and bypass any direct interaction with the moblie app. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.
-Once the adversary understands how the authorization scheme is vulnerable, they fake or bypass authorization by submitting service requests to the mobile app's backend server using a session that belongs to a user with less perission than they should have to conduct the operation. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.</td>
+Once the adversary understands how the authorization scheme is vulnerable, they fake or bypass authorization by submitting service requests to the mobile app's backend server using a session that belongs to a user with less permission than they should have to conduct the operation. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.</td>
       <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Poor or missing authentication schemes allow an adversary to anonymously execute functionality within the mobile app or backend server used by the mobile app. Weaker authentication for mobile apps is fairly prevalent due to a mobile device's input form factor. The form factor highly encourages short passwords that are often purely based on 4-digit PINs.
-Authentication requirements for mobile apps can be quite different to traiditonal web authentication schemes due to availability requirements.
+Authentication requirements for mobile apps can be quite different to traditional web authentication schemes due to availability requirements.
-In traditional web apps, users are exepcted to be online and authenticate in realtime with a backend server. Throughout their session, there is a reasonable expectation that they will have continuous access to the Internet.
+In traditional web apps, users are expected to be online and authenticate in real-time with a backend server. Throughout their session, there is a reasonable expectation that they will have continuous access to the Internet.
-In mobile apps, users are not exepcted to be online at all times during their session. Mobile internet connections are much less reliable or predictable than traiditonal web connections. Hence, mobile apps may have uptime requirements that require offline authenitcation. This offline requirement can have profound ramifications on things that developers must consider when implementing mobile authentication.
+In mobile apps, users are not expected to be online at all times during their session. Mobile internet connections are much less reliable or predictable than traditional web connections. Hence, mobile apps may have uptime requirements that require offline authentication. This offline requirement can have profound ramifications on things that developers must consider when implementing mobile authentication.
-To detect poor authentication schemes, testers can perform binary attacks against the mobile app whilt it is in 'offline' mode. Through the attack, the tester will force the app to bypass offline authentication and then execute functionality that should require offline authentication (for more information on binary attacks, see M10). As well, testers should try to execute any backend server functionality anonymously by removing any session tokens from any POST/GET reqeusts for the mobile app functionality.
+To detect poor authentication schemes, testers can perform binary attacks against the mobile app while it is in 'offline' mode. Through the attack, the tester will force the app to bypass offline authentication and then execute functionality that should require offline authentication (for more information on binary attacks, see M10). As well, testers should try to execute any backend server functionality anonymously by removing any session tokens from any POST/GET requests for the mobile app functionality.
-To test for poor authorization schemes, testers can perform binary attacks against the mobile app and try to execute privileged functionality that should only be executable with a user of higher privilege while the mobile app is in 'offline' mode (for more information on binary attacks, see M10). As well, testers should try to execute any privileged functionality using a low-privilege session token within the corresponding POST/GET reqeusts for the sensitive functionality to the backend server.Poor or missing authorization schemes allow an adversary to execute functionality they should not be entitled to using an authenticated but lower- privilege user of the mobile app. Authorization requirements are more vulnerable when making authorization decisions within the mobile device instead of through a remote server. This may be a requirement due to mobile requirements of offline usability.</td>
+To test for poor authorization schemes, testers can perform binary attacks against the mobile app and try to execute privileged functionality that should only be executable with a user of higher privilege while the mobile app is in 'offline' mode (for more information on binary attacks, see M10). As well, testers should try to execute any privileged functionality using a low-privilege session token within the corresponding POST/GET requests for the sensitive functionality to the backend server.Poor or missing authorization schemes allow an adversary to execute functionality they should not be entitled to using an authenticated but lower- privilege user of the mobile app. Authorization requirements are more vulnerable when making authorization decisions within the mobile device instead of through a remote server. This may be a requirement due to mobile requirements of offline usability.</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The technical impact of poor authentication is that the solution is unable to identify the user performing an action requrest. Immediately, the solution will be unable to log or audit user activity because the identity of the user cannot be established. This will contribute to an inability to detect the source of an attack, the nature of any underlying exploits, or how to prevent future attacks.
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The technical impact of poor authentication is that the solution is unable to identify the user performing an action request. Immediately, the solution will be unable to log or audit user activity because the identity of the user cannot be established. This will contribute to an inability to detect the source of an attack, the nature of any underlying exploits, or how to prevent future attacks.
-Authentication failures may expose underlying authorization failures as well. When authentication controls fail, the solution is unable to verify the user's identity. This identity is linked to a user's role and associated permissions. If an attacker is able to anonymously execute sensitive functionality, it highights that the underlying code is not verifying the permissions of the user issuing the request for the action. Hence, anonymous execution of code highlights failures in both authentication and authorization controls.
+Authentication failures may expose underlying authorization failures as well. When authentication controls fail, the solution is unable to verify the user's identity. This identity is linked to a user's role and associated permissions. If an attacker is able to anonymously execute sensitive functionality, it highlights that the underlying code is not verifying the permissions of the user issuing the request for the action. Hence, anonymous execution of code highlights failures in both authentication and authorization controls.
 The technical impact of poor authorization is similar in nature to the technical impact of poor authentication. The technical impact can be wide ranging in nature and dependent upon the nature of the over-privileged functionality that is executed. For example, over-privileged execution of remote or local administration functionality may result in destruction of systems or access to sensitive information.</td>
@@ Line 45: / Line 45: @@
 * If you are porting a web application to its mobile equivalent, authentication requirements of mobile applications should match that of the web application component. Therefore, it should not be possible to authenticate with less authentication factors than the web browser.
-* Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through runtime manipulation or modification of the binary.  If there is a compelling business requirement for offline authentication, see M10 for additional guidance on preventing binary attacks against the mobile app.
+* Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through run-time manipulation or modification of the binary.  If there is a compelling business requirement for offline authentication, see M10 for additional guidance on preventing binary attacks against the mobile app.
 * Where possible, ensure that all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication.
 * If client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials. This will ensure that the stored application data will only be accessible upon successfully entering the correct credentials.  There are additional risks that the data will be decrypted via binary attacks. See M10 for additional guidance on preventing binary attacks that lead to local data theft.
@@ Line 62: / Line 62: @@
 # Developers assume that only authenticated users will be able to generate a service request that the mobile app submits to its backend for processing. During the processing of the request, the server code does not verify that the incoming request is associated with a known user. Hence, adversaries submit service requests to the back-end service and anonymously execute functionality that affects legitimate users of the solution.
 # Developers assume that only authorized users will be able to see the existance of a particular function on their mobile app. Hence, they expect that only legitimately authorized users will be able to issue the request for the service from their mobile device. Backend code that processes the request does not bother to verify that the identity associated with the request is entitled to execute the service. Hence, adversaries are able to perform remote administrative functionality using fairly low-privilege user accounts.
-# Due to usabiltiy requirements, mobile apps allow for passwords that are 4 digits long. Server code correctly stores a hashed version of the password. However, due to the severely short length of the password, an adversary will be able to quickly deduce the original passwords using rainbow hash tables. If the password file (or data store) on the server is compromised, an adversary wil be able to quickly deduce users' passwords.
+# Due to usability requirements, mobile apps allow for passwords that are 4 digits long. Server code correctly stores a hashed version of the password. However, due to the severely short length of the password, an adversary will be able to quickly deduce the original passwords using rainbow hash tables. If the password file (or data store) on the server is compromised, an adversary will be able to quickly deduce users' passwords.
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=5}}

← Older revision		Revision as of 08:49, 27 January 2014
Line 1:		Line 1:
		+	<center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center>
	{{Top_10_2010:SubsectionColoredTemplate\|<center>Poor Authorization and Authentication</center>\|\|year=2014}}		{{Top_10_2010:SubsectionColoredTemplate\|<center>Poor Authorization and Authentication</center>\|\|year=2014}}
	{{Top_10_2010:SummaryTableHeaderBeginTemplate}}		{{Top_10_2010:SummaryTableHeaderBeginTemplate}}

@@ Line 7: / Line 7: @@
 {{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
 {{Top_10_2010:SummaryTableHeaderEndTemplate}}
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat Description </td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat agents that expolit authentication vulnerabilities typically do so through automated attacks that use available or custom-built tools.
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attack Vector Description </td>
-      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Security Weakness Description </td>
+Threat agents that exploit authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools.</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Technical Impacts</td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Once the adversary understands how the authentication scheme is vulnerable, they fake or bypass authentication by submitting service requests to the mobile app's backend server and bypass any direct interaction with the moblie app. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Business Impacts </td>
 {{Top_10_2010:SummaryTableEndTemplate}}
@@ Line 17: / Line 44: @@
 Avoid the following Insecure Mobile Application Authentication Design Patterns:
-* Authentication requires that mobile applications should match the security protections that of the web application component. Therefore, it should not be possible to authenticate through with less authentication factors then it would be possible through the web browser.
+* If you are porting a web application to its mobile equivalent, authentication requirements of mobile applications should match that of the web application component. Therefore, it should not be possible to authenticate with less authentication factors than the web browser.
-* Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through runtime manipulation or modification of the binary.
+* Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through runtime manipulation or modification of the binary.  If there is a compelling business requirement for offline authentication, see M10 for additional guidance on preventing binary attacks against the mobile app.
-* Ensure all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication.
+* Where possible, ensure that all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication.
-* If client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials. This will ensure that the stored application data will only accessible upon successfully entering the correct credentials.
+* If client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials. This will ensure that the stored application data will only be accessible upon successfully entering the correct credentials.  There are additional risks that the data will be decrypted via binary attacks. See M10 for additional guidance on preventing binary attacks that lead to local data theft.
-* Persistent authentication (Remember Me) functionality implemented within mobile applications should never be implemented by storing a user’s password on the device.
+* Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device.
-* Ideally, mobile applications should utilize a device-specific authentication token, which can be revoked within the web application by the user. This will ensure that unauthorized access can be mitigated in the event of a stolen/lost device.
+* Ideally, mobile applications should utilize a device-specific authentication token that can be revoked within the mobile application by the user. This will ensure that the app can mitigate unauthorized access from a stolen/lost device.
 * Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-location.
-* Persistent authentication within mobile applications should be implemented as opt-in and not enabled by default
+* Persistent authentication within mobile applications should be implemented as opt-in and not be enabled by default.
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=5}}
-Developers should assume all client-side authorization controls can be bypassed by malicious users. Authorization controls should be re-enforced server-side whenever possible.
+Developers should assume all client-side authorization and authentication controls can be bypassed by malicious users. Authorization and authentication controls must be re-enforced on the server-side whenever possible.
-−
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=5}}
-Example Scenarios
+The following scenarios showcase weak authentication or authorization controls in mobile apps:
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=5}}

← Older revision		Revision as of 07:34, 27 January 2014
Line 1:		Line 1:
		+	{{Top_10_2010:SubsectionColoredTemplate\|<center>Poor Authorization and Authentication</center>\|\|year=2014}}
	{{Top_10_2010:SummaryTableHeaderBeginTemplate}}		{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
	{{Top_10_2010:SummaryTableValue-1-Template\|Exploitability\|EASY}}		{{Top_10_2010:SummaryTableValue-1-Template\|Exploitability\|EASY}}