3 ms·

Be wary if you do anything with signed data before you verify the signature. http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ http://www.thou

by bbrazil 12y ago

Be wary if you do anything with signed data before you verify the signature. http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...

ploxiln 12y ago
That's a great link (which I've seen before) and I upvoted it. But these "typical JWT lib api vulns" are WAY SIMPLER than Vaudenay etc. Any programmer could do this in minutes or less. WOW. It's so obvious and straightforward (in hindsight I suppose). My mouth is still hanging open.
- bbrazil 12y ago
  We've recently been looking at adding JWT, and one of the things I looked out for was that we were protected against downgrade attacks. This was done both as a check of the current library code, and an explicit check on our side that the alg is what we expect to protect against future library changes.
Arnout 12y ago
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 https://sandbox.gc.apple.com and https://static.gc.apple.com https://static.gc.apple.com .

by bbrazil 12y ago

ploxiln 12y ago

That's a great link (which I've seen before) and I upvoted it. But these "typical JWT lib api vulns" are WAY SIMPLER than Vaudenay etc. Any programmer could do this in minutes or less. WOW. It's so obvious and straightforward (in hindsight I suppose). My mouth is still hanging open.

bbrazil 12y ago
We've recently been looking at adding JWT, and one of the things I looked out for was that we were protected against downgrade attacks. This was done both as a check of the current library code, and an explicit check on our side that the alg is what we expect to protect against future library changes.

Arnout 12y ago

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 https://sandbox.gc.apple.com and https://static.gc.apple.com https://static.gc.apple.com .