Total Pageviews

Mobile

Mobile Testing Interview questions:


What is the difference between mobile web vs native application?
Would you recommend to develop mobile web vs native application?
What is the latest device available for iOS, Android or Windows Mobile 7?
Tell the difference between Android Gingerbread and Android Honeycomb operations systems?
Explain in details the challenges of mobile application testing?
How would you do functionality testing in mobile world?
How would you approach mobile application usability testing?
Do you have a performance testing experience for mobile applications?
How do you test that the mobile app design will be consistent across the different phones?
What do you have to do to test a new application on a real phone?
What are pros and cons of using mobile emulators and simulators for mobile testing?
How would you implement test automation for mobile testing?
Can we test mobile apps using Selenium test automation tool?
Would you recommend to implement Agile for mobile testing?

Part 1:


Part 2:



Mobile applications - an Overview

More and more consumers are using mobile / smart phones - so mobile applications are a great way to directly connect with customers. They connect with consumers in real-time and therefore provide services anytime anywhere.
Mobile applications can be categorized under communications, games, utilities, multimedia, productivity and travel based on their functionality. However, for security testing our focus is mainly on applications from Banking / Finance domain under the productivity category.
From a technical point of view, mobile applications can be differentiated by the runtime environment they run in:
  1. Operating systems such as Symbian, Windows Mobile and Linux
  2. Platforms and virtual machines such as .Net Mobile, Java/J2ME, BREW, Flash Lite and Silverlight
Note: This article discusses testing of JAVA/J2ME based mobile applications. Although, similar approach may be followed for testing mobile applications based on other platforms.

Prerequisites for a Mobile Application Security Assessment

  1. Installation file for the application : Generic / device specific
    A mobile application is usually distributed as either a jar/jad file. The application jad/jar file may be different for different mobile model/make and operating system.
  2. Emulator: Generic / device specific
    An emulator is a software application which allows a computer to run programs written for Mobile devices.

    mobile-banking-emulator.png
    Fig 1. J2ME Emulator
    You may use J2ME emulator which is generic. Many device specific emulators are also freely downloadable.

    If the jar / jad file doesn’t run on the generic emulator then it means it searches for device specifications, which are not present in generic emulators. It is then a good idea to try emulating the application on device specific emulators.

Procedure

Mobile application security assessment also follows the same step by step procedure as a normal application security assessment such as:
  1. Threat Profiling
  2. Test Planning
  3. Test execution
  4. Reporting

Categories of Applicable Tests

All the tests relevant to a thick client application can be applicable to mobile applications.
  1. Authentication checks
  2. Input Validation checks
  3. Session Management checks
  4. Encryption checks
  5. Application checks
  6. SQL injection checks
  7. LDAP injection checks
  8. XPATH injection checks
Relevant Tools
  1. Web Proxy editor / thick client proxy
    Usually the mobile applications communicate with server using SMS or GPRS.

    Special tools are required to intercept the SMS traffic which may not be freely available. Further more; sending SMS to a server via emulator is not possible as of now. Thus that may not be a viable option. It is easier to intercept GPRS traffic as GPRS uses http. Thus GPRS requests and responses can be captured in any web proxy tool.

    burp-web-proxy.png
    Fig 2. Burp Web Proxy
    In an emulator you can set the http proxy in preferences > network settings or in settings etc.

    If in the emulator there is no such option then if the manifest / .ini /.config file has the server URL, which can be replaced with http://127.0.0.1:8080[can also try web scarab as reverse proxy]

    You could also try hooking echo mirage to the emulator.exe by injecting into process. [Try using sysinternals to find the actual executable name.]
  2. Memory reader like winhex to read the executable’s memory for sensitive information such as User Id, Mpin etc.
  3. Network protocol analyzer like ethereal for sniffing packets
  4. Process monitor [for files, registry, processes]
  5. Registry key reading utility like user assist
  6. DI hell [for listing out the .dll files called by the application]
  7. Disassembler like softice
  8. Decompiler [decompiling .class files to .java files]
  9. JADmaker [converts jar file to jad file]
    JADMaker.png
    Fig 3. JADMaker
  10. IDE for JAVA development like eclipse with eclipseME plug-in

Alternative Tests

In absence of an emulated environment, it might not be possible to capture requests in proxy. Then as an alternative, architecture review and reverse engineering can be carried out.

Architecture Review

[Source: Discussion with vendor and supporting documents]
  1. Study of Network architecture.
  2. Identifying each component and its role during end to end communication.
  3. Reviewing the encryption mechanism used and its implementation.
  4. Channels used for communication.
  5. Communication packet architecture and content.
  6. Configuration of a client.
  7. Information stored locally in [.db, .ini, .config, .dll, .rms, etc] files.
  8. Read / Modify information from locally stored files.

Reverse Engineering

  1. Extract from the Jar file the constituent class files.
  2. Decompile the class files to obtain the source code.
  3. From the obtained source code remove obfuscation, if present.
  4. Study the code for hard coded sensitive information.
  5. Write/modify code to defeat the validations/encryption.
  6. Compile the modified code of the classes in to jar file.
  7. Now try to emulate the application on the computer, using new jar file.
  8. If this succeeds then make a test plan according to the captured requests.
  9. Execute the test plan.

Future Improvement

Being able to achieve the following would overcome many of the obstacles faced while testing mobile applications:
  1. Capturing SMS via a proxy tool
  2. Bypassing SMS
  3. Sending SMS to server from emulator
Subscribe to: Posts (Atom)