42Crunch Platform release, November 9, 2020

This 42Crunch Platform release brings improvements and fixes to API Security Audit, API Conformance Scan, and API Firewall.

New features

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

Improvements across the platform

  • Better performance when loading of user and API information.
  • The horizontal limit of OpenAPI definitions (how many properties (keys) an object may have, or how many items an array can contain) has been increased to 300.

Improvements to Security Audit

More information on how Security Audit calculates audit score when it finds more than one security risk in the same API operation. For more details, see Multiple security risks in a single security requirement.

Improvements to Conformance Scan

  • Error handling when the minimum defined for an integer is greater than its set maximum.
  • Limits on minLength for strings and minItems for arrays to avoid high memory consumption.
  • Issue in pattern generation fixed.
  • Issue where the scan was not able to generate requests with any parameters that were not defined as required fixed.
  • The test for maxLength now uses maxLength+1, not maxLength.
  • Issues in generating a request using minimum and maximum for floats and int64 fixed.

Improvements to API Firewall

You can now use the API-specific variables LOG_LEVEL and ERROR_LOG_LEVEL to define the granularity you want for the logs that API Firewall produces. In addition, more log levels are now supported.

For more details, see API-specific API Firewall variables.

Compatibility

This release is compatible with the following API Firewall images:

  • 42crunch/apifirewall:v0.17.15
    • PCRE regex engine
  • 42crunch/apifirewall:v0.17.16
    • Non-TLS configuration allowed with LISTEN_NO_TLS=1
  • 42crunch/apifirewall:v0.17.17
    • Expression functions for date manipulation added
  • 42crunch/apifirewall:v0.17.20
    • Fixed issues:
      • Assertion cache deserialization
      • Possible crash with large uploads
      • Possible crash with mixed Content-Length/Transfer-Encoding uploads
    • Improvements:
      • Deserialization of the parameters from the OpenAPI definition
      • JSON path implementation
      • Configuring all log levels through LOG_LEVEL and ERROR_LOG_LEVEL environment variables
  • 42crunch/apifirewall:v0.17.21
    • Some errors in the transaction log formats fixed, so that they show up in the UI
  • 42crunch/apifirewall:v0.17.22
    • Upgrade to openssl-1.1.1i (CVE-2020-1971)
    • Upgrade to musl-1.1.24-r3 (CVE-2020-28928)

      Previous API Firewall versions (v0.17.21 and earlier) are not affected by these CVEs, because the firewall does not use the affected functions. However, some image scanners may detect the presence of vulnerable openssl and musl versions, so to avoid confusion, we have updated the affected libraries.

All previous image versions have been deprecated and are not compatible with this version of the platform.

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.

Known issues

This release has the following known issues.

Security Audit does not verify the format of vendor extensions

At the moment, Security Audit does not verify that you have used the correct format for vendor extensions to the OpenAPI Specification (OAS). According to the OAS, the field names of vendor extensions must begin with x-. However, Security Audit does not flag it as an error if the field name is missing the x-.

This will be fixed in a future release.

Security Audit does not check for missing HTTP status code 406

At the moment, Security Audit does not raise an issue if you have not defined a response for the HTTP status code 406. A HTTP 406 response is required for all PUT and POST operations and all operations that take a body.

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.

We are working to improve this in the future.