Application Testing


Prevent application security breaches

UL strives to limit the presence of vulnerabilities and weaknesses in application software. UL application testing identifies vulnerabilities and demonstrates how an attacker may gain access to information stored in applications.

UL has expertise performing testing on a wide variety of applications, including web and mobile applications

Web Applications

The majority of security breaches is caused by vulnerabilities in web applications. Web applications form a popular target by attackers. A majority of web application vulnerabilities are known, and have published CVEs, yet are exploited.

Mobile Applications

For mobile applications, customer experience and flexibility is key. Yet, security presents its own challenges. Today’s mobile security risks are dominated by different types of intrusive and malicious mobile applications, which present a different threat compared to more traditional computer viruses.

Step 1: Scoping

The starting point for the application testing is a kickoff meeting to scope the work. This is the most important scoping step, for planning and preparing the testing effort. The scoping will determine the security control areas UL will focus on. Metrics for timing and duration of the testing are also agreed.

Some examples of questions asked are the following:

    • Is authenticated or unauthenticated testing required?
    • Are there any devices (firewall, IPS, WAF, etc.) in place that may impact the results of an application test?
    • If the application resides on an internal network, what method will be used to access them (UL employee on-site, physical appliance, or VM provided by the customer)?
    • Will the testers have access to the QA testing procedures of the application(s) in scope?
    • Is the application file (.apk, .ipa, etc.) available?

Step 2: Information Gathering

UL will examine the application with the aim of getting familiar and understandings it context, functionality, and architecture at a high level.

Examples of activities are:

    • Conduct application architectural analysis
    • Assess application runtime environment
    • Map application reliant backend services
    • Identify application entry points
    • Conduct discovery and reconnaissance for information leakage
    • Review metafiles for information leakage
    • Map execution paths through the application
    • Fingerprint application framework

The results from these activities are collected and used to map the current application access points and technologies and define a plan to execute on the security control areas in scope.

Step 3: Vulnerability Detection & Exploitation

In this step, UL experts will discover the application vulnerabilities. There are two phases; automated and manual. In the first phase UL experts will use automated tools to perform the scanning on the target systems. In the second phase a manual validation process is carried out, depending on the security control areas in scope. The outcome of the scanning is a report with the list of the application vulnerabilities ranked by priority. This result is the input for the next step.

Knowing that a vulnerability exists on a target does not always imply that it can be properly exploited. This can be due to particular configurations, protections in place, or practicality of exploitation. During the exploitation step, UL experts will try to exploit existing vulnerabilities using different tools and methods depending on the context.

Depending on the scope and the type of testing the organization wants to have, UL experts can approach the attempts in three different ways such as black box, grey box, or white box. The explanation for each approach is given below.

‘Black box’ means that our testers don’t have any knowledge about your application except publicly known information. An example of this would be a penetration test for a website, where only the website URL or IP-address is supplied to the testing team. This would equate to an external attack carried out by a malicious hacker.

‘Grey box’ means that UL would be supplied with limited information, to be able to build a threat model, based on application design methodology, open source packages and libraries used, and access to developers, community forums, but not source code.

‘White box’ means that UL has complete knowledge of the application’s architecture and source code, and performs a complete code review, using static (SAST) and dynamic (DAST) application security testing methodologies.

Step 4: Report & Advice

During the analysis step UL experts will look at the findings and provide a detailed report describing the successful penetration attempts; as well as the mitigation plan for each case.

The report will describe the application areas in scope, the test tools and test methods used, the vulnerabilities and weaknesses found, and the penetration attempts performed.

For each successful penetration attempt, we will list the related vulnerabilities, the attack method, all logs and data related to the attempt and any other information necessary to reproduce the attempt.

We will give a brief analysis of the likelihood and impact of each successful exploit, and include recommendations on mitigating the vulnerabilities we found.