TLDR: string parsing is hard and most of us are vulnerable to assumptions and/or never get around to do those fuzzy tests properly when checking that input is handled correctly.
TLDR: string parsing is hard and most of us are vulnerable to assumptions and/or never get around to do those fuzzy tests properly when checking that input is handled correctly.
A lot of these are on the pattern of normalising input as late as possible, which is an odd choice for a security product.
I'd argue it's odd that they (or LDAP) normalise input in the first place. I can sort-of understand username normalization to avoid having both "admin" and "Admin" accounts, but that check only needs to be done when creating an account, when logging in it should not accept "Admin" as valid for account "admin".
But I'm neither a security person nor have I done much with authentication since my 2000's PHP hobbying. I suspect an LDAP server has to deal with or try and manage a lot of garbage input because of the sheer number of integrations they often have.
Security products are just products like everything else. They're not written differently than normal infrastructure products.
It’s enterprise product, a ton of money can be made by trying to parse complete garbage being tossed at you and delivering it.
I mean… it's hashicorp… did you expect sanity?
One of the vault backends has a size limit and so secret keys larger than 2048 bits would not fit. Amazing tool.
I don't see any parsing going on here. They failed to normalize the input values the way that the LDAP server does before applying rate limiting resulting in an effectively higher than expected login attempt rate limit.