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-M5"
From OWASP
Jason Haddix (talk | contribs) |
m |
||
| 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}}>Threat | + | <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}}> | + | |
| − | <td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> | + | 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}}> | + | <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 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> | ||
| + | <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. | ||
| + | |||
| + | 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 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. | ||
| + | |||
| + | 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 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> | ||
| + | <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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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> | ||
| + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The business impact of poor authentication will typically result in the following at a minimum: | ||
| + | |||
| + | * Reputational Damage | ||
| + | |||
| + | In the event that a user (anonymous or verified) is able to execute over-privileged functionality, the business may experience the following impacts: | ||
| + | |||
| + | * Reputational Damage; | ||
| + | * Fraud; or | ||
| + | * Information Theft. | ||
| + | </td> | ||
{{Top_10_2010:SummaryTableEndTemplate}} | {{Top_10_2010:SummaryTableEndTemplate}} | ||
| Line 17: | Line 44: | ||
Avoid the following Insecure Mobile Application Authentication Design Patterns: | Avoid the following Insecure Mobile Application Authentication Design Patterns: | ||
| − | * | + | * 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. |
| − | * | + | * 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 | + | * 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 | + | * 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. | * 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. |
| + | * If possible, do not allow users to provide 4-digit PIN numbers for authentication passwords. | ||
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=5}} | {{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 | + | 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. |
| − | + | ||
| + | Due to offline usage requirements, mobile apps may be required to perform local authentication or authorization checks within the mobile app's code. If this is the case, developers should instrument local integrity checks within their code to detect any unauthorized code changes. See M10 for more information about detecting and reacting to binary attacks. | ||
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=5}} | {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=5}} | ||
| − | + | The following scenarios showcase weak authentication or authorization controls in mobile apps: | |
| + | |||
| + | # 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. | ||
| + | |||
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=5}} | {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=5}} | ||
| − | |||
Revision as of 00:39, 10 April 2014
| Threat Agents | Attack Vectors | Security Weakness | Technical Impacts | Business Impacts | |
|---|---|---|---|---|---|
| Application Specific | Exploitability EASY |
Prevalence COMMON |
Detectability EASY |
Impact SEVERE |
Application / Business Specific |
| Threat agents that expolit 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. | 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. | 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. 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 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. 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 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. |
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.
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. 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. |
The business impact of poor authentication will typically result in the following at a minimum:
In the event that a user (anonymous or verified) is able to execute over-privileged functionality, the business may experience the following impacts:
|
|
Am I Vulnerable To Poor Authorization and Authentication?
Avoid the following Insecure Mobile Application Authentication Design Patterns:
- 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.
- 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.
- 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 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 be enabled by default.
- If possible, do not allow users to provide 4-digit PIN numbers for authentication passwords.
How Do I Prevent Poor Authorization and Authentication?
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.
Due to offline usage requirements, mobile apps may be required to perform local authentication or authorization checks within the mobile app's code. If this is the case, developers should instrument local integrity checks within their code to detect any unauthorized code changes. See M10 for more information about detecting and reacting to binary attacks.
Example Scenarios
The following scenarios showcase weak authentication or authorization controls in mobile apps:
- 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.
References
