Mobile Top 10 2014-M2 - Revision history

Abhinav at 06:14, 31 March 2016

2016-03-31T06:14:32Z

Barbarafox: Grammatical errors

2015-10-08T18:25:48Z

Grammatical errors

Ryan Dewhurst: Update "Google Androids Developer Security Topics 2" hyperlink

2015-04-23T10:56:51Z

Update "Google Androids Developer Security Topics 2" hyperlink

Stephencor at 06:59, 8 October 2014

2014-10-08T06:59:24Z

Jonathan Carter at 23:50, 9 April 2014

2014-04-09T23:50:07Z

Jason Haddix at 08:48, 27 January 2014

2014-01-27T08:48:17Z

Jason Haddix at 07:31, 27 January 2014

2014-01-27T07:31:06Z

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-27T04:57:44Z

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}}>Threats agents include lost/stolen phones and the possibility of in-the-wild exploit/malware gaining access to the device. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> A malicious agent hooks up an unprotected device to a computer with commonly available software. They are able to see all third party application directories that often contain stored personal information. </td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>M2, insecure data storage, occurs when development teams assume that users will not have access to the phones file system and store sensitive pieces of information in data-stores on the phone. Devices file systems are often easily accessible and you should expect a malicious user to be inspecting your data stores. Rooting or jailbreaking a device usually circumvents any encryption protections and in some cases, where data is not protected properly, all that is needed to view application data is to hook the phone up to a computer and use some specialized tools. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Insecure data storage can result in data loss, in the best case, for one user. In the worst case, for many users. Common valuable pieces of data seen stored include:
* Usernames
* Authentication tokens
* Passwords
* Cookies
* Location data
* UDID/EMEI, Device Name, Network Connection Name
* Personal Information: DoB, Address, Social, Credit Card Data
* Application Data:
** Stored application logs
** Debug information
** Cached application messages
** Transaction histories </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Insert text here </td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=1}}
It is important to threat model applications to see what data they handle, as well as know the API's that handle it and if they store sensitive information securely. Although annecdotal, places we most often see data being stored insecurely are:

* SQLite databases
* Log Files
* Plist Files
* XML Data Stores or Manifest Files
* Binary data stores
* Cookie stores
* SD Card
* Cloud synced
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=1}}
The cardinal rule of mobile apps is: don’t store data unless absolutely necessary. As a developer you have to assume that the data is forfeit as soon as it touches the phone. You also have to consider the implications of losing every single mobile users data to a silent jailbreak or root exploit. If the usability versus security tradeoff is too much for you, we recommend scrutinizing your platforms data security API’s and making sure you’re calling them appropriately. The lesson here is to know what data is being stored and protect it appropriately.

'''iOS Specific Best Practices:'''

''' '''

* Never store credentials on the phone file system. Force the user to authenticate using a standard web or API login scheme (over HTTPS) to the application upon each opening and ensure session timeouts are set at the bare minimum to meet the user experience requirements.
* Where storage or caching of information is necessary consider using a standard iOS encryption library such as CommonCrypto
* If the data is small, using the provided apple keychain API is recommended but, once a phone is jailbroken or exploited the keychain can be easily read. This is in addition to the threat of a bruteforce on the devices PIN, which as stated above is trivial in some cases.
* For databases consider using SQLcipher for Sqlite data encryption
* For items stored in the keychain leverage the most secure API designation, kSecAttrAccessibleWhenUnlocked (now the default in iOS 5) and for enterprise managed mobile devices ensure a strong PIN is forced, alphanumeric, larger than 4 characters.
* For larger or more general types of consumer-grade data, Apple’s File Protection mechanism can safely be used (see NSData Class Reference for protection options).
* Avoid using NSUserDefaults to store senstitve pieces of information as it stores data in plist files.
* Be aware that all data/entities using NSManagedObects will be stored in an unencrypted database file.

'''Android Specific Best Practices:'''

''' '''

* For local storage the enterprise android device administration API can be used to force encryption to local file-stores using “setStorageEncryption”
* For SD Card Storage some security can be achieved via the ‘javax.crypto’ library. You have a few options, but an easy one is simply to encrypt any plain text data with a master password and AES 128.
* Ensure any shared preferences properties are '''NOT''' MODE_WORLD_READABLE unless explicitly required for information sharing between apps.
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=1}}

'''A Visual Example:'''

Here we have iGoat, a purposefully vulnerable mobile app for security conscious folk to see these types of vulnerabilities first hand. In the exercise we enter our credentials, and log in to the fake bank app. We can then navigate to the file system and in our applications directory we can see a database called “credentials.sqlite”. Exploring this database reveals our username and credentials (Jason:pleasedontstoremebro!) being stored in plain text.

[[Image:Screen%20Shot%202012-12-19%20at%206.34.23%20AM.png]]
[[Image:Screen%20Shot%202012-12-19%20at%206.44.51%20AM.png]]
[[Image:Screen%20Shot%202012-12-19%20at%2010.11.15%20AM.png]]
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=1}}
* [https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet OWASP ][https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet IOS Developer Cheat Sheet]
* [http://source.android.com/tech/security/ Google Androids Developer Security Topics 1]
* [http://developer.android.com/guide/topics/security Google Androids Developer Security Topics 2]
* [https://developer.apple.com/library/mac/ Apple's Introduction to Secure Coding]
* [http://h30499.www3.hp.com/t5/Application-Security-Fortify-on/Exploring-The-OWASP-Mobile-Top-10-M1-Insecure-Data-Storage/ba-p/5904609 Fortify On Demand Blog - Exploring The OWASP Mobile Top 10: Insecure Data Storage]

@@ Line 8: / Line 8: @@
 {{Top_10_2010:SummaryTableHeaderEndTemplate}}
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threats agents include the following: an adversary that has attained a lost/stolen mobile device; malware or a other repackaged app acting on the adversary's behalf that executes on the mobile device.</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In the event that an adversary physically attains the mobile device, the adversaryhooks up the mobile device to a computer with freely available software. These tools allow the adversary to see all third party application directories that often contain stored personally identifiable information (PII) or other sensitive information assets. An adversary may construct malware or modify a legitimate app to steal such information assets.</td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In the event that an adversary physically attains the mobile device, the adversary hooks up the mobile device to a computer with freely available software. These tools allow the adversary to see all third party application directories that often contain stored personally identifiable information (PII) or other sensitive information assets. An adversary may construct malware or modify a legitimate app to steal such information assets.</td>
-      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Insecure data storage, vulnerabilities occurs when development teams assume that users or malware will not have access to a mobile device's filesystem and subsequent sensitive information in data-stores on the device.  Filesystems are easily accessible.  Organizations should expect a malicious user or malware to inspect sensitive data stores.
+      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Insecure data storage vulnerabilities occur when development teams assume that users or malware will not have access to a mobile device's filesystem and subsequent sensitive information in data-stores on the device.  Filesystems are easily accessible.  Organizations should expect a malicious user or malware to inspect sensitive data stores.
 Rooting or jailbreaking a mobile device circumvents any encryption protections.  When data is not protected properly, specialized tools are all that is needed to view application data.</td>

@@ Line 8: / Line 8: @@
 {{Top_10_2010:SummaryTableHeaderEndTemplate}}
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threats agents include the following: an adversary that has attained a lost/stolen mobile device; malware or a other repackaged app acting on the adversary's behalf that executes on the mobile device.</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In the event that an adversary physically attains the mobile device, the adversaryhooks up the mobile device to a computer with freely available software. These tools allow the adversary to see all third party application directories that often contain stored personally identifiable information (PII) or other sensitive information assets. An adversary may consruct malware or modify a legitimate app to steal such information assets.</td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In the event that an adversary physically attains the mobile device, the adversaryhooks up the mobile device to a computer with freely available software. These tools allow the adversary to see all third party application directories that often contain stored personally identifiable information (PII) or other sensitive information assets. An adversary may construct malware or modify a legitimate app to steal such information assets.</td>
       <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Insecure data storage, vulnerabilities occurs when development teams assume that users or malware will not have access to a mobile device's filesystem and subsequent sensitive information in data-stores on the device.  Filesystems are easily accessible.  Organizations should expect a malicious user or malware to inspect sensitive data stores.
@@ Line 48: / Line 48: @@
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=1}}
-The cardinal rule of mobile apps is to not store data unless absolutely necessary. As a developer you have to assume that the data is forfeited as soon as it touches the phone. You also have to consider the implications of losing mobile users' data to a silent jailbreak or root exploit. If the usability versus security tradeoff is too much for you, OWASP recommends scrutinizing your platforms data security APIs and making sure you’re calling them appropriately.  The lesson here is to know what data is being stored and protect it appropriately.
+The cardinal rule of mobile apps is to not store data unless absolutely necessary. As a developer you have to assume that the data is forfeited as soon as it touches the phone. You also have to consider the implications of losing mobile users' data to a silent jailbreak or root exploit. If the usability versus security trade-off is too much for you, OWASP recommends scrutinizing your platforms data security APIs and making sure you’re calling them appropriately.  The lesson here is to know what data is being stored and protect it appropriately.
@@ Line 58: / Line 58: @@
 * For items stored in the keychain leverage the most secure API designation, kSecAttrAccessibleWhenUnlocked (now the default in iOS 5) and for enterprise managed mobile devices ensure a strong PIN is forced, alphanumeric, larger than 4 characters.
 * For larger or more general types of consumer-grade data, Apple’s File Protection mechanism can safely be used (see NSData Class Reference for protection options).
-* Avoid using NSUserDefaults to store senstitve pieces of information as it stores data in plist files.
+* Avoid using NSUserDefaults to store sensitive pieces of information as it stores data in plist files.
 * Be aware that all data/entities using NSManagedObects will be stored in an unencrypted database file.
 * Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive information assets.

← Older revision		Revision as of 08:48, 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>Insecure Data Storage</center>\|\|year=2014}}		{{Top_10_2010:SubsectionColoredTemplate\|<center>Insecure Data Storage</center>\|\|year=2014}}
	{{Top_10_2010:SummaryTableHeaderBeginTemplate}}		{{Top_10_2010:SummaryTableHeaderBeginTemplate}}

← Older revision		Revision as of 07:31, 27 January 2014
Line 1:		Line 1:
		+	{{Top_10_2010:SubsectionColoredTemplate\|<center>Insecure Data Storage</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}}

@@ Line 21: / Line 21: @@
 * Personal Information: DoB, Address, Social, Credit Card Data
 * Application Data:
-** Stored application logs
+** Stored application logs e.g For an android Apps ADB logcat
 ** Debug information
 ** Cached application messages

@@ Line 84: / Line 84: @@
 * [https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet OWASP ][https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet IOS Developer Cheat Sheet]
 * [http://source.android.com/tech/security/ Google Androids Developer Security Topics 1]
-* [http://developer.android.com/guide/topics/security Google Androids Developer Security Topics 2]
+* [http://developer.android.com/training/articles/security-tips.html Google Androids Developer Security Topics 2]
 * [https://developer.apple.com/library/mac/ Apple's Introduction to Secure Coding]
 * [http://h30499.www3.hp.com/t5/Application-Security-Fortify-on/Exploring-The-OWASP-Mobile-Top-10-M1-Insecure-Data-Storage/ba-p/5904609 Fortify On Demand Blog - Exploring The OWASP Mobile Top 10:  Insecure Data Storage]

@@ Line 7: / Line 7: @@
 {{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
 {{Top_10_2010:SummaryTableHeaderEndTemplate}}
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threats agents include lost/stolen phones and the possibility of in-the-wild exploit/malware gaining access to the device. </td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threats agents include the following: an adversary that has attained a lost/stolen mobile device; malware or a other repackaged app acting on the adversary's behalf that executes on the mobile device.</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> A malicious agent hooks up an unprotected device to a computer with commonly available software. They are able to see all third party application directories that often contain stored personal information. </td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In the event that an adversary physically attains the mobile device, the adversaryhooks up the mobile device to a computer with freely available software. These tools allow the adversary to see all third party application directories that often contain stored personally identifiable information (PII) or other sensitive information assets. An adversary may consruct malware or modify a legitimate app to steal such information assets.</td>
-      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>M2, insecure data storage, occurs when development teams assume that users will not have access to the phones file system and store sensitive pieces of information in data-stores on the phone. Devices file systems are often easily accessible and you should expect a malicious user to be inspecting your data stores. Rooting or jailbreaking a device usually circumvents any encryption protections and in some cases, where data is not protected properly, all that is needed to view application data is to hook the phone up to a computer and use some specialized tools. </td>
+      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Insecure data storage, vulnerabilities occurs when development teams assume that users or malware will not have access to a mobile device's filesystem and subsequent sensitive information in data-stores on the device.  Filesystems are easily accessible.  Organizations should expect a malicious user or malware to inspect sensitive data stores.
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Insecure data storage can result in data loss, in the best case, for one user. In the worst case, for many users. Common valuable pieces of data seen stored include:
 * Usernames
@@ Line 22: / Line 24: @@
 ** Debug information
 ** Cached application messages
-** Transaction histories  </td>
+** Transaction histories</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Insert text here </td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Insecure data storage vulnerabilities typically lead to the following business risks for the organization that owns the risk app:
 {{Top_10_2010:SummaryTableEndTemplate}}
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=1}}
-It is important to threat model applications to see what data they handle, as well as know the API's that handle it and if they store sensitive information securely. Although annecdotal, places we most often see data being stored insecurely are:
+It is important to threat-model your mobile app to understand the information assets it processes and how the underlying APIs handle those assets.  These APIs should store sensitive information securely. Places OWASP most often sees data being stored insecurely include the following:
 * SQLite databases
@@ Line 37: / Line 44: @@
 * SD Card
 * Cloud synced
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=1}}
-The cardinal rule of mobile apps is: don’t store data unless absolutely necessary. As a developer you have to assume that the data is forfeit as soon as it touches the phone. You also have to consider the implications of losing every single mobile users data to a silent jailbreak or root exploit. If the usability versus security tradeoff is too much for you, we recommend scrutinizing your platforms data security API’s and making sure you’re calling them appropriately.  The lesson here is to know what data is being stored and protect it appropriately.
+The cardinal rule of mobile apps is to not store data unless absolutely necessary. As a developer you have to assume that the data is forfeited as soon as it touches the phone. You also have to consider the implications of losing mobile users' data to a silent jailbreak or root exploit. If the usability versus security tradeoff is too much for you, OWASP recommends scrutinizing your platforms data security APIs and making sure you’re calling them appropriately.  The lesson here is to know what data is being stored and protect it appropriately.
 '''iOS Specific Best Practices:'''
 * Never store credentials on the phone file system. Force the user to authenticate using a standard web or API login scheme (over HTTPS) to the application upon each opening and ensure session timeouts are set at the bare minimum to meet the user experience requirements.
-* Where storage or caching of information is necessary consider using a standard iOS encryption library such as CommonCrypto
+* Where storage or caching of information is necessary consider using a standard iOS encryption library such as CommonCrypto. However, for particularly sensitive apps, consider using whitebox cryptography solutions that avoid the leakage of binary signatures found within common encryption libraries.
 * If the data is small, using the provided apple keychain API is recommended but, once a phone is jailbroken or exploited the keychain can be easily read. This is in addition to the threat of a bruteforce on the devices PIN, which as stated above is trivial in some cases.
 * For databases consider using SQLcipher for Sqlite data encryption
@@ Line 52: / Line 60: @@
 * Avoid using NSUserDefaults to store senstitve pieces of information as it stores data in plist files.
 * Be aware that all data/entities using NSManagedObects will be stored in an unencrypted database file.
 '''Android Specific Best Practices:'''
 * For local storage the enterprise android device administration API can be used to force encryption to local file-stores using “setStorageEncryption”
 * For SD Card Storage some security can be achieved via the ‘javax.crypto’ library. You have a few options, but an easy one is simply to encrypt any plain text data with a master password and AES 128.
 * Ensure any shared preferences properties are '''NOT''' MODE_WORLD_READABLE unless explicitly required for information sharing between apps.
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=1}}
 '''A Visual Example:'''
-Here we have iGoat, a purposefully vulnerable mobile app for security conscious folk to see these types of vulnerabilities first hand. In the exercise we enter our credentials, and log in to the fake bank app. We can then navigate to the file system and in our applications directory we can see a database called “credentials.sqlite”. Exploring this database reveals our username and credentials (Jason:pleasedontstoremebro!) being stored in plain text.
+iGoat is a purposefully vulnerable mobile app for the security community to explore these types of vulnerabilities first hand. In the exercise below, we enter our credentials and log in to the fake bank app. Then, we navigate to the file system. Within the applications directory, we can see a database called “credentials.sqlite”. Exploring this database reveals that the application is storing our username and credentials (Jason:pleasedontstoremebro!) in plain text.
 [[Image:Screen%20Shot%202012-12-19%20at%206.34.23%20AM.png]]