Bug #72264 [Opn->Csd]: base64_decode $strict fails with whitespace between padding

Edit report at https://bugs.php.net/bug.php?id=72264&edit=1 ID: 72264 Updated by: nikic@php.net Reported by: lauri dot kentta at gmail dot com Summary: base64_decode $strict fails with whitespace between padding -Status: Open +Status: Closed Type: Bug Package: Strings related PHP Version: 7.0.6 Block user comment: N Private report: N New Comment: Automatic comment on behalf of lauri.kentta@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=3380acbdd40f504b08b64c01960dbe8afc91d7ea Log: base64_decode: fix bug #72264 ('VV= =' shouldn't fail in strict mode) Previous Comments: ------------------------------------------------------------------------ [2016-06-16 13:45:26] lauri dot kentta at gmail dot com > Line breaks are allowed, but as far as I know, not in arbitrary > places, and no other whitespace characters are allowed. RFC 4648 (Base* encoding) doesn't cover these issues; it only says that any characters outside the Base64 alphabet MUST be rejected, UNLESS another specification says otherwise. This means that we can really do as we please, since the same function may be used in different contexts. RFC 2045 (MIME) says that "any characters outside of the base64 alphabet are to be ignored in base64-encoded data". This is what the "non-strict" mode does, so this is fine, even though it's really weird to accept stuff like !"#%&. The current C code specifically tries to ignore white-space even in "strict" mode. I think that the PHP documentation is "wrong" in this regard and that this bug should be fixed. It's obvious that the current "strict" mode is actually intended as a sensible mode for any sensible input, with the benefit that anything weird like leaked errors inside the Base64 string will probably produce FALSE. Many tools add line breaks in Base64 data, so it's nice to accept that. (echo -n U | base64 -w3 == "VQ=\n=\n") == true. Also, changing the current behavior to be more strict would cause a BC break, which is probably not acceptable. PHP doesn't really implement a strict mode for Base64. So maybe some day we should implement all three modes: - MIME mode, the current default, ignores any weirdness. - sensible mode, the current "strict", with Base64 + white space - really strict mode, which only accepts 0-9A-Za-z+/= ------------------------------------------------------------------------ [2016-06-16 12:51:08] cmb@php.net > Whitespace (at least line breaks) is allowed in Base64. Line breaks are allowed, but as far as I know, not in arbitrary places, and no other whitespace characters are allowed. > In other words, base64_decode("VV ==") and base64_decode("VV= > =") should yield the same result. ACK. Obviously that is not the case now: <https://3v4l.org/4ZV7T>. ------------------------------------------------------------------------ [2016-06-14 15:20:45] lauri dot kentta at gmail dot com Whitespace (at least line breaks) is allowed in Base64. And even with your logic, at least the whitespace should be handled equally in all cases. In other words, base64_decode("VV ==") and base64_decode("VV= =") should yield the same result. ------------------------------------------------------------------------ [2016-06-14 13:14:20] cmb@php.net In my opinion, this is not a bug, but rather expected behavior[1]: | Returns FALSE if input contains character from outside the | base64 alphabet. [1] <http://php.net/manual/en/function.base64-decode.php> ------------------------------------------------------------------------ [2016-05-25 18:55:23] lauri dot kentta at gmail dot com Description: ------------ base64_decode $strict fails with whitespace between padding. Test script: --------------- <?php var_dump(base64_decode("VV= =", true)); Expected result: ---------------- string(1) "U" Actual result: -------------- bool(false) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=72264&edit=1