GHSA-52cf-226f-rhr6: Default CORS config allows any origin with credentials
ImpactOrigin reflection attackThe default CORS configuration is vulnerable to an origin reflection attack.  Take the following http4s app `app`, using the default CORS config, running at https://vulnerable.example.com:The following request is made to our server:When the `anyOrigin` flag of `CORSConfig` is `true`, as is the case in the default argument to `CORS`, the middleware will allow sharing its resource regardless of the `allowedOrigins` setting.  Paired with the default `allowCredentials`, the server approves sharing responses that may have required credentials for sensitive information with any origin:A malicious script running on `https://adversary.example.org/` can then exfiltrate sensitive information with the user's credentials to `vulnerable.exmaple.org`:Null origin attackThe middleware is also susceptible to a Null Origin Attack.  A user agent may send `Origin: null` when a request is made from a sandboxed iframe.  The CORS-wrapped http4s app will respond with `Access-Control-Allow-Origin: null`, permitting a similar exfiltration of secrets to the above.PatchesThe problem is fixed in 0.21.27, 0.22.3, 0.23.2, and 1.0.0-M25.  The original `CORS` implementation and `CORSConfig` are deprecated.  In addition to the origin vulnerability, the following deficiencies in the deprecated version are fixed in the new signatures:MigrationThe `CORS` object exposes a default `CORSPolicy` via `CORS.policy`.  This can be configured with various `with*` methods, like any http4s builder.  Finally, the `CORSPolicy` may be applied to any `Http`, like any other http4s middleware:WorkaroundsIt is possible to be safe in unpatched versions, but note the following defects exist:The `anyMethod` flag, enabled by default, accepts methods that cannot be enumerated in the `Access-Control-Allow-Methods` preflight response.Rejected CORS requests receive a `403` response, when the client should be the enforcement point. The server should just omit all CORS response headers.Does not send `Vary: Access-Control-Request-Headers` on preflight requests. This may confuse caches.Does not validate the `Access-Control-Request-Headers` of a preflight request. This validation is not mandated by the Fetch standard, but is typical of most server implementations.Needlessly sends `Vary: Access-Control-Request-Method` on non-preflight requests.  This should be harmless in practice.Needlessly sends `Access-Control-Max-Age` header on non-preflight requests.  This should be harmless in practice.Sends an invalid `Access-Control-Allow-Credentials: false` instead of omitting the header.  This should be harmless in practice.Explicit originsIn versions before the patch, set `anyOrigin` to `false`, and then specifically include trusted origins in `allowedOrigins`.0.21.x0.22.x, 0.23.x, 1.xDisable credentialsAlternatively, sharing responses tainted by credentials can be deprecated.0.21.x0.22.x, 0.23.x, 1.xReferencesThe [MDN guide to CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)[PayloadsAllTheThings CORS misconfiguration](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/6cba7ceda93c3f64559c3e73881c21076536e5fb/CORS%20Misconfiguration/README.md)For more informationIf you have any questions or comments about this advisory:Open an issue in [GitHub](http://github.com/http4s/http4s)Contact us via the [http4s security policy](https://github.com/http4s/http4s/security/policy)
CVSS v3.1: 9.1