Mobile Application Assessment

What is it?

Mobile testing will examine and identify security vulnerabilities in mobile applications built for smart phones or tablets. The assessment encompasses the complete mobile application and any server-side APIs the application uses. It is also recommended that the application’s source code is provided as this improves both the quality of findings and any recommendations.

Approach

The first attack phase consists of manual testing using a range of tools and techniques. The tools used include network monitoring, man-in-the-middle proxies, and reverse engineering tools. The precise tests that are performed will vary depending on the nature of the application. Typically, these will include:

• Analysis of data stored on the mobile device
• Analysis of transport layer security
• Analysis of the use of cryptography within the application
• Analysis of any binary protections that may be in place
• Validation of authentication and session management
• Source code review
• OWASP Top Ten Mobile Risks

The second attack phase consists of manual and automated testing of the server-side end point of a client-server mobile application. The tools used include network scanners, automated testing tools, and man-in-the-middle proxies.

The testing will look for flaws of various types including:

• Input manipulation flaws such as SQL injection, Xpath injection and path manipulation
• Flaws in authentication and authorisation
• Business logic flaws
• Session management errors

What is the output from this assessment?

A full technical report will include the following:

• Executive Summary – explanation of the vulnerabilities encountered, the risk they pose to your organisation, whether the objective was completed and recommendations of any remedial action that should be taken
• Summary of Findings – a table of all vulnerabilities noted during the assessment, the vulnerability title, its risk rating, and the vulnerability’s current state
• Detailed Findings:
  • The vulnerability’s risk rating
  • The system, URL or process that contains the vulnerability
  • How the vulnerability was exploited
  • The risk posed to the organisation
  • Full technical details of how to replicate the vulnerability
  • Remediation advice
• Appendices – vulnerability output that was noted in the engagement

When evaluating the overall risk rating for each vulnerability, the following factors will be considered:

• Impact – the impact that exploitation of this vulnerability will have on the business or organisation
• Risk – the risk posed to the organisation if this vulnerability was exploited
• Likelihood – the likelihood that this vulnerability could be exploited

Each vulnerability will have a remediation recommendation, which will include either:

• Official fix, such as a firmware upgrade for hardware, or a patch for a publicly disclosed vulnerability
• When there is no official fix a workaround can be used
• Process improvement for when exploitation of a vulnerability is caused by a business process