Projects/OWASP Mobile Security Project -2015 Scratchpad - Revision history

Paco: Added M1, M2, M3, etc.

2016-03-18T17:26:27Z

Added M1, M2, M3, etc.

Paco: typo

2016-03-16T11:39:12Z

typo

Paco: Added hyperlinks

2016-03-16T11:38:22Z

Added hyperlinks

Paco: /* Extraneous Functionality */

2016-03-15T11:24:41Z

‎Extraneous Functionality

Paco: /* Prominent Characteristics */

2016-03-15T11:20:16Z

‎Prominent Characteristics

Paco at 11:18, 15 March 2016

2016-03-15T11:18:25Z

Paco: /* Insecure Communication (Owner: Andrew Blaich, Milan) */

2016-03-15T11:07:50Z

‎Insecure Communication (Owner: Andrew Blaich, Milan)

Paco: /* Prominent Characteristics */

2016-03-15T11:06:57Z

‎Prominent Characteristics

Paco: /* Insecure Authentication (Paco) */

2016-03-15T11:04:53Z

‎Insecure Authentication (Paco)

Paco: /* Prominent Characteristics */

2016-03-15T11:04:11Z

‎Prominent Characteristics

@@ Line 5: / Line 5: @@
 This is the draft of the 2016 reworking of the Mobile Top Ten.
-==Improper Platform Usage==
+==M1: Improper Platform Usage==
 ===Overview Text===
 This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system.
@@ Line 35: / Line 35: @@
 The iOS Keychain is a secure storage facility for both app and system data. On iOS, apps should use it to store any small data that has security significance (session keys, passwords, device enrolment data, etc.). A common mistake is to store such items in app local storage. Data stored in app local storage is available in unencrypted iTunes backups (e.g., on the user's computer). For some apps, that exposure is inappropriate.
-==Insecure Data==
+==M2: Insecure Data==
 Owner: Milan
 ===Overview Text===
@@ Line 87: / Line 87: @@
 ===Examples===
-==Insecure Communication==
+==M3: Insecure Communication==
 Owner: Andrew Blaich, Milan. Contributions by Paco
 ===Overview Text===
@@ Line 120: / Line 120: @@
 The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL. This jeopardizes the confidentiality of any privacy-related data between the mobile app and the endpoint.
-==Insecure Authentication==
+==M4: Insecure Authentication==
 Owner: Paco
 ===Overview Text===
@@ Line 164: / Line 164: @@
 Apps sometimes do not actually log out of the server side of the application. The app merely discards its copy of session identifiers and other login data. This weak form of logout can leave sessions open far longer than is intended. A session that is observed (e.g., via eavesdropping) could be cloned into another device or into a web browser and continued, even after the mobile app believes it has logged out.
-==Insufficient Cryptography==
+==M5: Insufficient Cryptography==
 Owner: Paco Hope
@@ Line 203: / Line 203: @@
 Imagine a mobile app that posts data to a central service (e.g., high scores for a game, user's geographic location, etc.). Imagine that the mobile app adds a hash of the user's data as a parameter in the request as an integrity check. This hash is trivial to duplicate, so an attacker attempting to forge a legitimate update can do so easily. The attacker simply needs to calculate the same hash over the fake data. Fixing this issue would involve making the signature unique and difficult to forge.
-==Insecure Authorization==
+==M6: Insecure Authorization==
 ===Overview Text===
@@ Line 224: / Line 224: @@
 The web app end points that service mobile apps might permit access to resources as long as any authentication has taken place. Imagine a REST-based microservice that provides the loyalty points balance for a given loyalty account number. If that service requires some kind of authentication, but does not validate the user's identity as being authorised to see that balance, then this a failure in authorization.
-==Client Code Quality Issues==
+==M7: Client Code Quality Issues==
 Owner: Milan
@@ Line 243: / Line 243: @@
 If an app had a format string vulnerability or similar, it could display sensitive information (e.g., an encryption key, session ID, or API key) in its user interface that was intended to only exist in RAM inside the app.
-==Code Tampering==
+==M8: Code Tampering==
 Owner: Jonathan Carter
 ===Generic Label===
@@ Line 268: / Line 268: @@
 The conditional jumps which detect whether an in-application purchase is successful canbe short-circuited to always allow the content, without charging the end user.
-==Reverse Engineering==
+==M9: Reverse Engineering==
 Owner: Jonathan Carter, Milan
@@ Line 294: / Line 294: @@
 Then using [https://github.com/pxb1988/dex2jar Dex to Jar] converter,  an attacker can easily convert it to jar file. In next step, Java Decompiler (like [http://jd.benow.ca/ JDgui]) will provide you the code.
-==Extraneous Functionality==
+==M10: Extraneous Functionality==
 Owner: Andrew Blaich, Milan

@@ Line 168: / Line 168: @@
 ===Overview Text===
-The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in [[#Insecure Communications]]. Also, if the app fails to use cryptography at all when it should, that probably belongs in [[#Insecure Data]]. This category is for issues where cryptography was attempted, but it wasn't done correctly.
+The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in [[#Insecure Communication]]. Also, if the app fails to use cryptography at all when it should, that probably belongs in [[#Insecure Data]]. This category is for issues where cryptography was attempted, but it wasn't done correctly.
 ===Prominent Characteristics===

@@ Line 168: / Line 168: @@
 ===Overview Text===
-The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in M3. Also, if the app fails to use cryptography at all when it should, that probably belongs in M2. This category is for issues where cryptography was attempted, but it wasn't done correctly.
+The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in [[#Insecure Communications]]. Also, if the app fails to use cryptography at all when it should, that probably belongs in [[#Insecure Data]]. This category is for issues where cryptography was attempted, but it wasn't done correctly.
 ===Prominent Characteristics===

@@ Line 301: / Line 301: @@
 ===Prominent Characteristics===
 ===Risk===
-There is high risk of stealing your personal information, payment transactions and all other activities that you do on your mobile device.
+There is high risk of stealing sensitive data or accessing unauthorized functions via these extra capabilities. If a banking application has malicious code implanted in it, it will not only steal customer information and funds but also damage the bank's reputation. This malicious code will initiate an outgoing connection, which will be treated as genuine connection and not malicious. Despite of all security controls, it will be very difficult for bank to detect malicious activity by the application on mobile devices.
-Another example is Insurance Application. If a developer injects malicious code snippet in any insurance application and the application code has not undergone Secure Code, then there is high probability of Stealing Customer data which includes all personal details. Imagine if this malicious snippet is monitoring your Payment Transactions, you know what will happen next.
+Another example is insurance application. If a developer injects malicious code snippet in any insurance application, then there is high probability of stealing customer data which includes all personal details. Imagine if this malicious snippet is monitoring your payment transactions.
 ===Examples===
 <hr/>

@@ Line 234: / Line 234: @@
 ===Prominent Characteristics===
-The key characteristic of this risk is that it's code executing on the mobile device and the code needs to be changed in a fairly localised way. Fixing most risks requires code changes, but in the code quality case the risk comes from using the wrong API, using an API insecurely, using insecure language constructs, or some other code-level issue.
+The key characteristic of this risk is that it's code executing on the mobile device and the code needs to be changed in a fairly localised way. Fixing most risks requires code changes, but in the code quality case the risk comes from using the wrong API, using an API insecurely, using insecure language constructs, or some other code-level issue. Importantly: this is '''not''' code running on the server. This is a risk that captures bad code that executes on the mobile device itself.
 ===Risk===

@@ Line 142: / Line 142: @@
 ===Prominent Characteristics===
-The key characteristic that authentication issues have is that the tokens which represent the user can be compromised in some way.
+The key characteristic that authentication issues have is that the tokens which represent the user can be compromised in some way. Alternatively, the app might have mechanism at all for authenticating something that needs to be authenticated. E.g., no mechanism to identify users, no means of identifying/enrolling devices, no means of authenticating genuine microservices, etc.
 ===Risk===

@@ Line 97: / Line 97: @@
 The prominent characteristics include packaging up some kind of sensitive data and transmitting it into or out of the device. Some examples of sensitive data include encryption keys, passwords, private user information, account details, session tokens, documents, metadata, and binaries. The sensitive data can be coming to the device from a server, it can be coming from an app out to a server, or it might be going between the device and something else local (e.g., an NFC terminal or NFC card). The defining characteristic of this risk is the existence of two devices and some data passing between them.
-If the data is being stored locally in the device itself, that's [[#Insecure Data]]. If the session details are communicated securely (e.g., via a strong TLS connection) but the session identifer itself is bad (perhaps it is predictable, low entropy, etc.), then that's an [[#Authentication]] problem, not a communication problem.
+If the data is being stored locally in the device itself, that's [[#Insecure Data]]. If the session details are communicated securely (e.g., via a strong TLS connection) but the session identifer itself is bad (perhaps it is predictable, low entropy, etc.), then that's an [[#Insecure Authentication]] problem, not a communication problem.
 ===Risk===