php.net |  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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: cryogen at mac dot com
New email:
PHP Version: OS:

 

 [2006-05-06 00:19 UTC] cryogen at mac dot com
Description:
------------
I have been using base64_encode/decode for the past 2 years to 
pass complex SQL statements in href links between scripts 
running under php 5.0.4.  After upgrading to 5.1.2 I 
experienced errors and missing data using the same functions.  
I get the same results in php 5.1.4.

It appears that data is being lost or garbled in either the 
encode or decode.

This problem does NOT occur on our production server running 
5.0.4.

NOTE: Unable to post code to reproduced bug on production 
server as we cannot install 5.1.x if there is a problem.  I 
tried to keep it as short as possible and illustrate the bug. 

Reproduce code:
---------------
// base64_bug1.php - Demo bug with base64_encode/decode
//--------------
$query = "SELECT DISTINCT class.class_no, class.status, class.class_id, class.sess_group, class.short_desc, class.classroom, class.ages, class.capacity, csc.beg_date, csc.end_date, csc.end_date_infinite_flag, csc.open_sched_flag, ins.lname, ins.fname, CONCAT(ins.fname,' ',ins.lname) AS ins_full_name, csc.w_mon, csc.w_mon_time, csc.w_mon_duration, csc.w_tue, csc.w_tue_time, csc.w_tue_duration, csc.w_wed, csc.w_wed_time, csc.w_wed_duration, csc.w_thu, csc.w_thu_time, csc.w_thu_duration, csc.w_fri, csc.w_fri_time, csc.w_fri_duration, csc.w_sat, csc.w_sat_time, csc.w_sat_duration, csc.w_sun, csc.w_sun_time, csc.w_sun_duration FROM class_sched_cfg AS csc, class LEFT JOIN class_sched AS cs ON class.class_id = cs.class_id LEFT JOIN class_instruct AS ci ON (class.class_id = ci.class_id AND ci.primary_ins_flag = 1) LEFT JOIN instructor AS ins ON ci.ins_id = ins.ins_id WHERE class.co_id = 55555 AND class.class_id = csc.class_id AND (((cs.beg_time > '01:00:00' AND cs.beg_time < '23:00:00') OR (cs.end_time > '01:00:00' AND cs.end_time < '23:00:00')) OR (cs.beg_time <= '01:00:00' AND cs.end_time >= '23:00:00')) AND sess_group LIKE 'spring/summer%' AND (class.status = 'A' AND CURDATE() <= csc.end_date) ORDER by short_desc";

$tmp = base64_encode($query);
echo "<a href='base64_bug2.php?query=".$tmp."'>Pass Data</a>";
?>

// base64_bug2.php - Demo bug with base64_encode/decode
//--------------
echo "<b>We should get our original encoded Value back.<br/>Encoded Value Prior to base64_decode:</b><br/> ".$_REQUEST['query'];

$query = base64_decode($_REQUEST['query']);

echo "<p><b>Value After base64_decode:</b><br/> ".$query;
echo "<p><a href='encode_bug1.php'>Back to Step 1</a>";
?>

Expected result:
----------------
I should have gotten my original SQL string back after 
executing the base64_decode().  I get part of the string back 
with the last couple lines garbled with crazy characters.

Actual result:
--------------
I get part of the original string back with the last couple 
lines garbled with crazy characters.  Here is the actual 
output from script base64_bu2.php:

SELECT DISTINCT class.class_no, class.status, 
class.class_id, class.sess_group, class.short_desc, 
class.classroom, class.ages, class.capacity, csc.beg_date, 
csc.end_date, csc.end_date_infinite_flag, 
csc.open_sched_flag, ins.lname, ins.fname, CONCAT
(ins.fname,' ',ins.lname) AS ins_full_name, csc.w_mon, 
csc.w_mon_time, csc.w_mon_duration, csc.w_tue, 
csc.w_tue_time, csc.w_tue_duration, csc.w_wed, 
csc.w_wed_time, csc.w_wed_duration, csc.w_thu, 
csc.w_thu_time, csc.w_thu_duration, csc.w_fri, 
csc.w_fri_time, csc.w_fri_duration, csc.w_sat, 
csc.w_sat_time, csc.w_sat_duration, csc.w_sun, 
csc.w_sun_time, csc.w_sun_duration FROM class_sched_cfg AS 
csc, class LEFT JOIN class_sched AS cs ON class.class_id = 
cs.class_id LEFT JOIN class_instruct AS ci ON 
(class.class_id = ci.class_id AND ci.primary_ins_flag = 1) 
LEFT JOIN instructor AS ins ON ci.ins_id = ins.ins_id WHERE 
class.co_id = 55555 AND class.class_id = csc.class_id AND 
(((cs.beg_time 	?N??	?S??˘?Y??[YH	̌Ό?	?HԈ ?˙[??[
YH?	?N??	?S??˙[??[YH	̌Ό?	?JHԈ ?˘?Y??[YHH
	?N??	?S??˙[??[YH?H	̌Ό?	?JHS??\???ܛ?\R?H
	???[????[[Y\?I?S? ?\?˜?]\?H	?I?S??T?UJ HH??˙[??]
JHԑT??H????\?

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-05-06 09:12 UTC] tony2001@php.net
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] et@php.net
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.

Notes:
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 
garbage.

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] et@php.net
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-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 23 16:01:30 2024 UTC