setSignature in JWS should fail when invalid characters are detected prior to running base64urldecode

[Gavin Wu]

Problem line: https://bitbucket.org/b_c/jose4j/src/9767aa4dd40d83aee6bbb12bc03708e9d4549dd3/src/main/java/org/jose4j/jws/JsonWebSignature.java#lines-125

rfc4648 : https://datatracker.ietf.org/doc/html/rfc4648#section-3.3
"Implementations MUST reject the encoded data if it contains characters outside the base alphabet when interpreting base-encoded data"

The base64UrlDecode currently just ignores all non base64URL supported characters.
The underlying decoder library is: https://bitbucket.org/b_c/jose4j/src/9767aa4dd40d83aee6bbb12bc03708e9d4549dd3/src/main/java/org/jose4j/base64url/internal/apache/commons/codec/binary/Base64.java#lines-4:5 which is outdated. In the newer version 1.13, it should throw an error when non-base64url characters are detected prior to decoding.

Here is a defect against the CODEC-134: https://issues.apache.org/jira/browse/CODEC-134

Expected behavior:

• in setSignature, the underlying library should check for invalid base64URL characters BEFORE attempting to decode

Alternatively, the base64urldecode provided by the Apache Commons Codec library can be switched to JDK's java.util.Base64 class which is available since Java 8 and provides a safe implementation of base64 URL decode.

[Brian Campbell]

Hi Gavin,

Are there concrete security or functional issues here? To be candid, that behavior from the (copied) v1.9 Base64/BaseNCodec code has been that way for over a decade and is known and even expected behavior at this point. True, it’s not strictly inline with the bit of RFC4648. But it’s a “be liberal in what you accept” kinda thing that’s made the library somewhat more tolerant in what it can process. And changing it would entail a number of compatibility, interoperability, etc., risks that I’m not too keen to take on or pass on to users of this library.

‌