HN user
Hah. They could still improve it by only accepting a single algorithm, rather than a list.
edit: though there could be some internal use cases where you want a list, but it's a tradeoff between flexibility and making it easy for people to shoot themselves in the foot.
Various, been a while since I wrote code using them myself.
Often JWT tokens come from sources other than our own and they will have passed through user agent or client land. Don't trust anything in them unless you verified them.
edit: good on that library! That's what it should do. Clearly auth0's code did not do that though, it should never have accepted any variant of 'none' in the first place.
I've encountered issues like this in various systems using JWT at this point. The real problem is that developers blacklist the algorithms they don't want. Instead, the verification code should explicitly whitelist which algorithms you support.
More specifically, you can't even rely on using the 'alg' parameter before successful signature verification with any level of authority: after all, it is protected by the signature it declares the algorithm for itself. So even with a whitelist, there is the potential of downgrade attacks.
In other words, don't even use a whitelist, use a single specific expected algorithm.
Pretty much the case every single time. It's how cycling infrastructure finally got taken seriously in the Netherlands too - https://www.youtube.com/watch?v=XuBdf9jYj7o
I last tried the bootcamp/vmware setup with a Vista partition; it really confused the activation system and kept de-activating.
Don't trust the data before you verified it is indeed the common problem here. You have to be careful with JWK in a similar way: the public key can be specified a as a URL via the x5u parameter, you have to make sure you only trust keys from a whitelisted URL otherwise whoever supplies the token signed with a JWK can just provide their own public key and self-sign it.
This can be problematic and need some leg-work on a developer's side when the URLs to be whitelisted aren't documented. For example Apple use a similar signed blob to allow 3rd parties to verify a Game Center identity, using generateIdentityVerificationSignatureWithCompletionHandler. The data you get back includes the publicKeyUrl, but not which URLs to expect. A naive implementation would just download the public key and run with it. Bad for two reasons: you're now downloading data from an arbitrary location and you are trusting a signature that you verified using untrusted information. In case anyone is interested, the two locations I've seen Apple provide here are https://sandbox.gc.apple.com and https://static.gc.apple.com .
Now annoyingly the ELB on AWS just bounces PATCH requests with a 405 Method Not Allowed. Our services are affected by this and I noticed there is a bug open over at Heroku regarding the same issue. It's something Amazon don't document though so you only find out through testing after you already created your planned stack...