Projects/OWASP Mobile Security Project - Security Testing - Revision history

Jack Mannino at 16:55, 18 January 2013

2013-01-18T16:55:15Z

Jack Mannino at 16:54, 18 January 2013

2013-01-18T16:54:48Z

Jack Mannino at 16:49, 18 January 2013

2013-01-18T16:49:14Z

Show changes

Jack Mannino at 16:27, 18 January 2013

2013-01-18T16:27:36Z

Jack Mannino at 16:24, 18 January 2013

2013-01-18T16:24:17Z

Jack Mannino at 16:12, 18 January 2013

2013-01-18T16:12:36Z

Jack Mannino at 15:55, 18 January 2013

2013-01-18T15:55:17Z

Jack Mannino at 15:44, 18 January 2013

2013-01-18T15:44:27Z

Jack Mannino at 15:26, 18 January 2013

2013-01-18T15:26:43Z

Jack Mannino at 15:15, 18 January 2013

2013-01-18T15:15:28Z

Show changes

@@ Line 335: / Line 335: @@
 === Active Testing ===
-==== Local Testing =====
+==== Local Testing ====
 *Exposed IPC interfaces

@@ Line 335: / Line 335: @@
 === Active Testing ===
-==== Local Testing ===
+==== Local Testing =====
 *Exposed IPC interfaces

← Older revision		Revision as of 16:27, 18 January 2013
Line 301:		Line 301:

	Dynamic analysis is conducted against the backend services and APIs and the type of tests varies depending on mobile application type.		Dynamic analysis is conducted against the backend services and APIs and the type of tests varies depending on mobile application type.
		+
		+	*Native Mobile Application: Native mobile applications can be installed on to the device. This type of applications generally store most of their code on the device. Any information required can be requested to the server using the HTTP/s protocol
		+
		+	*Webservices for Mobile Application: Native mobile application that uses SOAP or REST based web services to communicate between client and Server
		+
		+	*Mobile Browser Based Application: Web browser based applications can be accessed using device’s browsers such as Safari or Chrome. Most of the commercial applications are nowadays specifically designed and optimized for mobile browsers. These applications are no different than traditional web application and all the web application vulnerabilities apply to these apps and these should be tested as traditional web apps.
		+
		+	*Mobile Hybrid Applications:Applications can leverage web browser functionality within native applications, blending the risks from both classes of applications.
		+
		+	In this phase, the mobile client, backend services, and host platform is analyzed/scanned in attempt to uncover potential risks, vulnerabilities and threats. The use of an intercepting proxy tool as well as automated vulnerability scanners are core to this phase. In many cases, you will also need some type of shell access to the device.
		+
		+	The following outline can be used as a “Dynamic Analysis” guide in planning a mobile assessment.

@@ Line 294: / Line 294: @@
 === Helpful Search Strings and Regular Expressions ===
-::To do
+-To do
 == Dynamic Analysis ==

@@ Line 215: / Line 215: @@
 *Encryption
 **Are the algorithms used “best of breed” or do they contain known issues?
 **Based on the algorithms and approaches used to encrypt data, do implementation issues exist that degrade the effectiveness of encryption?
 **How are keys managed and stored on the device? Can this reduce the complexity in breaking the encryption?
 *Identify if the application utilizes storage areas external to the “sandboxed” locations to store unencrypted data such as:
-**places with limited access control granularity (SD card, tmp directories, etc.)
+**Places with limited access control granularity (SD card, tmp directories, etc.)
-**directories that may end up in backups or other undesired locations (iTunes backup, external storage, etc.)
+**Directories that may end up in backups or other undesired locations (iTunes backup, external storage, etc.)
-**cloud storage services such as Dropbox, Google Drive, or S3
+**Cloud storage services such as Dropbox, Google Drive, or S3
 *Does the application write sensitive information to the file system at any point, such as:
-**credentials
+**Credentials
-***username + password
+***Username and/or password
 ***API keys
-***authentication tokens
+***Authentication tokens
-**payment information
+**Payment information
-**patient data
+**Patient data
-**signature files
+**Signature files
 *Is sensitive information written to data stores via platform exposed APIs such as contacts?
 === Information Disclosure ===
 *Logs
-**Does the application log sensitive information to a globally shared log?
+**Does the application log data? Is sensitive information accessible?
 **Can any of the logged information be considered a privacy violation?
 *Caches
-**predictive text
+**Predictive text
-**location information
+**Location information
 **Browser cache
 *Exceptions
 **Does sensitive data leak in crash logs?
 *Third Party Libraries and APIs
 **What permissions do they require?
 **Do they access or transmit sensitive information?
 **Can their runtime behavior expose users to privacy issues and unauthorized tracking?
 === Web Application Issues ===
 *XSS and HTML Injection
 *Command Injection (if the application utilizes a shell)
 *CSRF
 *SQL Injection
 *Cookies
 *HTML5
 === Helpful Search Strings and Regular Expressions ===
 == Dynamic Analysis ==

@@ Line 176: / Line 176: @@
 ***header information
 ***Other mechanism?
-***Are one time passwords (OTP) used or is other sensitive account data transmitted via SMS?
+**Are one time passwords (OTP) used or is other sensitive account data transmitted via SMS?
-****Can other applications access this data?
+***Can other applications access this data?
 *Push Notifications
@@ Line 186: / Line 186: @@
 *Determine if it is possible to access functionality not intended for your role
 **Identify if the application has role specific functionality within the mobile application
 **Locate any potential flags or values that may be set on the client from any untrusted source that can be a point of privilege elevation such as
 ***databases
 ***flat files
 ***HTTP responses
 **Find places within an application that were not anticipated being directly accessed without following the application’s intended workflow

@@ Line 108: / Line 108: @@
 There are two primary ways static analysis will generally be performed on a mobile application:
 #Analyzing source code obtained from development team (prefered)
-#Using a compiled binary. Some level of static analysis should be performed for both dynamic and forensic analysis, as the application’s code will almost always provide valuable information to the tester (i.e. logic, backend targets, APIs, etc).
+#Using a compiled binary.
 In scenarios where the primary goal is to identify programmatic examples of security flaws, your best bet is to review pure source code as opposed to reverse engineering compiled software. For source code reviews, it is highly beneficial to have access to either a development or production instance of any web services. This includes both source code and a working test environment to perform the assessment within in order to expedite understanding of the code.
@@ Line 116: / Line 118: @@
 **extract the application from the device
 **follow the appropriate steps for your platform’s application reverse engineering
-**some applications may require decryption prior to reverse engineering
+**some applications may also require decryption prior to reverse engineering (note: decryption and code obfuscation are not the same thing)
 *Review the permissions the application requests as well as the resources that it is authorized to access (i.e. AndroidManifest.xml, iOS Entitlements)
 *Are there any easy to identify misconfigurations within the application found within the configuration files? Debugging flags set, world readable/writable permissions, etc.
 *Identify the libraries in use including both platform provided as well as third party. Perform a quick review on the web to determine if these libraries:
@@ Line 126: / Line 130: @@
 **are free of vulnerabilities
 **expose functionality that requires elevated privileges (access to location or contact data)
-*Does the application check for rooted/jailbroken devices? How is this done? How can this be circumvented? Is it as easy as changing the case of a file name or path?
+*Does the application check for rooted/jailbroken devices? How is this done? How can this be circumvented? Is it as easy as changing the case of a file name or name of executable or path?
 *Determine what types of objects are implemented to create the various views within the application. This may significantly alter your test cases, as some views implement web browser functionality while others are native UI controls only.
@@ Line 138: / Line 143: @@
 *Identify every entry point for untrusted data entry and determine how it enforces access controls, validates and sanitizes inbound data, and passes the data off to other interpreters
-**from web service calls
+**From web service calls
-**receiving data from other apps and on-device services
+**Receiving data from other apps and on-device services
-**inbound SMS messages
+**Inbound SMS messages
-**reading information from the filesystem
+**Reading information from the filesystem
 === Authentication ===
 *Locate the code which handles user authentication through the UI. Assess the possible methods of user impersonation via vectors such as parameter tampering, replay attacks, and brute force attacks.
 *Determine if the application utilizes information beyond username/password such as
@@ Line 158: / Line 163: @@
 **Does the application properly authenticate the remote user or peer prior to granting access to device resources?
 **How does the application handle excessive failed attempts at authentication?
-*Single Sign On
+*Single Sign On, e.g.
 **OAuth
 **Facebook
@@ Line 168: / Line 175: @@
 ***password
 ***header information
-**Are one time passwords (OTP) used or is other sensitive account data transmitted via SMS?
+***Other mechanism?
-***Can other applications access this data?
+***Are one time passwords (OTP) used or is other sensitive account data transmitted via SMS?
 *Push Notifications

@@ Line 42: / Line 42: @@
 Prerequisites of this phase may require specific operating systems, platform specific software development kits (SDK’s), rooted or jailbroken devices, the ability to man-in-the-middle secure communications (i.e. HTTPS) and bypass invalid certificate checks.
-*Proxy and sniff all network traffic from either a physical mobile device or an emulator/simulator. Begin recording and logging traffic (if your proxy tool permits logging, which most should).
+*Manually navigate through the running application to understand the basic functionality and workflow of the application. This can be performed on a real device or within a simulator/emulator. For deeper understanding of application functionality tester can proxy and sniff all network traffic from either a physical mobile device or an emulator/simulator recording and logging traffic (if your proxy tool permits logging, which most should).
-*Register for and/or provision test accounts. Ideally, you will want two accounts per user role to ensure proper testing of vertical and horizontal privilege escalation attack vectors.
+*Identify the networking interfaces used by the application, for instance:
-*Manually navigate through the running application to understand the basic functionality and workflow of the application. This can be performed on a real device or within a simulator/emulator.
+*Determine what the application supports for access 3G, 4G, wifi and or others
-*Identify the networking interfaces used by the application
+*What networking protocols are in use?
-**3G/4G
+**Are secure protocols used where needed?
-**Wifi
+**Can they be switched with insecure protocols?
 *Does the application perform commerce transactions?
-**credit card transactions and/or stored payment information.
+**Credit card transactions and/or stored payment information (certain industry regulations may be required (i.e. PCI DSS)).
-**in-app purchasing of goods or features
+**In-app purchasing of goods or features
 *Monitor and identify the hardware components that the application may potentially interact with
@@ Line 70: / Line 67: @@
 **Microphone
 **Sensors
 *Perform open source intelligence gathering (search engines, source code repositories, developer forums, etc.) to identify source code or configuration information that may be exposed (i.e. 3rd party components integrated within the application)
 *Identify if the application appears to interact with any other applications, services, or data such as:
 **Telephony (SMS, phone)
 **Contacts
 **Google Wallet
 **iCloud
@@ Line 82: / Line 84: @@
 **Evernote
 **Email
 *Can you determine anything about the server side application environment?
@@ Line 95: / Line 98: @@
 *Perform a thorough crawl of exposed web resources and sift through the requests and responses to identify potentially interesting data or behavior
-**leaking credentials
+**Leaking sensitive information (i.e. credentials) in the response
-**resources not exposed through the UI
+**Resources not exposed through the UI
-**error messages
+**Error messages
-**cacheable information
+**Cacheable information