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 andminItems
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 usesmaxLength+1
, notmaxLength
. - Issues in generating a request using
minimum
andmaximum
for floats andint64
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
- Non-TLS configuration allowed with
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
andERROR_LOG_LEVEL
environment variables
- Fixed issues:
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
andmusl
versions, so to avoid confusion, we have updated the affected libraries.
- Upgrade to
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.