Mobile Top 10 2014-M7 - Revision history

Stephencor at 07:08, 8 October 2014

2014-10-08T07:08:53Z

Jonathan Carter at 00:52, 10 April 2014

2014-04-10T00:52:42Z

Jason Haddix at 08:49, 27 January 2014

2014-01-27T08:49:26Z

Jason Haddix at 07:35, 27 January 2014

2014-01-27T07:35:30Z

Jason Haddix: Created page with "{{Top_10_2010:SummaryTableHeaderBeginTemplate}} {{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}} {{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}..."

2014-01-27T06:52:49Z

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|MODERATE}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider anyone who can send untrusted data to the system, including external users, internal users, and the application itself. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attacker loads simple text-based attacks that exploit the syntax of the targeted interpreter. Almost any source of data can be an injection vector, including resource files or the application itself. </td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Client Side Injection for Mobile Applications is a mixed bag. To properly determine the Impact you must threat model the application. Injection attacks such as SQL Injection on client devices can be severe if your application deals with more than one user account on a single application or a shared device, or paid-for-only content. Other injection points are meant to overflow applications components but are less likely to achieve a high impact result because of the managed code protections of the application languages. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>As stated the Impact of client side injections can vary depending on the type of data or type of the application. </td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Business Impacts </td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=4}}

The best way to find out if an application is vulnerable to injection is to identify the sources of input and validate that user/application supplied data is being subject to input validation, disallowing code injection. Checking the code is a fast and accurate way to see if the application is handling data correctly. Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Manual penetration testers can confirm these issues by crafting exploits that confirm the vulnerability.

Since data can come from many sources in mobile applications we feel it is important list them delineated by what they are trying to achieve. In general injection attacks on mobile devices target the following:

'''Data on the Device:'''

* SQL Injection: SQLite (many phones default data storing mechanism) can be subject to injection just like in web applications. The threat of being able to see data using this type of injection is risky when your application houses several different users, paid-for/unlockable content, etc.
* Local File Inclusion: File handling on mobile devices has the same risks as stated above except it pertains to reading files that might be yours to view inside the application directory.

'''The Mobile Users Session:'''
* JavaScript Injection (XSS, Etc): The mobile browser is subject to JavaScript injection as well. Usually the mobile browser has access to the mobile applications cookie, which can lead to session theft.

'''The Application Interfaces or Functions:'''
* Several application interfaces or language functions can accept data and can be fuzzed to make applications crash. While most of these flaws do not lead to overflows because of the phone’s platforms being managed code, there have been several that have been used as a “userland” exploit in an exploit chain aimed at rooting or jailbreaking devices.

{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=4}}
In general, protecting you application from client side injection requires looking at all the areas your application can receive data from and applying some sort of input validation. In certain cases this is simple but for others it is more complex, see below:

'''iOS Specific Best Practices:'''

* '''SQLite Injection:''' When designing queries for SQLite be sure that user supplied data is being passed to a parameterized query. This can be spotted by looking for the format specifier used. In general, dangerous user supplied data will be inserted by a “%@” instead of a proper parameterized query specifer of “?”.
* '''JavaScript Injection (XSS, etc):''' Ensure that all UIWebView calls do not execute without proper input validation. Apply filters for dangerous JavaScript characters if possible, using a whitelist over blacklist character policy before rendering. If possible call mobile Safari instead of rending inside of UIWebkit which has access to your application.
* '''Local File Inclusion:''' Use input validation for NSFileManager calls.
* '''XML Injection:''' use libXML2 over NSXMLParser
* '''Format String Injection:''' Several Objective C methods are vulnerable to format string attacks:
** NSLog, [NSString stringWithFormat:], [NSString initWithFormat:], [NSMutableString appendFormat:], [NSAlert informativeTextWithFormat:], [NSPredicate predicateWithFormat:], [NSException format:], NSRunAlertPanel.
** Do not let sources outside of your control, such as user data and messages from other applications or web services, control any part of your format strings.
* '''Classic C Attacks:''' Objective C is a superset of C, avoid using old C functions vulnerable to injection such as: strcat, strcpy, strncat, strncpy, sprint, vsprintf, gets, etc.

'''Android Specific Best Practices:'''

* '''SQL Injection:''' When dealing with dynamic queries or Content-Providers ensure you are using parameterized queries.
* '''JavaScript Injection (XSS):''' Verify that JavaScript and Plugin support is disabled for any WebViews (usually the default).
* '''Local File Inclusion:''' Verify that File System Access is disabled for any WebViews (webview.getSettings().setAllowFileAccess(false);).
* '''Intent Injection/Fuzzing:''' Verify actions and data are validated via an Intent Filter for all Activities.
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=4}}
Example Scenarios
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=4}}
[https://developer.apple.com/library/mac/#documentation/security/conceptual/SecureCodingGuide Apple’s Secure Coding Guide]

[http://blog.fortify.com/blog/2012/07/25/Format-Strings-Is-Objective-C-Objectively-Safer Fortify Software: Format Strings - Is Objective C Objectively Safer?]

[http://www.youtube.com/watch?v=FJvyLUjbAy0 Ilja Van Sprundel – Auditing iPhone and iPad Applications]

[http://labs.mwrinfosecurity.com/blog/2012/04/23/adventures-with-android-webviews/ Adventures with Android WebViews]

@@ Line 9: / Line 9: @@
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider anyone who can send untrusted data to the mobile app, including external users, internal users, the application itself or other malicious apps on the mobile device.</td>
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The adversary loads simple text-based attacks that exploit the syntax of the targeted interpreter within the mobile app. Almost any source of data can be an injection vector, including resource files or the application itself.</td>
-      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Client-side injection results in the execution of malicous code on the mobile device via the mobile app. Typically, this malicious code is provided in the form of data that the threat agent inputs to the mobile app through a number of differnt means. The data is malformed and is processed (like all other data) by the underlying frameworks supporting the mobile app. During processing, this special data is forces a context switch and the framework reinterprets the data as executable code. The code is malicious in nature and executed by the app. In the "best-case" scenario, the code runs with the same scope and access permissions as the user that has unintentionally executed this code. In the worst-case scenario, the code executes with priviliged permissions and much greater scope leading to much greater damage potential than in the "best-case" scenario.
+      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Client-side injection results in the execution of malicious code on the mobile device via the mobile app. Typically, this malicious code is provided in the form of data that the threat agent inputs to the mobile app through a number of different means. The data is malformed and is processed (like all other data) by the underlying frameworks supporting the mobile app. During processing, this special data is forces a context switch and the framework reinterprets the data as executable code. The code is malicious in nature and executed by the app. In the "best-case" scenario, the code runs with the same scope and access permissions as the user that has unintentionally executed this code. In the worst-case scenario, the code executes with privileged permissions and much greater scope leading to much greater damage potential than in the "best-case" scenario.
 There are other forms of client-side injection that involve direct injection of binary code into the mobile app via binary attacks. This brute-force approach to malicious code execution may lead to even greater potential for damage than data injections. For more information on binary attacks, see M10.</td>
@@ Line 42: / Line 42: @@
 '''Binary Code Itself:'''
-* Mobile malware or other malicious apps may perform a binary attack against the presentation layer (HTML; JavaScript; Cascading Style Sheets CSS) or the actual binary of the mobile app's executable. These code injections are executed either by the mobile app's framework or the binary itself at runtime.
+* Mobile malware or other malicious apps may perform a binary attack against the presentation layer (HTML; JavaScript; Cascading Style Sheets CSS) or the actual binary of the mobile app's executable. These code injections are executed either by the mobile app's framework or the binary itself at run-time.
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=4}}
@@ Line 51: / Line 51: @@
-* '''SQLite Injection:''' When designing queries for SQLite be sure that user supplied data is being passed to a parameterized query. This can be spotted by looking for the format specifier used. In general, dangerous user supplied data will be inserted by a “%@” instead of a proper parameterized query specifer of “?”.
+* '''SQLite Injection:''' When designing queries for SQLite be sure that user supplied data is being passed to a parameterized query. This can be spotted by looking for the format specifier used. In general, dangerous user supplied data will be inserted by a “%@” instead of a proper parameterized query specifier of “?”.
 * '''JavaScript Injection (XSS, etc):''' Ensure that all UIWebView calls do not execute without proper input validation. Apply filters for dangerous JavaScript characters if possible, using a whitelist over blacklist character policy before rendering. If possible call mobile Safari instead of rending inside of UIWebkit which has access to your application.
 * '''Local File Inclusion:''' Use input validation for NSFileManager calls.
@@ Line 77: / Line 77: @@
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=4}}
 Classic client-side injection scenarios include the following:
-# SQL Injection - Data retrieved from a mobile app's server contains malformed data that results in a local SQL injetion within the mobile device's local databases. Local SQL injections may result in local malware injection, information theft, and much more;
+# SQL Injection - Data retrieved from a mobile app's server contains malformed data that results in a local SQL injection within the mobile device's local databases. Local SQL injections may result in local malware injection, information theft, and much more;
 # Cross-Application Scripting Attacks - Malicious intents fed from one Android application to another may result in buffer overflows that allow for malicious code execution;
 # Cross-Site Script Attacks - Local HTML modifications via malware or other apps results in execution of malicious JavaScript in the presentation layer of the app. This may result in information theft.

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

← Older revision		Revision as of 07:35, 27 January 2014
Line 1:		Line 1:
		+	{{Top_10_2010:SubsectionColoredTemplate\|<center>Client Side Injection</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 7: / Line 7: @@
 {{Top_10_2010:SummaryTableValue-1-Template|Impact|MODERATE}}
 {{Top_10_2010:SummaryTableHeaderEndTemplate}}
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider anyone who can send untrusted data to the system, including external users, internal users, and the application itself.  </td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider anyone who can send untrusted data to the mobile app, including external users, internal users, the application itself or other malicious apps on the mobile device.</td>
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attacker loads simple text-based attacks that exploit the syntax of the targeted interpreter. Almost any source of data can be an injection vector, including resource files or the application itself. </td>
+      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The adversary loads simple text-based attacks that exploit the syntax of the targeted interpreter within the mobile app. Almost any source of data can be an injection vector, including resource files or the application itself.</td>
-      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Client Side Injection for Mobile Applications is a mixed bag. To properly determine the Impact you must threat model the application. Injection attacks such as SQL Injection on client devices can be severe if your application deals with more than one user account on a single application or a shared device, or paid-for-only content. Other injection points are meant to overflow applications components but are less likely to achieve a high impact result because of the managed code protections of the application languages. </td>
+      <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Client-side injection results in the execution of malicous code on the mobile device via the mobile app. Typically, this malicious code is provided in the form of data that the threat agent inputs to the mobile app through a number of differnt means. The data is malformed and is processed (like all other data) by the underlying frameworks supporting the mobile app. During processing, this special data is forces a context switch and the framework reinterprets the data as executable code. The code is malicious in nature and executed by the app. In the "best-case" scenario, the code runs with the same scope and access permissions as the user that has unintentionally executed this code. In the worst-case scenario, the code executes with priviliged permissions and much greater scope leading to much greater damage potential than in the "best-case" scenario.
-      <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>As stated the Impact of client side injections can vary depending on the type of data or type of the application. </td>
-     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Business Impacts </td>
+There are other forms of client-side injection that involve direct injection of binary code into the mobile app via binary attacks. This brute-force approach to malicious code execution may lead to even greater potential for damage than data injections. For more information on binary attacks, see M10.</td>
 {{Top_10_2010:SummaryTableEndTemplate}}
@@ Line 18: / Line 24: @@
 The best way to find out if an application is vulnerable to injection is to identify the sources of input and validate that user/application supplied data is being subject to input validation, disallowing code injection. Checking the code is a fast and accurate way to see if the application is handling data correctly. Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Manual penetration testers can confirm these issues by crafting exploits that confirm the vulnerability.
+Since data can come from many sources in mobile applications, it is important to list them delineated by what they are trying to achieve. In general, injection attacks on mobile devices target the following:
@@ Line 35: / Line 40: @@
 * Several application interfaces or language functions can accept data and can be fuzzed to make applications crash. While most of these flaws do not lead to overflows because of the phone’s platforms being managed code, there have been several that have been used as a “userland” exploit in an exploit chain aimed at rooting or jailbreaking devices.
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=4}}
@@ Line 60: / Line 68: @@
 * '''Local File Inclusion:'''  Verify that File System Access is disabled for any WebViews (webview.getSettings().setAllowFileAccess(false);).
 * '''Intent Injection/Fuzzing:''' Verify actions and data are validated via an Intent Filter for all Activities.
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=4}}
-Example Scenarios
+Classic client-side injection scenarios include the following:
 {{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=4}}
 [https://developer.apple.com/library/mac/#documentation/security/conceptual/SecureCodingGuide Apple’s Secure Coding Guide]