This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Mobile Top 10 2014-M7
| Threat Agents | Attack Vectors | Security Weakness | Technical Impacts | Business Impacts | |
|---|---|---|---|---|---|
| Application Specific | Exploitability EASY |
Prevalence COMMON |
Detectability EASY |
Impact MODERATE |
Application / Business Specific |
| Consider anyone who can send untrusted data to the system, including external users, internal users, and the application itself. | 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. | 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. | As stated the Impact of client side injections can vary depending on the type of data or type of the application. | Business Impacts | |
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.
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.
Example Scenarios
Fortify Software: Format Strings - Is Objective C Objectively Safer?
