42Crunch Platform release, January 10, 2023

This 42Crunch API Security Platform release introduces improvements to managing authentication checks in API Security Audit as well as the security quality gate (SQG) approval reports from audits, and defining additional settings for API Conformance Scan.

New features

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

Improvements to managing authentication checks in Security Audit

We have improved how you can relax authentication checks in Security Audit in APIs and API operations that do not need authentication.

  • Use customization rules to apply the new, recommended vendor extension x-42c-accept-empty-security to APIs where some or all operations do not need authentication.

    • Security Audit interprets the explicitly empty security requirements (security: []) as indication that authentication is not required, not as errors (the extension x-42c-accept-empty-security). Security checks are always performed on new endpoints where empty security objects have not been explicitly defined. This is the recommended option.
    • If needed, you can still choose to ignore all authentication checks (the extension x-42c-no-authentication) to completely switch them off in Security Audit. This means that security checks are not performed regardless of security objects and the quality of your security measures not evaluated at all (not recommended).

For more details on these extensions and their differences, see x-42c-accept-empty-security and x-42c-no-authentication.

New checks to Security Audit

To prevent conflicting directives for how to handle authentication checks in an audit, we have also added new checks (validation-x-42c-extensions-conflict and v3-validation-x-42c-extensions-conflict) in Security Audit.

If an API has both extensions applied to it, either from audit rules or directly in the OpenAPI definition, this is raised and the API treated as if the API definition was not a valid OpenAPI definition, to prevent inaccurate results from security analysis.

For more details, see:

Improvements SQG approval reports from Security Audit

We have improved how the approval reports from audit SQGs are shown.

  • Clearly see which criteria your API failed, so you know where to focus your fixes for the API to pass.

    The screenshot shows a SGQ approval report for the Petstore API that has failed the audit criteria set in the default SQG: the audit score of the API is only 45/100 and is highlighted in red, because the SQG requires at least 70/100.

  • Filter the audit report to show only the to-do list of issues that you must fix because they prevent your API from passing the SQG.

For more details, see Security quality gates. These improvements are also coming to scan SQGs in a future release.

Improvements to Conformance Scan

We have added more options to control how Conformance Scan handles redirects (HTTP 3XX) it receives in responses when scanning an API.

  • By default, scan does not follow redirects to the final response, but analyzes the received redirect. This is the most secure approach and also allows the scan to complete even if the format of the final response was unsuitable.
  • You can set the scan to follow redirects and analyze the final response, but this may increase the risk of the scan not completing because of an error and is not recommended.

In addition, you can now also change some scan settings when running scan in 42Crunch Platform. However, in most cases the default settings are adequate and this is not needed. For more details, see Scan API conformance.

Improvements to sharing API collections

There is now added granularity when sharing API collections to teams: different users in the same team can now be given different access levels to the collection.

The screenshot shows the sharing of an API collection. The collection has been shared with one team and two individual users, with different access levels. The team has been granted read-only rights, except one team member who can also edit APIs in the collection.

In addition, organizations administrators and auditors can now export the sharing details of an API collection for review.

For more details on sharing collections and APIs, see Sharing APIs and access level.

IDE tokens

We have introduced dedicated IDE tokens for deeper integration between IDE extensions and 42Crunch Platform, such as viewing API collections directly in IDEs.

  • Quickly create a token a single click on the platform landing page: all actions that the IDE extensions require to work are automatically included in the token scopes.

    Screenshot of the available integrations on the platform home page

  • For increased security, IDE tokens expire after three months, but you can also choose a different expiration time when creating tokens in your account settings.

For more details, see IDE tokens.

IDE tokens do not yet replace the tokens that you need to register for when you first run Security Audit in your IDE, and these tokens do not expire like IDE tokens.

In addition, viewing API collections is now also supported in Eclipse IDE.

Other updates

There have also been other, smaller updates, for example, to improve the UX:

  • The settings menu has been reorganized to make it easier to navigate, and you can also collapse the sections you do not need.

    A screenshot showing the Users tab from the organization settings.

  • In SSO integration, it is now possible to allow all new users to share API collections with everyone in the organization. If your organization has already integrated SSO to 42Crunch Platform and would like to take advantage of this, contact our support.
  • For the free Community organization, some wordings in our Terms & Conditions have been updated, however, there have been no material changes to them.

Changed behavior

  • We have updated the severity levels in authentication checks in Security Audit, which depending on your APIs may lead to changes in their audit score. For example:
    • The severity levels of some authentication checks for OpenAPI Specification (OAS) v3 has been raised to align with the severity of checks for the OAS v2. Depending on your API, this may decrease the audit score. The following issue IDs are affected:
      • v3-global-securityrequirement-apikey-incookie
      • v3-global-securityrequirement-apikey-inheader
      • v3-global-securityrequirement-apikey-inquery
      • v3-global-securityrequirement-http-basic
      • v3-global-securityrequirement-http-digest
      • v3-global-securityrequirement-http-negotiate
      • v3-global-securityrequirement-http-oauth1
      • v3-global-securityrequirement-http-unknown
      • v3-operation-securityrequirement-apikey-incookie
      • v3-operation-securityrequirement-apikey-inheader
      • v3-operation-securityrequirement-apikey-inquery
      • v3-operation-securityrequirement-http-basic
      • v3-operation-securityrequirement-http-digest
      • v3-operation-securityrequirement-http-negotiate
      • v3-operation-securityrequirement-http-oauth1
      • v3-operation-securityrequirement-http-unknown
    • The new checks validation-x-42c-extensions-conflict and v3-validation-x-42c-extensions-conflict consider the API definition as not being a valid OpenAPI definition if a conflict is found. In this case, the API would not get a audit score until the conflict has been resolved.
  • x-42c-no-authentication now completely switches off authentication checks and so hides any security issues from the audit report. We recommend switching to use x-42c-accept-empty-security instead. For more details, see Extensions for Security Audit.
  • By default, Conformance Scan no longer tries to follow redirects in API responses to analyze the final response, but analyzes the received redirect response instead. Depending on your API, you might see an increase in conformance failures in received API responses. For more details, see Response validation.
  • Based on feedback, we have continued to simplify the format entries in data dictionaries and have removed the types integer and number, as these do not have a pattern and are therefore easily managed directly in the API definition itself. For more details, see Data dictionaries.
  • IDE extensions are moving to use IDE tokens instead of API tokens, and API tokens will be phased out from the free Community organization in a future release.

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.3
    • Improved handling of redirects (HTTP 3XX) in API responses.
  • 42crunch/scand-agent:v1.22.2
    • Accept header included in all requests.
    • Increase to maximum 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 or scan report 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.

The scan SQG status on the scan report page might not always reflect the latest changes in SQG: if the SQG was updated after the scan was last run, the status (pass/fail) might be outdated until the scan report page is refreshed.

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.

When sharing API collections, the UI shows that an auditor could be given the right to edit the collection. However, auditors never get read/write access to any APIs or API collections shared with their team and cannot edit any APIs when they log in, regardless of the permission shown in sharing.

These 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.

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.