Further exploitation about sign/encrypt attack about jose-jwt

[dvsekhvalnov]

Hi @P3ngu1nW ,

i neither quite sure what fix you are looking for nor what 'set a maximum token size for expansion' means.

You can deregister compression via: https://github.com/dvsekhvalnov/jose-jwt?tab=readme-ov-file#deregister-algorithm-implementations or https://github.com/dvsekhvalnov/jose-jwt?tab=readme-ov-file#strict-validation

If you want to put max cap on incoming token length - it's beyond library responsibility and honestly quite easy to do before calling library.

[dvsekhvalnov]

Can probably limit memory decompression buffer size by default to some reasonable value. And make it configurable.
What can be good default?

[P3ngu1nW]

Maybe we can learn from Azure’s approach and set an upper limit of 250K.

https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/wiki/zipcve

[dvsekhvalnov]

yeah, i think doable. let's mark for next release.

[dvsekhvalnov]

@P3ngu1nW i've put fix for decompression thing: #238 will be part of v5 release.

Also, i guess figured out what did mean by unit test:

string s = Jose.JWT.Decode(eviltoken, Key, JwsAlgorithm.RS256);

that line doesn't really protects you, right? I think there is a bug in strict validation, it doesn't apply signing check to encrypted tokens and vice versa. Will fix it too.

[dvsekhvalnov]

v5.0.0 released to nuget.org

https://github.com/dvsekhvalnov/jose-jwt/releases/tag/v5.0.0