[geeklog-devel] Re: [geeklog-devtalk] Variable best practices

Blaine Lang geeklog at langfamily.ca
Wed Mar 3 10:59:43 EST 2004


Tony,

I don't disagree and using $_REQUEST would remove the need to check both GET
and POST.
I wonder though, if it is not still more secure to check for $_POST before
$_GET. I know a hacker can just as easily fake a POST request so maybe it
does not matter. As long as we are filtering out any potentially hostile
data.

I suspect our issues are mostly with users that host their sites.

That still leaves the question or feedback and using the concept I used in
this function for setting up which variables you want to filter and calling
the filter once.
It also has a mode to address the need for Register_Globals on.

Blaine
----- Original Message ----- 
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-devel at lists.geeklog.net>
Sent: Wednesday, March 03, 2004 10:12 AM
Subject: [geeklog-devel] Re: [geeklog-devtalk] Variable best practices


> Knowing that there have been security issues with anything prior to 4.2
> (and, indeed, after), I don't think it is a stretch to have Geeklog
> require 4.1 or better.  In fact, we should probably have a rule that
> Geeklog will support so many revisions behind the most current.  I mean,
> seriously, should we be concerned with people who are still using
> pre-4.1 (hell, the 5.0 launch isn't all that far away)?  I think
> not....simply because I can't fatham that many people out there with
> that old of a version.  Sure, that means you have some inconsistent code
> (i.e. some that can handle no register_globals and some that can) but to
> me that at least introduces the ability to start making the switch and,
> at the very least, encourages good coding habits.
>
> As you can tell, I have an opinion.  I say ditch pre-4.1 support and
> let's start using $_REQUEST, $_GET, $_POST and be happy.  I, of course,
> could be swayed if there is enough uproar to convince me pre-4.1 support
> is needed.
>
> Thoughts?
>
> --Tony
>
> Blaine Lang wrote:
> > Maybe, I can only receive emails on this list ;)
> >
> > Another suggestion where this function would be helpfull is in say .....
> >  admin/topic.php -- I believe $tid and $topic are variables that are
> > passed as GET or POST vars.
> >
> > You need to check for both, post is higher in presidence and if not set
> > it to '';
> >
> > Just a thought -- I'll stop sharing now.
> >
> >     ----- Original Message -----
> >     *From:* Blaine Lang <mailto:geeklog at langfamily.ca>
> >     *To:* geeklog-devtalk at lists.geeklog.net
> >     <mailto:geeklog-devtalk at lists.geeklog.net>
> >     *Sent:* Sunday, February 29, 2004 1:19 PM
> >     *Subject:* Re: [geeklog-devtalk] Variable best practices
> >
> >     I've been wanting to address this issue for a while and have come up
> >     with the following function.
> >
> >     It will filter either GET, POST or both (as in my need noted below -
> >     but look for POST first).
> >     It will appy the data filter - default mode for now.
> >     It will also optionally create GLOBALS out of the variables. This
> >     could be used to remove a dependany on Register_globals.
> >
> >     Example use:
> >
> >     $myvars = array('op','profileid','memberid');
> >     getdata($myvars,true);
> >
> >     or
> >
> >     $formvars = array('profile_name','member_num', 'member_addr',
> >     'member_city', 'member_phone');
> >     $formdata = array();
> >     $formdata = getdata($formvars,'POST');
> >
> >     << code begin >>
> >
> >     function getdata($vars,$setglobal=false,$type='')  {
> >       $return_data = array();
> >
> >       #setup common reference to SuperGlobals depending which array is
> >     needed
> >       if ($type == "GET" OR $type == "POST") {
> >         if ($type=="GET") { $SG_Array=& $_GET; }
> >         if ($type=="POST") { $SG_Array=& $_POST; }
> >
> >         # loop through SuperGlobal data array and grab out data for
> >     allowed fields if found
> >         foreach($vars as $key)  {
> >           if (array_key_exists($key,$SG_Array)) {
> >     $return_data[$key]=$SG_Array[$key]; }
> >         }
> >
> >       } else {
> >         foreach ($vars as $key) {
> >           if (array_key_exists($key, $_POST)) {
> >             $return_data[$key] = $_POST[$key];
> >           } elseif (array_key_exists($key, $_GET)) {
> >             $return_data[$key] = $_GET[$key];
> >           }
> >         }
> >       }
> >
> >         # loop through $vars array and apply the filter
> >         foreach($vars as $value)  {
> >           $return_data[$value]  = COM_applyFilter($return_data[$value]);
> >         }
> >
> >       // Optionally set $GLOBALS or return the array
> >       if ($setglobal) {
> >           # loop through final data and define all the variables using
> >     the $GLOBALS array
> >           foreach ($return_data as $key=>$value)  {
> >             $GLOBALS[$key]=$value;
> >           }
> >       } else {
> >           return $return_data;
> >       }
> >
> >     }
> >
> >
> >
> >         ----- Original Message -----
> >         *From:* Blaine Lang <mailto:geeklog at langfamily.ca>
> >         *To:* geeklog-devtalk at lists.geeklog.net
> >         <mailto:geeklog-devtalk at lists.geeklog.net>
> >         *Sent:* Sunday, February 29, 2004 10:19 AM
> >         *Subject:* [geeklog-devtalk] Variable best practices
> >
> >         As a practce, I try not to have any register_globals
> >         dependancies. I will use the full $HTTP_POST_VARS
> >         and $HTTP_GET_VARS variable names. I'd lole to use the other
> >         supper globals ($_REQUEST, $_POST and $_GET) and are still
> >         dependant on php version 4.1 or greater. Most hosting services
> >         should be running by now but it can not be assumed I guess.
> >
> >         I'm filtering all expected POST and GET vars now in my new
> >         plugins and there are still times it makes sense to use the same
> >         name in the POST and GET. It may be passed in the URL or form so
> >         you have to check both but I check the post first as I would use
> >         that first if I can post a hidden variable.
> >
> >         Examples are:
> >         using $op to indicate operation. I may be triggered from a link,
> >         selectbox, image or button in the UI. I may also have to pass it
> >         to another script.
> >         using $page and $sort as part of the page google like navigation
> >         (links) but you also need to retain this as hidden fields in
> >         forms if you want to retain your page position.
> >
> >         I don't see the reason to use different names with the get and
> >         post as this allows me more control. I only expect it one way or
> >         the other and POST should override get.
> >
> >         Hense why I end of having all this extra code at the top of
scripts:
> >          > if (isset($HTTP_POST_VARS['op']) ) {
> >          >     $op = clubApplyFilter($HTTP_POST_VARS['op']);
> >          > } elseif (isset($HTTP_GET_VARS['op']) ) {
> >          >     $op = clubApplyFilter($HTTP_GET_VARS['op']);
> >          > } else {
> >          >     $op = '';
> >          > }
> >
> >         Is this how others would approach this?
> >
> >         I was thinking if I am having to repeat this practice and common
> >         code, others would as well. Extending my class object to handle
> >         this would be an advantage.
> >         $myfilter = new COM_filter;
> >         $myfilter->_censor = true;
> >         $myfilter ->_jsfilter = true;
> >         $op = $myfilter->_setvar('op', 'text');
> >
> >         Cheers,
> >         Blaine
> >
> >
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel




More information about the geeklog-devel mailing list