<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>https://wiki.owasp.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Barbarafox</id>
		<title>OWASP - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="https://wiki.owasp.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Barbarafox"/>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php/Special:Contributions/Barbarafox"/>
		<updated>2026-05-27T10:02:56Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.27.2</generator>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M10&amp;diff=201887</id>
		<title>Mobile Top 10 2014-M10</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M10&amp;diff=201887"/>
				<updated>2015-10-08T18:33:13Z</updated>
		
		<summary type="html">&lt;p&gt;Barbarafox: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;center&amp;gt;[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]&amp;lt;/center&amp;gt;&lt;br /&gt;
{{Top_10_2010:SubsectionColoredTemplate|&amp;lt;center&amp;gt;Lack of Binary Protections&amp;lt;/center&amp;gt;||year=2014}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|Medium}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|Common}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|Easy}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Impact|Severe}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderEndTemplate}}&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;Typically, an adversary will analyze and reverse engineer a mobile app's code, then modify it to perform some hidden functionality.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;An adversary will use an automated tool to reverse engineer the code and modify it using malware to perform some hidden functionality.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;'''Prevalence'''&lt;br /&gt;
A lack of binary protections within a mobile app exposes the application and it’s owner to a large variety of technical and business risks if the underlying application is insecure or exposes sensitive intellectual property.  A lack of binary protections results in a mobile app that can be analyzed, reverse-engineered, and modified by an adversary in rapid fashion. However, an application with binary protection can still be reversed by a dedicated adversary and therefore binary protection is not a perfect security solution. At the end of the day, binary protection only slows down a security review. &lt;br /&gt;
&lt;br /&gt;
It is extremely common for apps to be deployed without binary protection. The prevalence has been extensively studied by a large number of security vendors, analysts, and researchers &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem1|1]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem2|2]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem3|3]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem17|17]]&amp;amp;#93;&amp;lt;/sup&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
'''Detectability'''&lt;br /&gt;
&lt;br /&gt;
It is difficult to detect that an adversary has reverse engineered an app’s code.  Typically, the app owner will realize reverse engineering was successful when the code shows up in another app in iTunes &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem4|4]]&amp;amp;#93;&amp;lt;/sup&amp;gt;, Google Play &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem5|5]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem16|16]]&amp;amp;#93;&amp;lt;/sup&amp;gt;, or a third-party app store &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem6|6]]&amp;amp;#93;&amp;lt;/sup&amp;gt;.  Usually, the owner discovers this by accident and not through active policing by an app store.&lt;br /&gt;
&lt;br /&gt;
There are many different viable solutions to detect code modification at runtime and respond accordingly.  At runtime, mobile apps should be enabled to detect if a runtime modification / injection has occurred and react in a number of different ways.  Pre-determined reactions of the apps will vary from either attempting to thwart the attack or fail in a subtle way &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem7|7]]&amp;amp;#93;&amp;lt;/sup&amp;gt;.&lt;br /&gt;
&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;The majority of mobile apps do not prevent an adversary from successfully analyzing, reverse engineering or modifying the app’s binary code &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem1|1]]&amp;amp;#93;&amp;lt;/sup&amp;gt;.  Organizations should apply binary protections to a mobile app under a few different circumstances:&lt;br /&gt;
&lt;br /&gt;
'''Analysis and Reverse Engineering'''&lt;br /&gt;
&lt;br /&gt;
Binary protections slow down an adversary from analyzing exposed interfaces and reverse engineering code within the mobile app.  All too often, the adversary will steal code and recycle it within another app for resell &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem16|16]]&amp;amp;#93;&amp;lt;/sup&amp;gt;.  The app owner is often unaware that the app has been repurposed and sold elsewhere unless they utilize some form of appstore monitoring service or similar.  If there is a likely chance that this may occur, the owner should consider binary protections to the app. But be warned, this protection only slows an attacker from reverse engineering. It does not prevent an attacker from doing so.&lt;br /&gt;
&lt;br /&gt;
'''Unauthorized Code Modification'''&lt;br /&gt;
&lt;br /&gt;
Binary protections slow an adversary from modifying the underlying code or behavior to disable or add additional functionality on behalf of the adversary.  This is likely to occur if the application stores, transmits, or processes personally identifiable information (PII) or other sensitive information assets like passwords or credit cards.  Code modification often takes the form of repackaging or insertion of malware into existing mobile apps &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem3|3]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem18|18]]&amp;amp;#93;&amp;lt;/sup&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;Typically, a lack of binary protection will result in the following business impacts:&lt;br /&gt;
&lt;br /&gt;
* Privacy Related and Confidential Data Theft;&lt;br /&gt;
* Unauthorized Access and Fraud;&lt;br /&gt;
* Brand and Trust Damage;&lt;br /&gt;
* Revenue Loss and Piracy;&lt;br /&gt;
* Intellectual Property Theft;&lt;br /&gt;
* User Experience Compromise.&lt;br /&gt;
&lt;br /&gt;
Many different analysts have provided policy guidance around minimizing this risk &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem8|8]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem9|9]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem10|10]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem11|11]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem12|12]]&amp;amp;#93;&amp;lt;/sup&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/td&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{Top_10_2010:SummaryTableEndTemplate}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{{Top_10_2010:SubsectionColoredTemplate|Am I Vulnerable to Lack of Binary Protections?||year=2014}}&lt;br /&gt;
&lt;br /&gt;
If you are hosting code in an untrustworthy environment, you are susceptible to this risk &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem1|1]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem2|2]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem3|3]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem17|17]]&amp;amp;#93;&amp;lt;/sup&amp;gt;.  An untrustworthy environment is defined as an environment in which the organization does not have physical control.  This includes mobile clients, firmware in appliances, cloud spaces, or datacenters within particular countries.&lt;br /&gt;
&lt;br /&gt;
If you answer yes to any of these questions, you are vulnerable to a binary attack:&lt;br /&gt;
&lt;br /&gt;
:* Can someone code-decrypt this app (iPhone specific) using an automated tool like ClutchMod or manually using GDB? &lt;br /&gt;
&lt;br /&gt;
:* Can someone reverse engineer this app (Android specific) using an automated tool like dex2jar?&lt;br /&gt;
&lt;br /&gt;
:* Can someone use an automated tool like Hopper or IDA Pro to easily visualize the control-flow and pseudo-code of this app?&lt;br /&gt;
&lt;br /&gt;
:* Can someone modify the app’s presentation layer (HTML/JS/CSS) of this app within the phone and execute modified JavaScript?&lt;br /&gt;
&lt;br /&gt;
:* Can someone modify the app’s binary executable using a hex editor to get it to bypass a security control?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{{Top_10_2010:SubsectionColoredTemplate|How Do I Prevent Lack of Binary Protections?||year=2014}}&lt;br /&gt;
&lt;br /&gt;
First, the application must follow secure coding techniques for the following security components within the mobile app:&lt;br /&gt;
&lt;br /&gt;
:* Jailbreak Detection Controls;&lt;br /&gt;
:* Checksum Controls;&lt;br /&gt;
:* Certificate Pinning Controls;&lt;br /&gt;
:* Debugger Detection Controls.&lt;br /&gt;
&lt;br /&gt;
Next, the app must adequately mitigate two different technical risks that the above controls are exposed to:&lt;br /&gt;
&lt;br /&gt;
:# The organization building the app must adequately prevent an adversary from analyzing and reverse engineering the app using static or dynamic analysis techniques;&lt;br /&gt;
:# The mobile app must be able to detect at runtime that code has been added or changed from what it knows about its integrity at compile time.  The app must be able to react appropriately at runtime to a code integrity violation.&lt;br /&gt;
&lt;br /&gt;
The remediation strategies for these types of risks are outlined in more technical detail within the [https://www.owasp.org/index.php/Technical_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification OWASP Reverse Engineering and Code Modification Prevention Project].&lt;br /&gt;
&lt;br /&gt;
'''Android Specific Best Practices:'''&lt;br /&gt;
&lt;br /&gt;
'''Android Root Detection'''&lt;br /&gt;
&lt;br /&gt;
There are a few common ways to detect a rooted Android device:&amp;lt;br&amp;gt;&lt;br /&gt;
Check for test-keys&lt;br /&gt;
:* Check to see if &amp;lt;tt&amp;gt;build.prop&amp;lt;/tt&amp;gt; includes the line ''ro.build.tags=test-keys'' indicating a developer build or unofficial ROM&lt;br /&gt;
Check for OTA certificates&lt;br /&gt;
:* Check to see if the file ''/etc/security/otacerts.zip'' exists&lt;br /&gt;
Check for several known rooted apk's&lt;br /&gt;
:* com.noshufou.android.su&lt;br /&gt;
:* com.thirdparty.superuser&lt;br /&gt;
:* eu.chainfire.supersu&lt;br /&gt;
:* com.koushikdutta.superuser&lt;br /&gt;
Check for SU binaries&lt;br /&gt;
:* &amp;lt;tt&amp;gt;/system/bin/su&amp;lt;/tt&amp;gt;&lt;br /&gt;
:* &amp;lt;tt&amp;gt;/system/xbin/su&amp;lt;/tt&amp;gt;&lt;br /&gt;
:* &amp;lt;tt&amp;gt;/sbin/su&amp;lt;/tt&amp;gt;&lt;br /&gt;
:* &amp;lt;tt&amp;gt;/system/su&amp;lt;/tt&amp;gt;&lt;br /&gt;
:* &amp;lt;tt&amp;gt;/system/bin/.ext/.su&amp;lt;/tt&amp;gt;&lt;br /&gt;
Attempt SU command directly&lt;br /&gt;
:* Attempt the to run the command &amp;lt;tt&amp;gt;su&amp;lt;/tt&amp;gt; and check the id of the current user, if it returns 0 then the su command has been successful&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=7}}&lt;br /&gt;
This section outlines typical app vulnerabilities that result from a lack of binary protection.  Items within parenthesis indicate examples of tools you can use to test for these vulnerabilities.&lt;br /&gt;
&lt;br /&gt;
==iOS Apps==&lt;br /&gt;
&lt;br /&gt;
:* Disabling Code Encryption (''ClutchMod'');&lt;br /&gt;
:* Jailbreak Detection Evasion (''xcon'');&lt;br /&gt;
:* Class Dumping (''class-dump-z'');&lt;br /&gt;
:* Method Swizzling (''Mobile Substrate'');&lt;br /&gt;
:* Runtime Code Injection (''cycript'');&lt;br /&gt;
:* Runtime Monitoring (''Snoop-It'');&lt;br /&gt;
:* Runtime Analysis (''GDB''); and&lt;br /&gt;
:* Reverse Engineering (''[https://www.hex-rays.com/products/ida/ IDA Pro]; Hopper'').&lt;br /&gt;
&lt;br /&gt;
== Android Apps==&lt;br /&gt;
&lt;br /&gt;
:* Bytecode Conversion (''apktool; dex2jar'');&lt;br /&gt;
:* Runtime Analysis (''ADB'');&lt;br /&gt;
:* Reverse Engineering (''[https://www.hex-rays.com/products/ida/ IDA Pro]; Hopper'');&lt;br /&gt;
:* Disassembly (''baksmali'') and&lt;br /&gt;
:* Code Injection (''Mobile Substrate'').&lt;br /&gt;
&lt;br /&gt;
== Windows Phone Apps==&lt;br /&gt;
&lt;br /&gt;
:* .NET Decompiler (''[https://www.jetbrains.com/decompiler/ JetBrains dotPeak]; [http://ilspy.net/ ILSpy]; [http://www.red-gate.com/products/dotnet-development/reflector/ RedGate .NET Reflector] '');&lt;br /&gt;
:* Runtime Analysis (''[https://github.com/andreycha/tangerine Tangerine]; [https://github.com/sensepost/xapspy XAPSpy]'');&lt;br /&gt;
:* Reverse Engineering (''[https://www.hex-rays.com/products/ida/ IDA Pro]'');&lt;br /&gt;
:* Disassembly (''[https://msdn.microsoft.com/en-us/library/f7dy01k1%28v=vs.110%29.aspx MSIL Disassembler (Ildasm.exe)]'') and&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
There are many well-established security experts within the mobile space that have written books on the topic of binary protection testing &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem13|13]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem14|14]]&amp;amp;#93;&amp;lt;/sup&amp;gt; &amp;lt;sup&amp;gt;&amp;amp;#91;[[#ReferenceItem15|15]]&amp;amp;#93;&amp;lt;/sup&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=7}}&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem1&amp;quot;&amp;gt;[1] Arxan Research: [https://www.arxan.com/assets/1/7/State_of_Security_in_the_App_Economy_Report_Vol._2.pdf State of Security in the App Economy, Volume 2], November 2013:&lt;br /&gt;
:''“Adversaries have hacked 78 percent of the top 100 paid Android and iOS apps in 2013.”''&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem2&amp;quot;&amp;gt;[2] HP Research: [http://www8.hp.com/us/en/hp-news/press-release.html?id=1528865#.UuwZFPZvDi5 HP Research Reveals Nine out of 10 Mobile Applications Vulnerable to Attack], 18 November 2013:&lt;br /&gt;
:''&amp;quot;86 percent of applications tested lacked binary hardening, leaving applications vulnerable to information disclosure, buffer overflows and poor performance. To ensure security throughout the life cycle of the application, it is essential to build in the best security practices from conception.&amp;quot;''&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem3&amp;quot;&amp;gt;[3] North Carolina State University: [http://www.csc.ncsu.edu/faculty/jiang/pubs/OAKLAND12.pdf Dissecting Android Malware: Characterization and Evolution], 7 September 2011:&lt;br /&gt;
:''“Our results show that 86.0% of them (Android Malware) repackage legitimate apps to include malicious payloads; 36.7% contain platform-level exploits to escalate privilege; 93.0% exhibit the bot-like capability.”''&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem4&amp;quot;&amp;gt;[4] Tech Hive: [http://www.techhive.com/article/249310/apple_pulls_ripoff_apps_from_its_walled_garden.html Apple Pulls Ripoff Apps from its Walled Garden]Feb 4th, 2012:&lt;br /&gt;
:''“While Apple is known for screening apps before they are allowed to sprout up in its walled garden, clearly fake apps do get in. Once they do, getting them out depends on developers who raise a fuss.”''&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem5&amp;quot;&amp;gt;[5] Tech Crunch: [http://techcrunch.com/2014/01/02/developer-spams-google-play-with-ripoffs-of-well-known-apps-again/ Developer Spams Google Play With RipOffs of Well-Known Apps… Again], January 2 2014:&lt;br /&gt;
:''“It’s not uncommon to search the Google Play app store and find a number of knock-off or “fake” apps aiming to trick unsuspecting searchers into downloading them over the real thing.”''&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem6&amp;quot;&amp;gt;[6] Extreme Tech: [http://www.extremetech.com/mobile/153849-chinese-app-store-offers-pirated-ios-apps-without-the-need-to-jailbreak Chinese App Store Offers Pirated iOS Apps Without the Need To Jailbreak], April 19 2013:&lt;br /&gt;
:''“The site offers apps for free that would otherwise cost money, including big-name titles.”''&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem7&amp;quot;&amp;gt;[7] OWASP: [https://www.owasp.org/index.php/Architectural_Principles_That_Prevent_Code_Modification_or_Reverse_Engineering Architectural Principles That Prevent Code Modification or Reverse Engineering], January 11th 2014.&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem8&amp;quot;&amp;gt;[8] Gartner report: Avoiding Mobile App Development Security Pitfalls, 24 May 2013:&lt;br /&gt;
:''&amp;quot;For critical applications, such as transactional ones and sensitive enterprise applications, hardening should be used.&amp;quot;''&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem9&amp;quot;&amp;gt;[9] Gartner report: Emerging Technology Analysis:  Mobile Application Shielding, March 26th, 2013:&lt;br /&gt;
:''&amp;quot;As more regulated and sensitive data applications move to mobile platforms the need to increase data protection increases. Mobile application shielding presents the opportunity to security providers to offer higher data protection standards to mobile platforms that exceed mobile OS security.&amp;quot;''&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem10&amp;quot;&amp;gt;[10] Gartner report: Proliferating Mobile Transaction Attack Vectors and What to Do About Them, March 1st, 2013:&lt;br /&gt;
:''&amp;quot;Use mobile application security testing services and self-defending application utilities to help prevent hacking attempts.&amp;quot;''&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem11&amp;quot;&amp;gt;[11] Gartner report: Select a Secure Mobile Wallet for Proximity, March 1st, 2013:&lt;br /&gt;
:''&amp;quot;Application hardening can fortify sensitive business code against hacking attempts, such as reverse engineering”''&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem12&amp;quot;&amp;gt;[12] Forrester paper: Choose The Right Mobile Development Solutions For Your Organization, May 6th 2013:&lt;br /&gt;
:''“5 Key Protections: Data Protection, App Compliance, App-Level Threat Defense, Security Policy Enforcement, App Integrity”''&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem13&amp;quot;&amp;gt;[13] John Wiley and Sons, Inc: [http://www.amazon.com/iOS-Hackers-Handbook-Charlie-Miller/dp/1118204123 iOS Hacker's Handbook], Published May 2012, ISBN 1118204123.&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem14&amp;quot;&amp;gt;[14] McGraw Hill Education: [http://mobilehackingexposed.com/ Mobile Hacking Exposed], Published July 2013, ISBN 0071817018.&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem15&amp;quot;&amp;gt;[15] Publisher Unannounced: [http://www.amazon.com/Android-Hackers-Handbook-Joshua-Drake/dp/111860864X Android Hacker's Handbook], To Be Published April 2014.&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem16&amp;quot;&amp;gt;[16] Software Development Times: [http://sdt.bz/66393#ixzz2sHa7dFMp More than 5,000 apps in the Google Play Store are copied APKs, or 'thief-ware'], November 20 2013:&lt;br /&gt;
:''“In most cases, the 2,140 copycat developers that were found reassembled the apps almost identically, adding new advertising SDKs to siphon profits away from the original developers.''&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem17&amp;quot;&amp;gt;[17] InfoSecurity Magazine: [http://www.infosecurity-magazine.com/view/36376/two-thirds-of-personal-banking-apps-found-full-of-vulnerabilities/ Two Thirds of Personal Banking Apps Found Full of Vulnerabilities], January 3 2014:&lt;br /&gt;
:''“But one of his more worrying findings came from disassembling the apps themselves ... what he found was hardcoded development credentials within the code. An attacker could gain access to the development infrastructure of the bank and infest the application with malware causing a massive infection for all of the application’s users.”''&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span id=&amp;quot;ReferenceItem18&amp;quot;&amp;gt;[18] InfoSecurity Magazine: [http://www.infosecurity-magazine.com/view/36686/mobile-malware-infects-millions-lte-spurs-growth/ Mobile Malware Infects Millions; LTE Spurs Growth], January 29 2014:&lt;br /&gt;
:''&amp;quot;Number of mobile malware samples is growing at a rapid clip, increasing by 20-fold in 2013... It is trivial for an attacker to hijack a legitimate Android application, inject malware into it and redistribute it for consumption. There are now binder kits available that will allow an attacker to automatically inject malware into an existing application&amp;quot;''&amp;lt;/span&amp;gt;&lt;/div&gt;</summary>
		<author><name>Barbarafox</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M8&amp;diff=201886</id>
		<title>Mobile Top 10 2014-M8</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M8&amp;diff=201886"/>
				<updated>2015-10-08T18:32:13Z</updated>
		
		<summary type="html">&lt;p&gt;Barbarafox: missing period.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;center&amp;gt;[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]&amp;lt;/center&amp;gt;&lt;br /&gt;
{{Top_10_2010:SubsectionColoredTemplate|&amp;lt;center&amp;gt;Security Decisions Via Untrusted Inputs&amp;lt;/center&amp;gt;||year=2014}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderEndTemplate}}&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;Threat Agents include entities that can pass untrusted inputs to the sensitive method calls. Examples of such entities include, but are not limited to, users, malware and vulnerable apps.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt; Exploitability of this vulnerability remains easy. &amp;lt;br&amp;gt; An attacker with access to app can intercept intermediate calls and manipulate results via parameter tampering. &amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;Developers generally use hidden fields and values or any hidden functionality to distinguish higher level users from lower level users. An attacker can intercept the calls (IPC or web service calls) and temper with such sensitive parameters. Weak implementation of such functionalities leads to improper behavior of an app and even granting higher level permissions to an attacker.This can easily be exploited through hooking functionality. &amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;This vulnerability may lead to privilege escalation providing access of higher authorities and functionalities to an attacker. It can even bypass security mechanisms implemented by the app leading to loss of confidentiality and integrity. &amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;This vulnerability leads to loss of reputation. &amp;lt;br&amp;gt;At the same time, impacting and harming the integrity and confidentiality. &amp;lt;/td&amp;gt;&lt;br /&gt;
{{Top_10_2010:SummaryTableEndTemplate}}&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=7}}&lt;br /&gt;
Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process Communication (IPC) mechanism. In general try and adhere to the following IPC design patterns:&lt;br /&gt;
&lt;br /&gt;
* If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications&lt;br /&gt;
* Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action&lt;br /&gt;
* All input received from IPC entry points must undergo stringent input validation in order to prevent input driven attacks&lt;br /&gt;
* Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=7}}&lt;br /&gt;
iOS Specific Examples:&lt;br /&gt;
* Do not use the deprecated handleOpenURL method to handle URL Scheme calls. This method does not contain an argument containing the BundleID of the source application.&lt;br /&gt;
** Instead use the openURL:sourceApplication:annotation method and validation the sourceApplication argument against a white-list of trusted applications&lt;br /&gt;
*Do not use the iOS Pasteboard for IPC communications, as it is susceptible to being set or read by all third party apps on the device.  &lt;br /&gt;
 &lt;br /&gt;
Android Specific Examples&lt;br /&gt;
* &lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=7}}&lt;br /&gt;
Example Scenarios&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=7}}&lt;br /&gt;
References&lt;br /&gt;
&lt;br /&gt;
[https://www.owasp.org/images/c/ca/ASDC12-An_InDepth_Introduction_to_the_Android_Permissions_Modeland_How_to_Secure_MultiComponent_Applications.pdf An In Depth Introduction to the Android Permissions Modeland How to Secure MultiComponent Applications]&lt;/div&gt;</summary>
		<author><name>Barbarafox</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M8&amp;diff=201885</id>
		<title>Mobile Top 10 2014-M8</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M8&amp;diff=201885"/>
				<updated>2015-10-08T18:31:17Z</updated>
		
		<summary type="html">&lt;p&gt;Barbarafox: Grammatical errors&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;center&amp;gt;[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]&amp;lt;/center&amp;gt;&lt;br /&gt;
{{Top_10_2010:SubsectionColoredTemplate|&amp;lt;center&amp;gt;Security Decisions Via Untrusted Inputs&amp;lt;/center&amp;gt;||year=2014}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderEndTemplate}}&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;Threat Agents include entities that can pass untrusted inputs to the sensitive method calls. Examples of such entities include, but are not limited to, users, malware and vulnerable apps&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt; Exploitability of this vulnerability remains easy. &amp;lt;br&amp;gt; An attacker with access to app can intercept intermediate calls and manipulate results via parameter tampering. &amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;Developers generally use hidden fields and values or any hidden functionality to distinguish higher level users from lower level users. An attacker can intercept the calls (IPC or web service calls) and temper with such sensitive parameters. Weak implementation of such functionalities leads to improper behavior of an app and even granting higher level permissions to an attacker.This can easily be exploited through hooking functionality. &amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;This vulnerability may lead to privilege escalation providing access of higher authorities and functionalities to an attacker. It can even bypass security mechanisms implemented by the app leading to loss of confidentiality and integrity. &amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;This vulnerability leads to loss of reputation. &amp;lt;br&amp;gt;At the same time, impacting and harming the integrity and confidentiality. &amp;lt;/td&amp;gt;&lt;br /&gt;
{{Top_10_2010:SummaryTableEndTemplate}}&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=7}}&lt;br /&gt;
Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process Communication (IPC) mechanism. In general try and adhere to the following IPC design patterns:&lt;br /&gt;
&lt;br /&gt;
* If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications&lt;br /&gt;
* Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action&lt;br /&gt;
* All input received from IPC entry points must undergo stringent input validation in order to prevent input driven attacks&lt;br /&gt;
* Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=7}}&lt;br /&gt;
iOS Specific Examples:&lt;br /&gt;
* Do not use the deprecated handleOpenURL method to handle URL Scheme calls. This method does not contain an argument containing the BundleID of the source application.&lt;br /&gt;
** Instead use the openURL:sourceApplication:annotation method and validation the sourceApplication argument against a white-list of trusted applications&lt;br /&gt;
*Do not use the iOS Pasteboard for IPC communications, as it is susceptible to being set or read by all third party apps on the device.  &lt;br /&gt;
 &lt;br /&gt;
Android Specific Examples&lt;br /&gt;
* &lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=7}}&lt;br /&gt;
Example Scenarios&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=7}}&lt;br /&gt;
References&lt;br /&gt;
&lt;br /&gt;
[https://www.owasp.org/images/c/ca/ASDC12-An_InDepth_Introduction_to_the_Android_Permissions_Modeland_How_to_Secure_MultiComponent_Applications.pdf An In Depth Introduction to the Android Permissions Modeland How to Secure MultiComponent Applications]&lt;/div&gt;</summary>
		<author><name>Barbarafox</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M5&amp;diff=201884</id>
		<title>Mobile Top 10 2014-M5</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M5&amp;diff=201884"/>
				<updated>2015-10-08T18:29:59Z</updated>
		
		<summary type="html">&lt;p&gt;Barbarafox: Duplicated sentence&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;center&amp;gt;[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]&amp;lt;/center&amp;gt;&lt;br /&gt;
{{Top_10_2010:SubsectionColoredTemplate|&amp;lt;center&amp;gt;Poor Authorization and Authentication&amp;lt;/center&amp;gt;||year=2014}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderEndTemplate}}&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;Threat agents that exploit authentication vulnerabilities typically do so through automated attacks that use available or custom-built tools.&lt;br /&gt;
&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;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.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;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.&lt;br /&gt;
&lt;br /&gt;
Authentication requirements for mobile apps can be quite different from traditional web authentication schemes due to availability requirements.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;The business impact of poor authentication will typically result in the following at a minimum:&lt;br /&gt;
&lt;br /&gt;
* Reputational Damage&lt;br /&gt;
&lt;br /&gt;
In the event that a user (anonymous or verified) is able to execute over-privileged functionality, the business may experience the following impacts:&lt;br /&gt;
&lt;br /&gt;
* Reputational Damage;&lt;br /&gt;
* Fraud; or &lt;br /&gt;
* Information Theft.&lt;br /&gt;
&amp;lt;/td&amp;gt;&lt;br /&gt;
{{Top_10_2010:SummaryTableEndTemplate}}&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=5}}&lt;br /&gt;
Avoid the following Insecure Mobile Application Authentication Design Patterns:&lt;br /&gt;
&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device.&lt;br /&gt;
* 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.&lt;br /&gt;
* Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-location.&lt;br /&gt;
* Persistent authentication within mobile applications should be implemented as opt-in and not be enabled by default.&lt;br /&gt;
* If possible, do not allow users to provide 4-digit PIN numbers for authentication passwords.&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=5}}&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=5}}&lt;br /&gt;
The following scenarios showcase weak authentication or authorization controls in mobile apps:&lt;br /&gt;
&lt;br /&gt;
# 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.&lt;br /&gt;
# 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.&lt;br /&gt;
# 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.&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=5}}&lt;/div&gt;</summary>
		<author><name>Barbarafox</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M5&amp;diff=201883</id>
		<title>Mobile Top 10 2014-M5</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M5&amp;diff=201883"/>
				<updated>2015-10-08T18:29:21Z</updated>
		
		<summary type="html">&lt;p&gt;Barbarafox: spelling and grammar&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;center&amp;gt;[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]&amp;lt;/center&amp;gt;&lt;br /&gt;
{{Top_10_2010:SubsectionColoredTemplate|&amp;lt;center&amp;gt;Poor Authorization and Authentication&amp;lt;/center&amp;gt;||year=2014}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderEndTemplate}}&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;Threat agents that exploit authentication vulnerabilities typically do so through automated attacks that use available or custom-built tools.&lt;br /&gt;
&lt;br /&gt;
Threat agents that exploit authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;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.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;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.&lt;br /&gt;
&lt;br /&gt;
Authentication requirements for mobile apps can be quite different from traditional web authentication schemes due to availability requirements.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;The business impact of poor authentication will typically result in the following at a minimum:&lt;br /&gt;
&lt;br /&gt;
* Reputational Damage&lt;br /&gt;
&lt;br /&gt;
In the event that a user (anonymous or verified) is able to execute over-privileged functionality, the business may experience the following impacts:&lt;br /&gt;
&lt;br /&gt;
* Reputational Damage;&lt;br /&gt;
* Fraud; or &lt;br /&gt;
* Information Theft.&lt;br /&gt;
&amp;lt;/td&amp;gt;&lt;br /&gt;
{{Top_10_2010:SummaryTableEndTemplate}}&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=5}}&lt;br /&gt;
Avoid the following Insecure Mobile Application Authentication Design Patterns:&lt;br /&gt;
&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device.&lt;br /&gt;
* 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.&lt;br /&gt;
* Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-location.&lt;br /&gt;
* Persistent authentication within mobile applications should be implemented as opt-in and not be enabled by default.&lt;br /&gt;
* If possible, do not allow users to provide 4-digit PIN numbers for authentication passwords.&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=5}}&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=5}}&lt;br /&gt;
The following scenarios showcase weak authentication or authorization controls in mobile apps:&lt;br /&gt;
&lt;br /&gt;
# 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.&lt;br /&gt;
# 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.&lt;br /&gt;
# 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.&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=5}}&lt;/div&gt;</summary>
		<author><name>Barbarafox</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M3&amp;diff=201882</id>
		<title>Mobile Top 10 2014-M3</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M3&amp;diff=201882"/>
				<updated>2015-10-08T18:26:23Z</updated>
		
		<summary type="html">&lt;p&gt;Barbarafox: spelling&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;center&amp;gt;[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]&amp;lt;/center&amp;gt;&lt;br /&gt;
{{Top_10_2010:SubsectionColoredTemplate|&amp;lt;center&amp;gt;Insufficient Transport Layer Protection&amp;lt;/center&amp;gt;||year=2014}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-3-Template|Exploitability|DIFFICULT}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Detectability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Impact|MODERATE}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderEndTemplate}}&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;When designing a mobile application, data is commonly exchanged in a client-server fashion. When the solution transmits its data, it must traverse the mobile device's carrier network and the internet. Threat agents might exploit vulnerabilities to intercept sensitive data while it's traveling across the wire. The following threat agents exist:&lt;br /&gt;
&lt;br /&gt;
* An adversary that shares your local network (compromised or monitored Wi-Fi);&lt;br /&gt;
* Carrier or network devices (routers, cell towers, proxy's, etc); or&lt;br /&gt;
* Malware on your mobile device.&lt;br /&gt;
&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt; The exploitabilty factor of monitoring a network for insecure communications ranges. Monitoring traffic over a carrier's network is harder than that of monitoring a local coffee shop's traffic. In general, targeted attacks are easier to perform.  &amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;Mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication but not elsewhere.  This inconsistency leads to the risk of exposing data and session IDs to interception.&lt;br /&gt;
&lt;br /&gt;
The use of transport security does not mean the app has implemented it correctly.&lt;br /&gt;
&lt;br /&gt;
To detect basic flaws, observe the phone's network traffic. More subtle flaws require inspecting the design of the application and the applications configuration. &amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;This flaw exposes an individual user's data and can lead to account theft. If the adversary intercepts an admin account, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;At a minimum, interception of sensitive data through a communication channel will result in a privacy violation.&lt;br /&gt;
&lt;br /&gt;
The violation of a user's confidentiality may result in:&lt;br /&gt;
&lt;br /&gt;
* Identity theft;&lt;br /&gt;
* Fraud, or&lt;br /&gt;
* Reputational Damage.&amp;lt;/td&amp;gt;&lt;br /&gt;
{{Top_10_2010:SummaryTableEndTemplate}}&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=3}}&lt;br /&gt;
To find out if an application has sufficient transport layer protection, look at the application traffic through a proxy. Answer the following questions:&lt;br /&gt;
&lt;br /&gt;
# Are all connections, not just ones to servers you own, properly encrypted? &lt;br /&gt;
# Are the SSL certificates in date?&lt;br /&gt;
# Are the SSL certificates self signed?&lt;br /&gt;
# Does the SSL use high enough cipher strengths?&lt;br /&gt;
# Will your application accept user accepted certificates as authorities?&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=3}}&lt;br /&gt;
'''General Best Practices:'''&lt;br /&gt;
&lt;br /&gt;
* Assume that the network layer is not secure and is susceptible to eavesdropping. &lt;br /&gt;
* Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.&lt;br /&gt;
* Account for outside entities like third-party analytics companies, social networks, etc. by using their SSL versions when an application runs a routine via the browser/webkit. Avoid mixed SSL sessions as they may expose the user’s session ID.&lt;br /&gt;
* Use strong, industry standard cipher suites with appropriate key lengths.&lt;br /&gt;
* Use certificates signed by a trusted CA provider. &lt;br /&gt;
* Never allow self-signed certificates, and consider certificate pinning for security conscious applications.&lt;br /&gt;
* Always require SSL chain verification.&lt;br /&gt;
* Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.&lt;br /&gt;
* Alert users through the UI if the mobile app detects an invalid certificate.&lt;br /&gt;
* Do not send sensitive data over alternate channels (e.g, SMS, MMS, or notifications).&lt;br /&gt;
* If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future vulnerabilities are discovered in the SSL implementation, the encrypted data will provide a secondary defense against confidentiality violation.&lt;br /&gt;
&lt;br /&gt;
Newer threats allow an adversary to eavesdrop on sensitive traffic by intercepting the traffic within the mobile device just before the mobile device's SSL library encrypts and transmits the network traffic to the destination server. See M10 for more information on the nature of this risk.&lt;br /&gt;
&lt;br /&gt;
'''iOS Specific Best Practices'''&lt;br /&gt;
&lt;br /&gt;
Default classes in the latest version of iOS handle SSL cipher strength negotiation very well. Trouble comes when developers temporarily add code to bypass these defaults to accommodate development hurdles. In addition to the above general practices:&lt;br /&gt;
&lt;br /&gt;
* Ensure that certificates are valid and fail closed.&lt;br /&gt;
* When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength.&lt;br /&gt;
* After development, ensure all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.&lt;br /&gt;
* Consider using certificate pinning by doing the following: export your certificate, include it in your app bundle, and anchor it to your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Android Specific Best Practices'''&lt;br /&gt;
&lt;br /&gt;
* Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.&lt;br /&gt;
* If using a class which extends SSLSocketFactory, make sure checkServerTrusted method is properly implemented so that server certificate is correctly checked.&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=3}}&lt;br /&gt;
There are a few common scenarios that penetration testers frequently discover when inspecting a mobile app's transport layer security:&lt;br /&gt;
&lt;br /&gt;
; Lack of Certificate Inspection&lt;br /&gt;
: The mobile app and an endpoint successfully connect and perform a SSL/TLS handshake to establish a secure channel. However, the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint. The mobile app is susceptible to man-in-the-middle attacks through a SSL proxy&lt;br /&gt;
; Weak Handshake Negotiation&lt;br /&gt;
: The mobile app and an endpoint successfully connect and negotiate a cipher suite as part of the connection handshake. The client successfully negotiates with the server to use a weak cipher suite that results in weak encryption that can be easily decrypted by the adversary. This jeopardizes the confidentiality of the channel between the mobile app and the endpoint;&lt;br /&gt;
; Privacy Information Leakage&lt;br /&gt;
: 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.&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=3}}&lt;br /&gt;
* [http://h30499.www3.hp.com/t5/Fortify-Application-Security/Exploring-The-OWASP-Mobile-Top-10-M3-Insufficient-Transport/ba-p/5966473 Fortify On Demand Blog - Exploring The OWASP Mobile Top 10: Insufficient Transport Layer Protection]&lt;br /&gt;
* [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]&lt;br /&gt;
* [http://blog.securemacprogramming.com/2011/12/on-ssl-pinning-for-cocoa-touch/ blog.securemacprogramming.com - SSL Pinning for Cocoa Touch]&lt;br /&gt;
* [http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security]&lt;br /&gt;
* [http://www.hpenterprisesecurity.com/vulncat/en/vulncat/index.html Fortify VulnCat - A Taxonimy of Software Security Errors]&lt;/div&gt;</summary>
		<author><name>Barbarafox</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M2&amp;diff=201881</id>
		<title>Mobile Top 10 2014-M2</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M2&amp;diff=201881"/>
				<updated>2015-10-08T18:25:48Z</updated>
		
		<summary type="html">&lt;p&gt;Barbarafox: Grammatical errors&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;center&amp;gt;[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]&amp;lt;/center&amp;gt;&lt;br /&gt;
{{Top_10_2010:SubsectionColoredTemplate|&amp;lt;center&amp;gt;Insecure Data Storage&amp;lt;/center&amp;gt;||year=2014}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}&lt;br /&gt;
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}&lt;br /&gt;
{{Top_10_2010:SummaryTableHeaderEndTemplate}}&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;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.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;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.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;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.&lt;br /&gt;
&lt;br /&gt;
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.&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;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: &lt;br /&gt;
* Usernames&lt;br /&gt;
* Authentication tokens&lt;br /&gt;
* Passwords&lt;br /&gt;
* Cookies&lt;br /&gt;
* Location data&lt;br /&gt;
* UDID/EMEI, Device Name, Network Connection Name&lt;br /&gt;
* Personal Information: DoB, Address, Social, Credit Card Data&lt;br /&gt;
* Application Data: &lt;br /&gt;
** Stored application logs&lt;br /&gt;
** Debug information&lt;br /&gt;
** Cached application messages&lt;br /&gt;
** Transaction histories&amp;lt;/td&amp;gt;&lt;br /&gt;
     &amp;lt;td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}&amp;gt;Insecure data storage vulnerabilities typically lead to the following business risks for the organization that owns the risk app:&lt;br /&gt;
* Identity Theft&lt;br /&gt;
* Fraud&lt;br /&gt;
* Reputation Damage&lt;br /&gt;
* External Policy Violation (PCI)&lt;br /&gt;
* or Material Loss.&amp;lt;/td&amp;gt;&lt;br /&gt;
{{Top_10_2010:SummaryTableEndTemplate}}&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=1}}&lt;br /&gt;
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:&lt;br /&gt;
 &lt;br /&gt;
* SQLite databases&lt;br /&gt;
* Log Files&lt;br /&gt;
* Plist Files&lt;br /&gt;
* XML Data Stores or Manifest Files&lt;br /&gt;
* Binary data stores&lt;br /&gt;
* Cookie stores&lt;br /&gt;
* SD Card&lt;br /&gt;
* Cloud synced&lt;br /&gt;
&lt;br /&gt;
When applying encryption and decryption to sensitive information assets, malware may perform a binary attack on the app in order to steal encryption or decryption keys. Once it steals the keys, it will decrypt the local data and steal sensitive information. See OWASP Mobile Top Ten 2014 Category M10 for more information on this topic.&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=1}}&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''iOS Specific Best Practices:'''&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* For databases consider using SQLcipher for Sqlite data encryption&lt;br /&gt;
* 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.&lt;br /&gt;
* 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).&lt;br /&gt;
* Avoid using NSUserDefaults to store sensitive pieces of information as it stores data in plist files.&lt;br /&gt;
* Be aware that all data/entities using NSManagedObects will be stored in an unencrypted database file.&lt;br /&gt;
* Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive information assets.&lt;br /&gt;
* Consider providing an additional layer of encryption beyond any default encryption mechanisms provided by the operating system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Android Specific Best Practices:'''&lt;br /&gt;
* For local storage the enterprise android device administration API can be used to force encryption to local file-stores using “setStorageEncryption”&lt;br /&gt;
* 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.&lt;br /&gt;
* Ensure any shared preferences properties are '''NOT''' MODE_WORLD_READABLE unless explicitly required for information sharing between apps.&lt;br /&gt;
* Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive information assets.&lt;br /&gt;
* Consider providing an additional layer of encryption beyond any default encryption mechanisms provided by the operating system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=1}}&lt;br /&gt;
&lt;br /&gt;
'''A Visual Example:'''&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Image:Screen%20Shot%202012-12-19%20at%206.34.23%20AM.png]] &lt;br /&gt;
[[Image:Screen%20Shot%202012-12-19%20at%206.44.51%20AM.png]] &lt;br /&gt;
[[Image:Screen%20Shot%202012-12-19%20at%2010.11.15%20AM.png]]&lt;br /&gt;
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=1}}&lt;br /&gt;
* [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]&lt;br /&gt;
* [http://source.android.com/tech/security/ Google Androids Developer Security Topics 1]&lt;br /&gt;
* [http://developer.android.com/training/articles/security-tips.html Google Androids Developer Security Topics 2]&lt;br /&gt;
* [https://developer.apple.com/library/mac/ Apple's Introduction to Secure Coding]&lt;br /&gt;
* [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]&lt;/div&gt;</summary>
		<author><name>Barbarafox</name></author>	</entry>

	</feed>