Test Mobile Applications

Learning Objectives

After completing this unit, you’ll be able to:

• Identify the differences between static application security testing and dynamic application security testing.
• Define interactive application security testing and runtime application self-protection.

Static and Dynamic Application Security Testing

As mobile applications (apps) continue to grow as an attack vector, your organization should prioritize mobile application security (appsec) to fortify its overall security posture. Adversaries employ both static attacks based on source code itself and dynamic attacks that exploit app functionality. Understanding and remediating mobile app vulnerabilities in your code is vital for your mobile appsec program.

Mobile appsec testing is the process of analyzing mobile apps to find security weaknesses, such as misconfigurations or vulnerabilities. Testing your apps regularly decreases the chance of vulnerabilities occuring or being exploited. Static application security testing (SAST) and dynamic application security testing (DAST) are the most popular evaluation techniques available to you in order to secure mobile apps during the software development lifecycle (SDLC).

Static Application Security Testing

SAST is about the prevention of defects, whereas DAST is about finding and fixing the defects. While you perform SAST testing in the early stages of the SDLC, before deploying code into production environments, you perform DAST later in the lifecycle. Static and dynamic testing complement one another, and each type has a distinct approach to detecting bugs.

You use SAST to analyze source code for known vulnerabilities as a form of white-box testing that scans and analyzes source code at rest from the inside out. SAST is programming-language dependent. You perform SAST to check the defects in software without actually executing the code of the mobile app. SAST tooling scans the source code looking for potentially vulnerable patterns and provides a list of results that then are triaged to weed out false positives. A false positive is a mislabeled security vulnerability indicating there is a threat when, in actuality, there isn't.

SAST is often referred to as verification: the evaluation of the development process. Though the most mature and easiest to deploy of the appsec testing tools, SAST scans are slow and often prone to high false-positive rates when identifying potential vulnerabilities. 

Dynamic Application Security Testing

DAST is a form of black-box testing you perform by executing the mobile app’s code. You use it to look for vulnerabilities by simulating external attacks on an application while it runs in a test environment. You use DAST to penetrate an application from the outside by checking its exposed interfaces for weaknesses. 

In DAST, you work with the actual mobile app, not some artifact or model that represents the system. You provide an input, receive output, and compare the output to the expected behavior. You use test cases for testing processes and study how the code behaves during execution. DAST is often referred to as validation: the evaluation of a finished product. You do this testing as one of the last steps before deployment in a test environment, and after code deployment. As a result, fixing problems at this stage becomes more expensive because the product is actively in use.

DAST is programming-language agnostic and is a good method for preventing regressions. However, it’s hard to automate and scale because you need experienced security professionals to tailor these test tools to specific use cases, making it more difficult to create a comprehensive testing strategy for each app. DAST also cannot pinpoint the exact source of the problem (for example, the line of code). Furthermore, it can generate a lot of false positives. 

Examples of methodologies for dynamic testing are unit, integration, system, and acceptance testing.

• Unit Testing: Testing of individual modules by developers
• Integration Testing: Testing the interface between different modules when they are joined
• System Testing: Testing performed on the system as a whole
• Acceptance Testing: Testing done from the user’s point of view

The following table summarizes the differences between SAST and DAST. 

While both tools have their advantages and disadvantages, using them in tandem—along with interactive application security testing (IAST) and runtime application self-protection (RASP)—helps strengthen your app’s security, one testing technique at a time. Let’s take a look! 

Interactive Application Security Testing and Runtime Application Self-Protection

Interactive Application Security Testing

SAST and DAST only provide a snapshot in time of a mobile app’s security weaknesses. These tools alone can’t keep up with today’s agile SDLC processes. This means that development, operations, and security teams are often one step behind as they develop, test, and transition software into production environments. To make it easier for businesses, appsec tool manufacturers realized that SAST and DAST techniques could be merged together to create better, more efficient tools that would include the advantages of both. This is how interactive application security testing (IAST) was born.

IAST analyzes code for security vulnerabilities while the app is run by an automated test, human tester, or any activity “interacting” with the app functionality. While DAST provides an outside perspective on the app before it goes live, IAST uses software instrumentation (an ability to monitor or measure the level of a product's performance and diagnose errors) to analyze running apps.

IAST techniques cover more code, produce better results, and verify a broader range of security rules faster than either SAST or DAST tools working alone. IAST solutions deploy agents and sensors in running apps and continuously analyze all app interactions initiated by manual tests, automated tests, or a combination of both, to identify vulnerabilities in real time. If a vulnerability is detected, the tester or testing team is notified.

This analysis allows developers to pinpoint the source of an identified vulnerability and fix it quickly. IAST also produces less false positives and false negatives (misidentified security vulnerabilities that claim you don’t have vulnerability when you do) than SAST and DAST, decreasing the workload on scarce security resources and making it easier to identify the most critical flaws.

IAST tools are not confined to a particular phase of the SDLC. Even though they deliver a lot of value during the development phase, because they help developers fix risks in real time, IAST tools are incredibly useful during the testing phase as well. They’re also valuable when the system is in production, because operations and appsec teams can benefit from the risk detection, with little performance hit and little risk of false positives. While IAST tools can provide good benefits, they also are more complex to implement correctly and require mature security development practices and comprehensive build integration in order to recognize their benefits.

Runtime Application Self-Protection

While IAST monitors an app for security vulnerabilities while it’s running, runtime application self-protection (RASP) monitors an app to detect and prevent fraudulent activities even before it runs, effectively protecting the app from both known and unknown (zero-day) attack vectors. You can use RASP to gain insight into an app's internal data and state, and identify threats at runtime that may have otherwise been overlooked by other security solutions. When an app begins to run, RASP can protect it from malicious input or behavior by analyzing both the app's behavior and the context of that behavior.

One advantage of RASP is that it requires minimal intervention of an administrator during deployment. When a security event in an app occurs, RASP takes control of the app and addresses the problem. In diagnostic mode, RASP will simply sound an alarm that something is amiss. In protection mode, it will try to stop it. For this reason, RASP can be beneficial to businesses with lean security resources because it can automatically block attacks on the spot without the need for human intervention. It’s important to first implement RASP in diagnostic mode, to observe how the tool makes decisions, before implementing protection mode.

You likely use other technologies such as intrusion prevention systems (IPS) and web application firewalls (WAF) to protect your apps at runtime, but these technologies work in-line as they inspect network traffic and content. Although they analyze traffic and user sessions to and from apps, they cannot see how traffic and data are being processed within apps themselves. Additionally, instead of analyzing preset signatures or known patterns based on commonly known attacks, as a WAF would, you can use RASP to look for suspicious actions taking place in the app. 

Sum It Up

You now have a better understanding of how to use SAST, DAST, IAST, and RASP to test and secure your mobile apps.

Next, let’s turn to how to use network and mobile app penetration testing (pen testing) to further secure them.

Resources

• Trailhead: Secure Development Lifecycle
• Trailhead: Responsibilities of a Penetration Tester
• PDF: National Institute of Standards and Technology (NIST): Guidelines on Minimum Standards for Developer Verification of Software
• External Site: Microsoft: Tracing and Instrumenting Applications
• External Site: Gartner: Runtime Application Self-protection (RASP)