search

ietf-wg-httpapi / ratelimit-headers

Repository for IETF WG draft ratelimit-headers
Other
42 stars 4 forks source link

Security Considerations #40

Closed mfortini closed 3 years ago

mfortini commented 3 years ago

If I had my way every request and response would return rate limit headers but over time I have been asked to hide rate limit headers from certain endpoints as it is deemed a security risk to expose information that could be used to formulate attack strategies. Optimally it would be good to have a way of addressing this within the specification and I was wondering if you had any thoughts on this. Maybe that is beyond the scope of the document…

ioggstream commented 3 years ago

You are welcome to provide a PR in the Security considerations

Feel free to provide further details or ideas!

unleashed commented 3 years ago

I can offer my thought about this topic.

These fields offer hints to the user agents and intermediaries about service rate limits that do not necessarily have to have a direct relation to infrastructure capacity, although I reckon in some cases that is exactly what will be happening. My expectation is that these fields are dynamically and conservatively adjusted by the service as the load grows and once a client is limited further requests will not reach the service but instead be blocked at infrastructure load balancers and proxies, or even given a harmful behaviour there would be monitoring and automation in place to block such requests at the outer infrastructure firewall and lower network stack layers, ie. IP address.

Leaking these service limits would not be something I'd lose sleep over as long as they are not reasonably representative of your full capacity but rather representative of a reasonable use case by a user agent. DDoS attacks in which this information is shared across clients to identify the point in which you start hinting at lower effective rates would still be a potential issue, but that is already the case when you take response times into account, and I expect any DDoS protections to not be negatively affected by providing these values.

V7k3ng commented 3 years ago

This is not necessarily a case of service capacity or DDoS directly, but rather relates to rate limits providing hints to a malicious actor who may be targeting a resource by, for example, using brute force and a botnet. There could be guidance given that advertising Limit or Remaining values on certain endpoints will allow attackers to better formulate an attack. I will see about creating a PR and we can go from there.

ioggstream commented 3 years ago

Concerns about information disclosure are mentioned in security considerations here https://github.com/ietf-wg-httpapi/ratelimit-headers/blame/main/draft-ietf-httpapi-ratelimit-headers.md#L899

@V7k3ng if it is not sufficient, feel free to reopen and file a PR :)