REGISTER GLOBALS - V 1.4 - Richard Bentley 06/03/2006
----------------

For revision information, see the file CHANGE_HISTORY

INTRODUCTION
------------
This contribution consists of a patch that will remove the need to enable the 'register_globals'
option in the php.ini file.

Having register globals enabled is a very serious security issue; it allows an attacker to inject
variables into the running PHP code. Just in case you don't realise, this is a VERY BAD THING.
It also imposes a minor performance overhead. Disabling register globals and using this patch will
prevent the variable injection problem. It will also mostly remove the performance overhead.

In fact, if you use this patch, you MUST disable the 'register_globals' option. if you do not,
things will go horribly wrong - The session management will probably not work correctly because of
the way the patch maps the session variables to the global variable space  - I could be be wrong
on this point, but I wouldn't do it anyway. Besides, what's the point of adding the patch if you are
not going to disable register globals ?

 ===================================================================================================
 >>>>> BEFORE APPLYING THIS PATCH, MAKE SURE YOU HAVE WORKING BACKUPS OF YOUR OSC SCRIPTS !!!! <<<<<
 ===================================================================================================

 ================================================================================================
 >>>>> I URGE YOU TO READ THIS FILE (UP TO THE POINT THAT SAYS YOU CAN STOP READING)        <<<<<
 >>>>> IT'S NOT VERY LONG AND IT COULD SAVE YOU A **LOT** OF GRIEF                          <<<<<
 >>>>>                                                                                      <<<<<
 >>>>> Can I also say that despite this notice, I am AMAZED at how many people have         <<<<<
 >>>>> problems with this patch, the solutions to which are explained in this text!         <<<<<
 >>>>> There's none so deaf as will not hear :-)                                            <<<<<
 ================================================================================================

As of version 1.4, the the 'patch' consists of the following:

1/ A set of instructions (rather than a 'patch' file) that you may use to manually apply the changes
   to an existing code tree. This is useful if you already have modififications made to the OSC source
   code and you want to apply this patch on top.

2/ A set or pre-patched files. These files are EXACTLY the same as you would get if you applied the
   patch instructions to a clean copy of OSC. This is useful if  you are performing a clean installation
   of OSC and therefore have no worries about just copying over existing files with new versions.

   >>> You only need to use either the instructions or the pre-patched files; NOT both <<<

   Which method should you use? Read on...

OS COMMERCE VERSION INFORMATION
-------------------------------

* This patch has been written for OS Commerce, the MS 2.2 release, dated 13/11/2005 (ie - the
  security/bugfix update to the original MS 2.2)

  This patch will also work for the original MS 2.2 release as well (applying it will also add
  a security fix to the session management code that was added to the 13/11/2005 update).

  WARNING: Although this patch will work for MS 2.2 versions prior to the 13/11/2005 update,
  -------  (and, I would guess, stands a good chance of working on later releases if there are
           any) it is very strongly suggested that if applying it to such code, you do **NOT** use
           the pre-patched files. Instead, apply the patch manually

WILL IT WORK FOR ME ? - PHP VERSIONS
------------------------------------

* This patch will not work at all if you are using PHP 3 (is anyone still using PHP 3 ?)

* This patch will not work if you are using PHP 4.0.6 or earlier (but there might be a way to make
 it work if anyone is interested)

WILL IT WORK FOR ME ? - OTHER CONTRIBUTIONS
-------------------------------------------

There are a lot of contributions out there and a lot of modification you can make to OS Commerce.
The only contribution I have assessed when making this patch is easypopulate. I may have also
inadvertently taken into account other patches, but I can't say which ones (I have a lot of changes
in my OS Commerce code). So, if you have contributions that use GET, POST, SESSION etc etc
variables and access them via their global names rather than via the $_GET (or $HTTP_GET_VARS)
arrays (for example) then there is a very good chance that they will not work any more, or they may
seem to work ok but are actually broken (which is even worse and rather dangerous !).

Having said this, I would guess that the vast majority of contributions don't do anythng that would
cause a problem, either because they don't introduce new POST, GET, etc variables or because they
are written correctly in the first place.

For further help, see the included OTHER_CONTRIBUTIONS file - it gives some hints and tips on
how to get other contributions working

Can I also take the opportunity to blow away a myth that seems to crop up now and then. That is,
if you are coding a contribution, you do NOT have to make a choice (in the coding) about whether
it is to run in a 'Register Globals On' environment of an 'Register Globals Off'! If you code
for it to operate in a 'Register Globals Off' environment then it shall always work, regardless
of the register globals setting.

If anyone finds any contributions that are broken as a result of applying this patch, then I
encourage them to post up details on the forums so others can share your fixes. Please don't send
fixes for other contributions directly to me for inclusion in this patch - I'm sorry but I simply
do not have the time to keep revisiting this and adding extra bits to the patch, and besides, I
don't want to include overhead that others have to endure even if they are not using the
contribution in question. Of course, if you find problems with what I have done here, then I will
fix it. I'll also try and keep it  up to date with future releases of OS Commerce (until the
'register_globals' requirement is officially removed)

----------------------------------------------------------------------------------------
INSTALLATION INSTRUCTIONS
-------------------------

Follow ONE (NOT both) of the following instructions...

----------------------------------------------------------------------------------------
1/ USING THE MANUAL PATCH INSTRUCTIONS
   -----------------------------------

  The manual patching instructions are contained in the following file :

  patch_instructions/INSTRUCTIONS

  If all you want to do is install the patch, then read this file and do what it says, and
  DON'T FORGET - After applying the patch, you MUST disable the register_globals option
  in php.ini

  ie, in php.ini :

  register_globals = Off

----------------------------------------------------------------------------------------
2/ USING THE PRE-PATCH FILES
   -------------------------

  >> WARNING <<
  Do NOT use the pre-patched files if you are using a version of OSC other than the
  MS 2.2 13/11/2005 security/bugfix update. If you do, you run a good chance of breaking
  something!!!

  Instructions for applying the pre-patched files (and the pre-patched files themselves)
  can be found here :

  patch_files/INSTRUCTIONS

  If all you want to do is install the patch, then read this file and do what it says, and
  DON'T FORGET - After applying the patch, you MUST disable the register_globals option
  in php.ini

  ie, in php.ini :

  register_globals = Off

----------------------------------------------------------------------------------------
IMPORTANT
---------

After this patch is applied, the OSC scripts (especially the session management) will no longer
work correctly if register_globals is enabled (despite what you might read on the support forum !).

----------------------------------------------------------------------------------------
PROBLEMS (AND ANSWERS)
----------------------

Some people have reported the following warning being printed when this patch is used :

"Warning: session_write_close(): Your script possibly relies on a session side-effect
 which existed until PHP 4.2.3. Please be advised that the session extension does not
 consider global variables as a source of data, unless register_globals is enabled.
 You can disable this functionality and this warning by setting session.bug_compat_42
 or session.bug_compat_warn to off, respectively. in ...<a ref. to sessions.php>

If you get this warning, it is because you have the following two values set in php.ini :

session.bug_compat_42 = 1
session.bug_compat_warn = 1

The scenario described by the warning does NOT apply to this patch (ie - this patch does NOT
make use of the bug/feature in 4.2.3), so it is safe (indeed very desirable) to switch this
functionality and warning off. To remove this functionality and stop the warning, set both
of these parameters in php.ini as follows :

session.bug_compat_42 = 0
session.bug_compat_warn = 0

------
One final point - You might be tempted to change the value of variables_order in php.ini
So was I ! Unfortunately, lots of things break if you change it from its default of "EGPCS".
This is something that probably needs addressing (even if the security issues are eliminated by
removing register_globals, there is still a performance hit with having variables_order set this
way). This is probably a project in itself though. One thing at a time...

Additional: PHP bug 16155 addresses this issue, but at the time of writing, as far as I know
it has not yet been fixed

 ===================================================================================================
 >>>>> OK, IF ALL YOU WANT TO DO IS APPLY THE PATCH, YOU CAN STOP READING NOW                  <<<<<
 ===================================================================================================

TECHNICAL STUFF
---------------
The rest of this README file contains some technical information about what I have done. You do not
need to know this to use the patch but I am including it here in the hope that the good people out
there will look at it and tell me if I have done anything wrong or misunderstood anything !

If anyone out there finds any errors in what I have done, PLEASE LET ME KNOW and I shall update the
contribution accordingly. I shall also have myself soundly flogged for being sloppy and careless.

...whip on standby...

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

GENERAL
-------

Most of the GET and POST variables are actually referenced 'correctly' via the $HTTP_*** global
 arrays, so they have not have to be changed (there are a couple of exceptions, but they are very
 minor)

The biggest issue was handling the session variables. I started by just changing all the references
 to use the $_SESSION array but it became apparent very quickly that this approach was not workable
 - it would lead to a huge number of changes and in my experience, problems = number of changes
 squared.

So, instead, I have patched the session handling routines so that the existing global variables are
 dynamically mapped to the real session variables in $_SESSION. This approach does incur an overhead
 but it's probably no more than having register_globals defined anyway.

I have not modified the .../includes/classes/sessions.php file - my understanding is that this is
 only used for PHP 3 and as this contribution won't work for PHP 3 anyway, I've not changed it

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

CATALOG
-------

This is a list of the global variables I have identified in the .../catalog scripts. For variables
 that I have adjusted in any way, I have marked them with a 'f' for 'fixed'. All variables that are
 not marked by a 'f' are (I believe) ok as they are.

You may also notice that a few of the variables are marked with '?'. I'm pretty sure I have assessed
 these correctly but there's something about the way they are used which makes me a bit doubtful. If
 anyone out there can clarify my understanding then I would be very grateful.

Type of global variable (by 'normal', I mean the variable is not a POST, GET, SESSION etc
 variable)...
-----------------------
s=session
x=Not applicable to the 'register_globals' issue
-=Normal globals but could be non-global (but that's another issue)
+=Normal globals
a=Normal global. Set in application_top
g=_GET
p=_POST
v=_SERVER
c=Class instance (normal)
i=Pulled out of php.ini
~=This is a normal global but redundant

 f=fixed

Variables
---------
 
sf $billto
sf $cart
sf $cartID
-  $categories_string

sf $comments (??? $comment seems to be both a session and s POST variabale - This can't be right !
              Seems to work ok though)
p  $comments

g  $cPath
+  $cPath_array
c  $currencies
sf $currency
sf $customer_account_id
sf $customer_country_id
sf $customer_default_address_id
sf $customer_first_name
sf $customer_id
sf $customer_zone_id

vf $HTTP_ACCEPT_ENCODING
x  $HTTP_COOKIE_VARS
x  $HTTP_GET_VARS
x  $HTTP_POST_VARS
v  $HTTP_REFERER / $GLOBALS['HTTP_REFERER']
v  $REQUEST_URI / $GLOBALS['REQUEST_URI']
x  $HTTP_SERVER_VARS
vf $HTTP_USER_AGENT

-  $insert_id
sf $language
sf $language_id
sf $languages_id
sf $messageToStack
sf $navigation
sf $new_products_id_in_cart
+  $order

sf $payment (??? $payment seems to be both a session and s POST variable - This can't be right !
             Seems to work ok though)
p  $payment

c  $php3session_user
x  $PHP_SELF
vf $REMOTE_ADDR / $GLOBALS['REMOTE_ADDR']
a  $request_type
sf $sendto
v  $SERVER_NAME / $GLOBALS['SERVER_NAME']
c  $session
sf $SESSION_IP_ADDRESS
sf $SESSION_SSL_ID
a  $session_started
sf $SESSION_USER_AGENT
i  $SESS_LIFE
sf $shipping
-? $shipping_num_boxes
~  $shipping_quoted
-? $shipping_weight
a  $SID
-  $total_count
-  $total_weight
+  $tree

-  db_link - Usual reference for $$link in database queries

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

ADMIN
-----

This is a list of the global variables I have identified in the .../admin scripts. For variables
 that I have adjusted in any way, I have marked them with a 'f' for 'fixed'. All variables that are
 not marked by a 'f' are (I believe) ok as they are.

I have added to this list the 'easypopulate' contribution as it is so popular.

An observation that I have made is that there seems to be a huge number of global variables defined
 for easypopulate. This is particularly 'observable' as it is pretty much (completely ?)
 self-contained in one file !

The variable types are identified as per the catalog variables above, but with the following
 additions :

e=Easypopulate-specific - normal global
f=File manager-specific

e  $active
e  $attribute_options_array
e  $attribute_options_select

gf $attribute_page (in products_attributes.php)

g? $banner
-? $banner

f  $cache_blocks
f  $cPath_array
c  $currencies
~  $customer_country_id
-? $customer_id
~  $customer_zone_id

e  $default_image_category
e  $default_image_manufacturer
e  $default_image_product
e  $default_images
e  $default_these
e  $deleteit
e  $epdlanguage_id
e  $fileheaders
e  $filelayout
e  $filelayout_count
e  $filelayout_sql
e  $froogle_image_path
e  $froogle_product_info_path
e  $froogle_SEF_urls

x  $HTTP_COOKIE_VARS
x  $HTTP_GET_VARS
x  $HTTP_POST_FILES
v  $HTTP_REFERER / $GLOBALS['HTTP_REFERER']
v  $REQUEST_URI / $GLOBALS['REQUEST_URI']
x  $HTTP_POST_VARS
x  $HTTP_SERVER_VARS
vf $HTTP_USER_AGENT

e  $inactive
e  $langcode
sf $language
sf $languages_id

-  db_link - Usual reference for $$link in database queries
 
c  $logger
e  $max_categories
e  $maxrecs
c  $messageStack
sf $messageToStack
e  $modelsize
sf $new_products_id_in_cart
gf $option_page (in products_attributes.php)
c  $php3session_user
x  $PHP_SELF
e  $price_with_tax
e  $products_with_attributes
e  $replace_quotes
v  $SERVER_NAME / $GLOBALS['SERVER_NAME']
e  $separator

c  $session

g  $SESS_LIFE
-  $SID (session class-specific)
-  $tep_remove_error
gf $value_page (in products_attributes.php)
-  $xx_mins_ago
e  $zero_qty_inactive

s? selected_box
s? current_path - file manager

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

-eof-
