Currently, when providing binascii.a2b_base64() base-64 input with excess data after the padding ('='/'=='), the excess data is ignored.

Example:

import binascii
binascii.a2b_base64(b'aGVsbG8=')       # b'hello' (valid)
binascii.a2b_base64(b'aGVsbG8==')      # b'hello' (ignoring data)
binascii.a2b_base64(b'aGVsbG8=python') # b'hello' (ignoring data)


Note: MANY libraries (such as the all-time favorite `base64`) use this function as their decoder.


Why is it problematic:
* User input can contain additional data after base64 data, which can lead to unintended behavior in products.
* Well-crafted user input can be used to bypass conditions in code (example in the referenced tweet).
* Can be used to target vulnerable libraries and bypass authentication mechanism such as JWT (potentially).


The logic behind my fix PR on GitHub:
* Before deciding to finish the function (after knowing the fact that we passed the data padding),
  we should check if there's no more data after the padding.
* If excess data exists, we should raise an error, free the allocated writer, and return null.
* Else, everything's fine, and we can proceed to the function's end as previously.


Though not publicly disclosed, this behavior can lead to security issues in heavily-used projects.
Preventing this behavior sounds more beneficial than harmful, since there's no known good usage for this behavior.

From what I read, the python implementation in not so close (when speaking about this case of course) to the base64 RFC.
(link: https://tools.ietf.org/html/rfc4648#section-3.3)


Thanks to Ori Damari (twitter: https://twitter.com/0xrepnz) for bringing this behavior up,
and thanks to Ryan Mast (twitter: https://twitter.com/rmast), and many of the other great guys for discussing the problem in the comments.

Link to the tweet: https://twitter.com/0xrepnz/status/1355295649915404291

--------------------------

Idan Moral
Twitter: https://twitter.com/idan_moral
GitHub: https://github.com/idan22moral