42Crunch Platform release, October 10, 2023

This 42Crunch API Security Platform release brings several enhancements and fixes requested by our customers, as well as further improvements to API Conformance Scan.

New features

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

Improvements to Conformance Scan

There have been several improvement to Conformance Scan, both to Scan v1 and Scan v2.

For both scan versions, we have clarified the scan status: scans where all API operations could not be scanned — for example, because of failed happy path tests — are now highlighted as incomplete to emphasize that the achieved results are not yet definitive and more work on the API is required. This acts as a safeguard for unpleasant surprises: if an API operation cannot be scanned, you cannot be sure that the API implementation for that part works as intended and does not pose a security risk.

We have also improved the support for read-only properties, so that these properties no longer are included in the generated requests.

In addition, the logs Conformance Scan produces when run on premises can again be viewed in 42Crunch Platform, see Scan logs.

Improvements to Scan v1

  • We have simplified the wizard for creating a scan configuration and running the scan so that the configuration flow is now the same regardless of if the scan will be run on the platform or on premises.
  • We have added a setting in the scan configuration to switch off the GET / request to check connectivity to API in case your API implementation does not support such a request. See Settings for Scan v1.
  • We have improved how Conformance Scan handles Content-Type that it does not support:
    • The handling of the Accept header when API response has unsupported Content-Type has been fixed.
    • The scan now skips scanning all API endpoints that have unsupported Content-Type. In this case, if all happy path tests have passed and the scan finishes successfully, the scan is considered to be complete even if API endpoints have been skipped because of the Content-Type, including in security quality gates (SQGs)

    You must update your scan configuration before these changes take effect.

  • We have also fixed a bug on how the angle brackets (<>) are encoded in the cURL request.

Improvements to Scan v2

  • We have added more information about scan scenarios and scan variables in the documentation, see Scan token.
  • The scan configuration validation report (SCVR) is now provided for all scan configurations, not only if a configuration has errors, and it now provides statistics, for example, on the coverage of your API that a particular scan configuration provides. See Scan configuration validation report (SCVR).
  • The web editor now warns you on unsaved changes if you try to navigate elsewhere without saving the scan configuration.
  • Scan configurations now support dynamic variables that do not require a schema to provide the details for what kind of value to generate, see Dynamic variables when there is no schema.
  • Conformance Scan now omits running tests for methods that the API endpoints do not allow if a global before block in the scan configuration fails, or the scan configuration is defined to run only happy path tests, not conformance tests.
  • SQG status is now again shown when viewing the scan report.

Separate access levels for editing and deleting APIs in an API collection

We have added more granularity to access levels that you can grant to other users when sharing API collections and APIs:

  • The existing READ/WRITE access has been renamed to READ/WRITE/DELETE to better reflect the actions it allows on APIs.
  • A new access for solely READ/WRITE has been added so that you can now share API collections for collaboration but prevent other users from deleting your APIs.

The existing access level has been retained, so if you had shared API collections with READ/WRITE access, these user will now have READ/WRITE/DELETE access. If you want to prevent other users from deleting APIs from your API collection, you must update the sharing permissions of the collection and change READ/WRITE/DELETE to READ/WRITE.

For more details, see Sharing APIs and access level.

Updates to pagination for improved performance

Previously, if your organization had many API collections, you might have to wait a long time for the list of collections to load on the UI before you could start working with them. We have now improved pagination here, so that the UI can load the API collections faster and you can get to your APIs quicker.

Platform audit logs

We have introduced a new feature for organization administrators: platform audit logs. Platform audit logs document the activity across your organization in 42Crunch Platform, and provide details such as:

  • What happened?
  • When?
  • Who (user or automation) performed the action?
  • What was the target of the action?

Platform audit logs are a diagnostic tool, not a detection tool. They allow you to dive into past activity, for example, to troubleshoot an issue, but they are not real-time and will not replace your existing detection tools.

This first iteration of the feature is a preview, and we will continue to improve on it in future releases.

For more details, see Platform audit logs.

New customization for API Security Audit

You can now create an audit rule to prevent Security Audit from providing audit score for APIs that have semantic issues. This highlights the fact that semantic issues still mean your API definition is not a valid OpenAPI definition and that more work on it is required.

In addition, you can now quickly reset default customization rules back to their original state, for example, if you notice that the customizations you have added to them do not really work for you and you want to start again. The default customization rules also no longer can expire.

For more details, see Customizations.

Enhancements to managing API Firewall logs

You can now delete API Firewall transaction logs that you no longer need from 42Crunch Platform. This allows you to ensure that no sensitive data — such as personally identifiable information (PII) subject to GDPR requirements — is stored when it is no longer needed, for example, after you have completed testing API Firewall for your API.

For more details, see Delete transaction logs.

Storing transaction logs from API Firewall in 42Crunch Platform is not suitable for firewall instances running in production environment due to the volume of logs produced. We recommend changing the log destination away from 42Crunch Platform in production or for performance testing. For more details, see Switch log destination for API Firewall logs.

Fixed YAML conversion

Converting the API format on the list of APIs in an API collection now again correctly reflects the format (JSON or YAML) that your API definition is currently saved as.

Compatibility

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

We recommend that you update to the latest compatible versions as soon as possible to take the full advantage of the new features and security improvements.

API Firewall images

This release is compatible with the following API Firewall images:

  • 42crunch/apifirewall:v1.0.25
    • Upgrade to go-1.21.1 (CVE-2023-39319, CVE-2023-39318, CVE-2023-3978, CVE-2023-29409)
    • Upgrade to openssl-1.1.1w (CVE-2023-4807, CVE-2023-3817, CVE-2023-3446)
  • 42crunch/apifirewall:v1.0.24
    • Upgrade to httpd-2.4.57 (CVE-2023-25690, CVE-2023-27522)
    • Upgrade to openssl-1.1.1u (CVE-2023-2650, CVE-2023-0465, CVE-2023-0466, CVE-2023-0464)
    • Support for multiple API key security schemes with the same name
    • Fixed the handling of content media-typedeclared as opaque string in response validation
    • Fixed request body handling when API Firewall is set to non-blocking mode.
    • Obfuscated headers (except Host) in transaction logs when the targeted API is unknown
    • New versions of JWT validation protections (x-42c-jwt-validation-ec_0.2, x-42c-jwt-validation-rsa_0.2, x-42c-jwt-validation-hmac_0.2)
      • Validating the scope claim of OAuth2 JWT tokens
      • Connecting to the JWKS server through a remote forward proxy
  • 42crunch/apifirewall:v1.0.23
    • Health check over SSL
    • The environment variable PLATFORM_HOST
    • Fixed the handling of multipart/form-data requests
    • Upgrade to openssl-1.1.1t
    • Upgrade to httpd-2.5.55
    • Upgrade to apr-util-1.6.3
  • 42crunch/apifirewall:v1.0.22
    • Fixed JWT signature validation
    • Allowed plain string content definition
    • Upgrade to openssl-1.1.1s
    • Upgrade to libexpat 2.5.0
    • Upgrade to libapreq 2.17
    • Upgrade to libjansson 2.14
    • Upgrade to libjose 11
    • Upgrade to libmaxminddb 1.7.1
  • 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

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. All previous image versions have been deprecated and are no longer supported.

Scan v1

  • 42crunch/scand-agent:v1.22.12
    • Support for text/plain as content type
    • Support for read-only properties
  • 42crunch/scand-agent:v1.22.11
    • Upgrade to Golang 1.20.7 (CVE-2023-39319, CVE-2023-39318, CVE-2023-3978, CVE-2023-29409)
    • Fixed handling of < and > characters in the request payload
    • Improved handling of content not supported by Conformance Scan
  • 42crunch/scand-agent:v1.22.9
    • Performance improvements to scan configuration generation
    • Better memory handling when generating array items of the type file for scan requests
    • Better handling of expired customization rules
    • Improved JSON schema validation for UTF-8 strings
  • 42crunch/scand-agent:v1.22.8
    • Upgrade to Golang 1.20.4 (CVE-2022-41716, CVE-2022-41717, CVE-2022-41720, CVE-2022-41722, CVE-2022-41723, CVE-2022-41724, CVE-2022-41725, CVE-2023-24532, CVE-2023-24534, CVE-2023-24536, CVE-2023-24537, CVE-2023-24538, CVE-2023-24539, CVE-2023-24540, CVE-2023-29400)
  • 42crunch/scand-agent:v1.22.7
    • Updates to regular expression library
  • 42crunch/scand-agent:v1.22.6
    • Fixed regular expressions handling

      In some rare cases, certain regular expression patterns could send the on-premises scan to an infinite loop, and the process would not finish. This image version fixes that, so if you are experiencing on-premises scan hanging, we recommend upgrading from the previous scan images to this one.

  • 42crunch/scand-agent:v1.22.4
    • Improved array iteration

Scan v2

  • 42crunch/scand-agent:v2.0.2
    • Support for text/plain as content type
    • Support for read-only properties
  • 42crunch/scand-agent:v2.0.1
    • Upgrade to Golang 1.20.7 (CVE-2023-39319, CVE-2023-39318, CVE-2023-3978, CVE-2023-29409)
    • Enhancements to generating random values from scan configuration
    • Tests for not allowed methods are omitted if a before block on a global level in the scan configuration is failing, or the scan configuration is set to run happy path tests only
  • 42crunch/scand-agent:v2.0.0
    • The new version of Conformance Scan

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.

The READ/WRITE/DELETE access not shown in API collection list

Both READ/WRITE/DELETE and READ/WRITE are currently shown as READ/WRITE outside the sharing details of an API collection, such as on the list of API collections. However, the accesses are correctly shown when viewing and editing the sharing details.

This will be fixed in a future release.

Manage teams permission not shown on list of users

The permission to manage teams is not yet shown on the list of users in your organization, but you can view all permissions that a user has by clicking the permission column. This permission also does not yet have a shortcut that you could use when searching by permission.

These will be fixed in a future release.

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.

Data dictionary duplication

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

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.