Comment 28 for bug 1098307
Revision history for this message
| Adam Young (ayoung) wrote Re: unauthenticated POST to /tokens can fill up disk/logs | #28 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
The attack listed above has a couple assumptions:
1. The attack is against an URL that will process unauthenticated requests
2. Limiting the size of values that are sent to the database will prevent them from being logged upon failure.
This patch was just approved for master
https:/
It does the overall size limiting of the request header. It defends against the attack above and a wider array of attacks: any place where overflowing a field can cause an error.
That patch should be backported to Folsom and Essex as it defends against a wider range of attacks.
The above patch has a few issues with it.
The max values are coded in python. They should be config file values, so they can be tuned in a deployment.
It limits the size of the tokens, which is probably OK, but could be an issue for very large tokens in a limited usage scenario. I would suggest instead that we limit the size of the value that is sent to the backend for looking up a token instead. This number can be much smaller: the length of a UUID/SHA1 hash, and can likely be MAX_PARAM_SIZE, not 8K.
My recommendation is that we focus on getting review 19567 backported, and then apply the above patches as good programming practices, but not as a response to a CVE.