I noticed that httpsig uses a fast noncryptographic hash function in try_parse:
pub type HttpSignatureHeadersMap = IndexMap<String, HttpSignatureHeaders, FxBuildHasher>;
But the httpsig-hyper uses IndexMap with the Rust default RandomState hasher.
I think it is fine as long as we validate and bound the number of signatures in the parsed request. The bigger problem is actually the validation of a large number of signatures in the request, which is more costly than the quadratic behaviour of a hash map on bad inputs.
A requestor could construct a request with 128 KiB header metadata (a header metadata limit in Cloudflare) with ~460 signatures, clone the request, and use it as a DOS attack amplifier.
Maybe, httpsig should set a practically large upper bound for the number of signatures in the input headers?
For a low number of signatures, it's possible to use a map, based on a linear scan, rather than hashing.
I noticed that
httpsiguses a fast noncryptographic hash function intry_parse:But the httpsig-hyper uses
IndexMapwith the Rust defaultRandomStatehasher.I think it is fine as long as we validate and bound the number of signatures in the parsed request. The bigger problem is actually the validation of a large number of signatures in the request, which is more costly than the quadratic behaviour of a hash map on bad inputs.
A requestor could construct a request with 128 KiB header metadata (a header metadata limit in Cloudflare) with ~460 signatures, clone the request, and use it as a DOS attack amplifier.
Maybe, httpsig should set a practically large upper bound for the number of signatures in the input headers?
For a low number of signatures, it's possible to use a map, based on a linear scan, rather than hashing.