You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The middleware processes the Access-Control-Request-Headers (ACRH) header of preflight requests in a rather suboptimal way. More specifically, processing a preflight request with a maliciously long ACRH header (or multiple such headers) requires a relatively long time and causes a lot of heap allocations:
$ go test -benchmem -run=^$ -bench ^BenchmarkPreflightAdversarialACRH$
oos: darwin
goarch: amd64
pkg: github.com/rs/cors
cpu: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
BenchmarkPreflightAdversarialACRH-8 9 127347568 ns/op 121176114 B/op 1053 allocs/op
PASS
ok github.com/rs/cors 3.628s
That's 127ms of execution time and a whopping 116 MiB of heap allocations to process a single 1-MiB malicious preflight request! 😬
Impact
This behaviour could be abused by attackers to produce undue load on the middleware/server as an attempt to cause a denial of service. I conducted some local tests: I created a small server configured for CORS with rs/cors and ran it in a Docker container with limited memory; concurrently sending a modest number of malicious preflight requests was enough to make the container run out of memory and die. 💀
Moreover, because CORS middleware occurs before authentication, attackers wouldn't even need to be authenticated.
Sure, most WAFs would likely drop those malicious preflight requests, but not all servers sit behind a WAF.
Solution
I have a fix ready and will submit a PR shortly.
The text was updated successfully, but these errors were encountered:
jub0bs
changed the title
Malicious/spoofed preflight requests cause prohibitive load
Some malicious/spoofed preflight requests cause prohibitive load
Apr 2, 2024
Problem
The middleware processes the
Access-Control-Request-Headers
(ACRH) header of preflight requests in a rather suboptimal way. More specifically, processing a preflight request with a maliciously long ACRH header (or multiple such headers) requires a relatively long time and causes a lot of heap allocations:$ go test -benchmem -run=^$ -bench ^BenchmarkPreflightAdversarialACRH$ oos: darwin goarch: amd64 pkg: github.com/rs/cors cpu: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz BenchmarkPreflightAdversarialACRH-8 9 127347568 ns/op 121176114 B/op 1053 allocs/op PASS ok github.com/rs/cors 3.628s
That's 127ms of execution time and a whopping 116 MiB of heap allocations to process a single 1-MiB malicious preflight request! 😬
Impact
This behaviour could be abused by attackers to produce undue load on the middleware/server as an attempt to cause a denial of service. I conducted some local tests: I created a small server configured for CORS with rs/cors and ran it in a Docker container with limited memory; concurrently sending a modest number of malicious preflight requests was enough to make the container run out of memory and die. 💀
Moreover, because CORS middleware occurs before authentication, attackers wouldn't even need to be authenticated.
Sure, most WAFs would likely drop those malicious preflight requests, but not all servers sit behind a WAF.
Solution
I have a fix ready and will submit a PR shortly.
The text was updated successfully, but these errors were encountered: