|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #37336 base64_encode/decode bug
Submitted: 2006-05-06 00:19 UTC Modified: 2006-05-06 20:27 UTC
From: cryogen at mac dot com Assigned:
Status: Not a bug Package: *Encryption and hash functions
PHP Version: 5.1.4 OS: Mac OS X 10.4.6
Private report: No CVE-ID: None
 [2006-05-06 00:19 UTC] cryogen at mac dot com


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-05-06 09:12 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

 [2006-05-06 17:21 UTC] cryogen at mac dot com
The reproduce code I put in my original post is the 
functioning example.  It represents 2 short scripts.  Each 
script start with two lines of comments.  Just paste those 
into your editor and save each one using the script name found 
on the first comment line.  It should be fairly easy to test 
using the provided script to see the results.
 [2006-05-06 17:51 UTC]
If you are using the function like in your code example, there is no bug.

base64 uses + as one of the encoded characters. When passing + in a query string, it will result in a space, and if you decode a base64 string where all + have been replaced with a space, it is obvious that the result will be different. Use (raw)urlencode on the result before putting it into a hyperlink.

a) base64_encode is NOT an encryption or hashing function.
b) If you have that code somewhere on the freely accessible web, you really should read about SQL Injection.
 [2006-05-06 18:45 UTC] cryogen at mac dot com
Thanks for your quick response.  As I mentioned in my post, 
i have been using the same code for 2+ years and it only 
stopped functioning after upgrading php to 5.1.x, while it 
continues to work without a problem in 5.0.4.

Since I do not base64_encode any "+" characters in my 
strings, this is not the issue.  Please look at the garbled 
text in my results from my original post.  It is not simply 
an issue of getting back space characters for plus signs in 
the original string (since there are none) but in my example 
the last 60 or so characters of the original string are 

And again running the exact two scripts under PHP 5.0.4 
correctly base64_encodes and decodes the string properly.  
Please look further into this.  So something has changed 
between version 5.0.4 and 5.1.x in those functions.  Thanks 
for the support.
 [2006-05-06 18:58 UTC] cryogen at mac dot com
Quick Followup:  I echo'd the base64_encode of the string to 
see if their were any embedded "+" characters and do indeed 
see one about 4/5 of the way through the encoded string.  
This may be the problem.

But, if this is indeed my problem, why does this same script 
work under PHP 5.0.4?  Something has changed in the 
base64_endode() function.  Since we use this type of code in 
dozens of places throughout our online product, it will be 
difficult and expensiver to track down and fix all of them.
 [2006-05-06 20:27 UTC]
Right, something changed. Whitespace was not properly ignored before, see bug #34214.

The solution to your problem is simply urlencoding the value, like you should with any value that you pass via hyperlinks that could contain special characters (like +).
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Tue Jun 19 20:01:45 2018 UTC