This topic explains how to perform penetration testing with Parasoft SOAtest.

Overview

Penetration testing is critical to uncover security holes in your application. With Parasoft SOAtest, you can efficiently take your existing API functional testing scenarios and create security tests, adding penetration testing into your automated CI process.

Creating Penetration Testing Scenarios

SOAtest supports penetration testing of REST and SOAP APIs that are accessible over HTTP or HTTPS.

Penetration testing is supported by starting with a functional test scenario that contains the APIs that need penetration testing and then configuring those scenarios for penetration testing. Existing functional test scenarios can be leveraged and turned into penetration tests, or you can create custom simplified test scenarios meant only for penetration testing.

Repurposing functional tests for use as security tests gives the following benefits:

1. Since functional tests have already been written, you can reuse work that has already been done, saving time and effort.
2. To execute certain APIs, you might have to do some setup, like prepping the database or calling other APIs. If you start with functional tests that already work, this setup is already done.

The general workflow for configuring penetration test scenarios is:  

1. Identify the test scenarios that you want to use for penetration testing and copy them. You can continue executing the original test scenarios for functional testing as normal.
2. Add the Penetration Testing Tools to the Traffic Object output of the test clients (e.g., SOAP Client, REST Client, EDI Client, or Messaging Client) that make the API calls that need penetration testing.
3. As the application changes, update only the functional test scenarios. Whenever you are ready to run the corresponding penetration test scenarios, repeat the above process of copying from the latest set of functional tests and then configuring the copy for penetration testing. 

Penetration testing requires a user license with the API Security Testing license feature enabled.

Best Practices for Creating Security Test Scenarios

• You should maintain your functional test scenarios separately from your security test scenarios, and run them from separate test jobs. The main reason for this is that adding penetration testing to existing functional tests will likely serve to destabilize the functional tests. You need to select which functional test scenarios should be turned into automated security tests, and then make copies of the functional tests that will be maintained as separate security tests.
• You need to be selective in which tests you choose since penetration testing is expensive; you need to maximize the attack surface of the API that is covered while minimizing the number of tests. You should consider the following:
  • The Penetration Testing Tool analyzes request/response traffic to understand which parameters in the request are available to be tested. You need to select functional tests that exercise all the parameters in each API, to ensure that every input to the API gets analyzed.
  • Within each scenario, you need to decide which API calls should be penetration tested. The same API may be referenced from multiple scenarios, and you don’t want to duplicate penetration testing on an API that is tested in a different scenario. The Penetration Testing Tool should only get added to the appropriate tests for the API(s) to be penetration tested.
  • The number of scenarios needs to be manageable so that the security test run is short enough to run at least once a day.
• Your functional test scenarios may have set up or teardown sections for initialization or cleanup. These typically don’t need to be penetration tested.
• If the functional test has any parameterization, you should remove it. The Penetration Testing Tool doesn't need to see multiple sets of values for the same parameters to know what to test, and sending different sets of values could just lead to making the test runs go longer due to duplicated testing.
• You should remove all assertions from any functional test scenarios that were converted into penetration test scenarios. API functional tests will usually have assertions that validate the response from the service. When used as security tests, these assertions can fail but will be noisy when reviewing the results, since in this context you only care about the security vulnerabilities that were found.
• Some API calls add data to the database. When using the Penetration Testing Tool against such APIs, the database can get bloated with information due to the number of attacks that the penetration testing tool directs at the API. In some cases, this can cause unexpected side effects, such as the performance of the application becoming so bad that the automated security test run cannot finish in a reasonable amount of time.  If you see behavior like this, exclude the security tests for that API from your automated run until the development team can fix the problem.
• You need to consider whether to run your functional and security tests within the same test environment or a different one. Resetting the environment between the functional and security test runs, or using a separate environment, promotes better test stability but is usually not necessary. You can often reuse the same environment, but when you do, you should run the functional tests first and the security tests last, since the security tests can destabilize the environment for the functional tests. When you use different environments, you need to make sure that the original functional test scenarios are configured with variables so that it is easy to point the tests at different endpoints for different environments. SOAtest supports this using environment variables. (See Configuring Testing in Different Environments.)

Executing Penetration Testing Scenarios

To run your penetration testing scenarios, execute them as described in Executing Functional Tests.

• When a REST Client or SOAP Client with an attached Penetration Testing Tool is executed, the corresponding request and response data is captured and used as a starting point by the Penetration Testing Tool to execute the penetration test.

Because penetration testing can take a long time to run, even for a single API, the Penetration Testing Tool has a built-in timeout that governs how long the tool will run before moving on to the next test. The timeout complies with the Connection Settings default timeout configured in the Misc Preferences. If the timeout is reached before the penetration testing for the current API is complete, the penetration testing for that API will be interrupted and an error will be reported. The timeout can be extended in the Misc Preferences by updating the default timeout. See Misc Settings. 

Reviewing Results

When running via UI, errors are reported to the Quality Tasks view, and details about the error and how to fix it can be seen by double-clicking on each error or right-clicking and choosing View Details.

More detailed results are available by generating an HTML version of the report. The HTML report will organize the errors by CWE, Risk, and Confidence.

For more information see Reviewing Results.

Suppressing False Positives

A number of rules used by the Penetration Testing Tool apply heuristics to analyze the AUT HTTP responses and raise alerts. For this reason, some of the reported errors may be false positive. Review each new error to decide whether it is an actionable item or a false positive (you may want to use the Confidence level of the alert to help your assessment).

To prevent the Penetration Testing Tool from reporting a false positive during subsequent runs, you can suppress the error in the in the Quality Tasks view or in the suppression file. See Suppressing Tasks for details.

To suppress an active scan rule for all tests, modify the default active scan policy. See Configuring Scan Policies.

Configuring Scan Policies

SOAtest's penetration testing uses active and passive scan rules to do its analysis. Active scan rules make additional (manipulated) requests to the API to attempt to discover security vulnerabilities.  In contrast, passive scan rules make no new requests to the application but instead analyze request/response data captured by the corresponding REST Client or SOAP Client to discover security vulnerabilities. SOAtest leverages OWASP ZAP for penetration testing. 

SOAtest contains two built-in penetration test profiles: one for REST APIs, and another for SOAP APIs. Each profile consists of an active scan policy and a set of passive scan rules. By default, a profile is chosen based on whether the configured test makes a request to a REST API or SOAP API.

If you want to use a custom active scan policy, you can do so by exporting a scan policy from OWASP ZAP and configuring SOAtest to use it. The exported scan policy will configure the set of active scan rules that will be used by the Penetration Testing Tool. When using a custom active scan policy, an appropriate set of passive scan rules will be automatically used based on whether the request is made to a REST API or SOAP API.

To configure SOAtest use a custom ZAP scan policy:

1. Select Parasoft > Test Configuration to open the Test Configuration Manager.
2. Click New to create a new Test Configuration, or select an existing one.
3. Open the Test Configuration’s Execution > Security tab.
4. Choose Use custom scan policy.
   
5. Using the Browse button select your ZAP .policy file.

Creating Custom Active Scan Policies

You can create or modify a custom active scan policy using the SOAtest embedded ZAP located in the SOAtest ZAP installation directory:

plugins\com.parasoft.ptest.libs.web_<version>\root\zap

(where version is the actual version of the com.parasoft.ptest.libs.web plugin. For example, 10.5.2.202109012000)

If you have a ZAP installation on your machine that is independent of SOAtest, you will likely have a ZAP home directory in one of the following locations:

• Windows: C:\Users\<username>\OWASP ZAP
• Linux: ~/.ZAP
• Mac: ~/Library/Application Support/ZAP

Your independent ZAP installation user settings stored in these directories may come in conflict with the SOAtest embedded ZAP when you launch it. For this reason, you should launch the SOAtest embedded ZAP with a custom ZAP home directory using the -dir command-line argument. Using a command prompt navigate to the SOAtest ZAP installation directory, and launch the SOAtest embedded ZAP with a custom ZAP home directory for example:

• Windows: zap -dir C:\Users\your_name\ZAP_SOATEST
• Linux: ./zap.sh -dir ~/.ZAP_SOATEST
• Mac: ./zap.sh -dir ~/Library/Application Support/ZAP_SOATEST

If you don’t have a ZAP installation on your machine that is independent of SOAtest, you can run the SOAtest embedded ZAP with either zap.bat (Windows) or zap.sh (Linux, Mac) scripts located in the SOAtest ZAP installation directory.

When you launch the SOAtest embedded ZAP, it may try to use a proxy port that is already taken. If so, ZAP will prompt you to select a different port:

To create a new active scan policy or edit an existing one select Analyze -> Scan Policy Manager from the ZAP top menu. In the Scan Policy Manager dialog select an existing policy or create a new one. In the Scan Policy dialog select the active scan rules you would like to apply to your custom policy:

Your custom .policy file will be saved in the policies folder of the ZAP home directory.

Inspecting/Modifying Default Active Scan Policies

You can inspect and/or modify the default active scan policies used by SOAtest. They are located in the following folder of the SOAtest installation:

plugins\com.parasoft.ptest.libs.web_version\root\zap\policies

(where version is the actual version of the com.parasoft.ptest.libs.web plugin, for example, 10.5.2.202109012000)

This folder contains the following active policy files:

• Parasoft REST.policy – used by Penetration Testing Tools attached to REST Clients.
• Parasoft SOAP.policy – used by Penetration Testing Tools attached to SOAP Clients.

Once you’ve modified either of these policies, it will be used in the next Penetration Testing Tool invocation.

Penetration Testing Rules Supported

Integration with Burp Suite

SOAtest uses a preconfigured instance of OWASP ZAP under the hood to perform penetration testing. You also have the option to use the commercial tool Burp Suite for penetration testing by leveraging the extension https://docs.parasoft.com/display/SOA20211/Burp+Suite+Extensions+1.0.