fix(crypto): reject non-canonical base64url input - #34
Merged
Conversation
Node ignores the unused low bits of a final base64url character, so 'aGVsbG8', 'aGVsbG9', 'aGVsbG-' and 'aGVsbG_' all decoded to "hello". Four spellings, one value — enough to slip past anything keyed on the encoded form rather than the bytes: a deny list, a dedupe set, a replay cache. `@exortek/shared/base64url` already guards this with a round-trip check; crypto's own decoder validated the alphabet but not the canonical form. It now re-encodes and compares, accepting padding and everything `encode` produces. Behaviour change, so a minor rather than a patch — input that previously decoded may now raise INVALID_ENCODING.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Independent. This one carries a behaviour change — see the note at the bottom.
Node ignores the unused low bits of a final base64url character, so four distinct strings decoded to the same bytes:
Four spellings, one value — enough to slip past anything keyed on the encoded form rather than the bytes: a deny list, a dedupe set, a replay cache.
@exortek/shared/base64urlalready guards this with a round-trip check; crypto's own decoder validated the alphabet but not the canonical form. It now re-encodes and compares.The JOSE stack (jwt, jws, jwe, jwk, paseto, security) already routes through the strict shared decoder, so this is confined to crypto's public encode surface. Verified separately that a malleated JWS signature is rejected with
INVALID_SIGNATURE.Behaviour change — released as a minor, not a patch. Input that previously decoded may now raise
INVALID_ENCODING. Padding is still accepted, and everythingencodeproduces still round-trips. The changeset spells this out for consumers.