42Crunch Platform release, October 20, 2022

This 42Crunch API Security Platform release enhances user management, clarifies the audit score that API Security Audit produces, and adds several smaller improvements to API Conformance Scan.

New features

The following are the new features and improvements to the existing ones in this release.

Improvements to user management

Organization administrators can now change user roles for all types of users.

  • Single place to manage user roles.
  • The auditor role is no longer permanent, so no need to create a new user simply to change the user role.
  • Freely change between the roles as needed.

The screenshot shows the user role dropdown list in user permissions dialog.

For more details, see User roles.

Improved user experience in the audit report

For accuracy, the scores that the algorithm in Security Audit produces are often fractions, but for your convenience the audit score is shown as a rounded value. However, sometimes this can lead to confusing outcomes.

For example, if your minimum acceptable score in the audit is set to 90 points and your API scores 89.59, the visible score is rounded to 90, but the actual score remains below the threshold. This means that despite being shown 90/100, the score is not shown as a success but a failure.

To help explain this apparent discrepancy, you can now hover on the audit score to check the exact score value.

The screenshot shows an example audit score 90/100 where the exact value is in fact 89.59166666666667.

For more details, see Audit score.

Improvements in Conformance Scan

Configuring authentication for Conformance Scan can be complicated. To make it clearer that you only need to enter the actual token value, the fields for OAuth2 bearer tokens now have placeholder texts to indicate this:

The screenshot shows the field for configuring bearer token authentication with the new placeholder texts.

APIs that have not yet been scanned are no longer included in the API Conformance Scan chart in API collection dashboard, to avoid the wrong impression that scan did not find any issues in them.

We have performed some optimization on the scan report and the maximum report size has been increased to 32 MB. For more details on how to manage this when running Conformance Scan on premises, see Scan API conformance.

We have also fixed a bug where Conformance Scan did not include the Accept header in requests it sends to the scanned API, which could lead all requests failing if the backend required the header. Now, Conformance Scan correctly includes the Accept header in requests.

Clarification for CI/CD integration and security quality gates (SQGs)

We have clarified the interplay between the CI/CD integration of 42Crunch Platform and SQGs: the criteria defined in the CI/CD plugins and SQGs are two independent sets of criteria, meaning that your CI/CD build fails if either criteria are not met.

For more details, see CI/CD integrations and Security quality gates.

API Firewall allows content in non-body parameters

API Firewall now correctly accepts the content property also in non-body parameters, such as headers, and no longer fails to start on APIs that have that included in their OpenAPI definition.

Fix to for Safari in regular expressions for API and API collection naming conventions

We have now fixed the regular expressions for the patterns of API and API collection naming conventions so that they also work in Safari.

For more details, see Define a naming convention for APIs and Define a naming convention for API collections.

Compatibility

This section lists the compatible Docker images for some of the features of 42Crunch API Security Platform, as well as other possible compatibility details.

API Firewall images

This release is compatible with the following API Firewall images:

  • 42crunch/apifirewall:v1.0.21
    • Fixed content handling in non-body parameters
    • HTTP status response code synchronization with Conformance Scan default expectations.
  • 42crunch/apifirewall:v1.0.20
    • Upgrade to openssl-1.1.1o (CVE-2022-2274, CVE-2022-2097).
    • Fixed decreasing the number of active instances when firewall shuts down abruptly.
  • 42crunch/apifirewall:v1.0.19
    • Upgrade to httpd-2.4.54 (CVE-2022-26377, CVE-2022-28330, CVE-2022-28614, CVE-2022-28615, CVE-2022-29404, CVE-2022-30522, CVE-2022-30556, CVE-2022-31813).
  • 42crunch/apifirewall:v1.0.18
    • Upgrade to openssl-1.1.1o (CVE-2022-0778, CVE-2022-1292, CVE-2022-1343, CVE-2022-1434, CVE-2022-1473).
    • Proper handling of the properties readOnly and writeOnly from the OpenAPI Specification (OAS) in schemas.
  • 42crunch/apifirewall:v1.0.17
    • Upgrade to httpd 2.4.53 (CVE-2022-22719, CVE-2022-22720, CVE-2022-22721, CVE-2022-23943).
  • 42crunch/apifirewall:v1.0.16
    • Fixed parsing multipart/form-data.
    • Fixed rejecting requests that include a request body when the targeted API operation does not define a corresponding body.
    • Upgrade to expat-2.4.4 (CVE-2022-23852, CVE-2022-23990).
  • 42crunch/apifirewall:v1.0.13
    • Upgrade to httpd-2.4.52 (CVE-2021-44224, CVE-2021-44790).
    • Upgrade to openssl 1.1.1m.
    • Various small improvements.
  • 42crunch/apifirewall:v1.0.12
    • Support for x-42c-access-control-based-on-ip-range_0.1 and x-42c-set-client-ip_0.1.
    • Improved matching to allow filtering API calls by IP or network addresses.
    • Fixed setting the request path when $TARGET_URL contains a basepath.
    • Upgrade to Apache httpd 2.4.51 (CVE-2021-42013).
  • 42crunch/apifirewall:v1.0.11
    • GUARDIAN_BLOCKING_LEVEL and GUARDIAN_DEFAULT_API_BLOCKING_LEVEL environment variables.
    • Upgrade to Apache httpd 2.4.50 (CVE-2021-41524, CVE-2021-41773).
  • 42crunch/apifirewall:v1.0.10
    • Fixed cookie attribute parsing in responses.
    • Upgrade to Apache httpd 2.4.48 (CVE-2021-33193, CVE-2021-34798, CVE-2021-36160, CVE-2021-39275, CVE-2021-40438).
    • Updated platform CA chain.
  • 42crunch/apifirewall:v1.0.9-1
    • Fixed handling UTF-8 patterns in JSON schemas.
    • Upgrade to openSSL-1.1.1l (CVE-2021-3711, CVE-2021-3712).
    • Updated platform CA chain.

All previous image versions have been deprecated and are no longer supported.

When you switch the version of the API Firewall image, you must reconfigure any existing protection configurations so that they work with the new version. For more details, see Reconfigure API Protection.

Conformance Scan images

This release is compatible with the following Conformance Scan images for running it on-premises:

  • 42crunch/scand-agent:v1.22.2
    • .Accept header included in all requests.
    • Increase to scan report size.
  • 42crunch/scand-agent:v1.22.1
    • Fixed a bug in handling oneOf and anyOf.
  • 42crunch/scand-agent:v1.22.0
    • Fixed a bug in skipping response body analysis with scan rules.
  • 42crunch/scand-agent:v1.21.1
    • Fixed a bug in applying the default scan customization rule of the organization.
  • 42crunch/scand-agent:v1.20.2
    • Internal cleanup and refactoring.
  • 42crunch/scand-agent:v1.20.1
    • Percentages in the filter bar of the scan report.

All previous image versions have been deprecated and are no longer supported.

Deprecated components

There are no new deprecations in this release. For the list of current deprecations, see List of deprecated images and endpoints.

Known issues

This release has the following known issues.

Scan customization rules may lead to no response codes being accepted.

In some cases, scan rules can lead to HTTP status response codes in API responses that are normally expected (for example, HTTP 401 or HTTP 404) to be treated as unexpected. This in turn can lead to a false positive in the scan results.

By default, the expected HTTP status response codes that are defined in scan rules applied to the scanned API take preference over the response codes that Conformance Scan would otherwise expect. However, this can cause problems in scan process if your scan rule only skips header or response body analysis but does not define any expected response codes, either for happy path requests or for particular test IDs. This results in the scan rule to have null defined as the expected response code, and because the scan rule takes preference over the default scan behavior, no response codes except null are accepted. This in turn means that some tests are incorrectly flagged as returning unexpected response codes when they were in fact successful.

We are currently investigating the best way how to reconcile the designed behavior of Conformance Scan and scan rules in these cases, and this issue will be fixed in a future release.

Occasional issues with displaying some API, API collection, and collection dashboard details

There are some occasional issue with how APIs, API collections, and dashboards are displayed:

  • If you have more than one API collection and you go view an API, occasionally the API you previously viewed is shown.
  • If you go to view an API by searching, the details on the API summary tab can misappropriate the API to an API collection you viewed previously.
  • If you have very many APIs in one API collection and you go view the collection dashboard, the names of the APIs are not shown on the charts.

These issues are related merely to how the data is shown on the UI, and the underlying data in the backend is still correct. The issues do not happen consistently, and we are currently investigating them further. They will be fixed in a future release.

SQG status not updating on the API summary page

When there are changes to the SQGs applied to an API, for example, you tag the API to apply a new SQG, the SQG status on the audit report is correctly updated, but the API summary tab still shows the previous SQG status. When you rerun the audit, the status on the API summary tab is correctly updated.

In some circumstances the audit score badge shown on the API summary tab is not correctly updated to match the status of the audit SQGs passing or failing. This issue does not happen consistently, and we are currently investigating it.

These will be fixed in a future release.

Auditor can be made a team lead

Currently, organization administrators can make an auditor a team lead. As team leads, auditors can add and remove users in the team, which could affect who has access to API collections shared with the team. Note that auditors themselves never get read/write access to any APIs or API collections shared with their team.

This will be fixed in a future release.

Data dictionary duplication

Duplicating a data dictionary does not yet duplicate the values in it.

This will be fixed in a future release.

YAML conversion shown regardless of the format of API definition

Converting API format currently shows as "Convert to YAML" regardless of the format (JSON or YAML) of your API definition. However, despite the text shown, your API is correctly converted from JSON to YAML or from YAML to JSON.

This will be fixed in a future release.

Limited sharing not possible when importing APIs

Users who only have the permission to share API collections with named users and teams cannot share API collections they create when importing APIs. They can, however, share them as per usual after completing the import.

This will be fixed in a future release.

Automatic sharing with everyone not possible for new SSO users

Currently, the sharing permissions for new users onboarded to 42Crunch Platform through single sing-on (SSO) integration are automatically set to sharing only with named teams and users. If you want to allow the users to share with everyone in your organization, you must enable it in the user permissions. The permissions of existing users in your organization have been retained as they were.

This will be fixed in a future release.

Conformance Scan string limits may conflict with minLength or maxLength values

By default, Conformance Scan limits the maximum length for strings in the requests it sends during the scan to 4096. If the properties minLength or maxLength or the length limits in a regular expression that you have defined for an API operation in your API definition conflict with this limit, it causes issues during the scan.

If the minimum length required is longer than the string length limit allowed in Conformance Scan, the scan cannot create the happy path request for that operation to establish a baseline. If the maximum length allowed in the API is longer than the allowed string length limit in Conformance Scan, the scan can create the happy path request but not the actual request during the scan.

In both cases, the operation is shown as a skipped operation in the scan report, but for different reasons. You must fix the operation in your API definition before it can be successfully scanned.

Regular expression lookaheads may cause issues

If your API definition has regular expressions with either positive or negative lookaheads defined, these may cause weird behavior, for example, in Conformance Scan.