Ravens PHP Scripts: Forums
 

 

View next topic
View previous topic
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> General/Other Stuff
Author Message
Gremmie
Former Moderator in Good Standing


Joined: Apr 06, 2006
Posts: 2415
Location: Iowa, USA

PostPosted: Thu Oct 19, 2006 7:03 pm Reply with quote

So after using PHP-Nuke for a few months and writing my own modules, I decided to get a book about PHP and MySQL... Razz

In the book, they get user supplied variables from either $_GET or $_POST arrays.

Does PHP-Nuke require register_globals to be On? My host just happens to have it On. But in my XAMPP setup, it looks like it is Off. But Nuke runs just fine in either. I'm confused... Confused

For example, how does the Downloads module get the value of $d_op? I don't see it reading $d_op from $_GET or $_POST. And I didn't find any code in a central spot like mainfile.php that is converting $_GET variables into global variables....?

Thank you.
 
View user's profile Send private message
Raven
Site Admin/Owner


Joined: Aug 27, 2002
Posts: 17077

PostPosted: Thu Oct 19, 2006 10:50 pm Reply with quote

It runs without it and you should too, for security.
 
View user's profile Send private message
evaders99
Former Moderator in Good Standing


Joined: Apr 30, 2004
Posts: 3221

PostPosted: Thu Oct 19, 2006 10:54 pm Reply with quote

It uses import_request_variables... essentially it will allow register_global operations when register_globals itself is not enabled

_________________
- Only registered users can see links on this board! Get registered or login! -

Need help? Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message Visit poster's website
Gremmie
PostPosted: Fri Oct 20, 2006 7:20 am Reply with quote

Thank you evaders, looks like I have some more reading to do. I'm still trying to understand the implications of all this.

It would seem to me after skimming the docs for 5 minutes that using import_request_variables() is just as unsafe as using register_globals = on...? It looks like a compromise to get php-nuke to run on systems regardless of the register_globals setting?
 
fkelly
Former Moderator in Good Standing


Joined: Aug 30, 2005
Posts: 3312
Location: near Albany NY

PostPosted: Fri Oct 20, 2006 9:32 am Reply with quote

That's such a good question about d_op and downloads that it ruined my morning.

I believe that what is happening here is:

look at the bottom of index.php in the downloads directory. There is a switch testing $d_op. I believe that it gets the $_GET operator d_op automatically. In other words that variable is available by virtue of it being a $_GET and you don't need to do a $_GET to get it. (Anyone correct this if I'm wrong). So take the case of adddownload. If the d_op switch is set to that you'll execute the function adddownload which you can find in index.php. When you do that you'll execute the function menu() which is also in index.php. Look down in there and you'll see the form action which passes the module name (download) to modules.php and also the d_op operator.

Sample code from there:
Code:


if ($user_adddownload == 1) {
   echo "<a href=\"modules.php?name=$module_name&amp;d_op=AddDownload\">"._ADDDOWNLOAD."</a>"
      ." | ";
   }
   echo "<a href=\"modules.php?name=$module_name&amp;d_op=NewDownloads\">"._NEW."</a>"
      ." | <a href=\"modules.php?name=$module_name&amp;d_op=MostPopular\">"._POPULAR."</a>"
      ." | <a href=\"modules.php?name=$module_name&amp;d_op=TopRated\">"._TOPRATED."</a> ]"
      ."</font></center>";


This stuff gets convoluted sometimes in Nuke and it's hard to tell where things are called until you get real used to it. If you look at the /admin directory of downloads for instance, you'll find a case.php program which does nothing but "drive" where things go depending on circumstances.
 
View user's profile Send private message Visit poster's website
Gremmie
PostPosted: Fri Oct 20, 2006 9:50 am Reply with quote

fkelly,

If register_globals was on, then the variable $d_op would have a value if it got passed to it as part of the URL query.

If register_globals is off, then the downloads module would have to be rewritten to get the value of $d_op from the $_GET or $_POST arrays.

However, nuke (thanks to evaders) apparently calls a function called import_request_variables() somewhere, which brings in the variables from the URL query and makes them globals. So its kind of like having register_globals on.

There is a great deal of info about this at Only registered users can see links on this board! Get registered or login! just look for register_globals.

I suspect what happened was that Nuke was always coded with the assumption that the register_globals = on behavior was there (since it has long roots). Then, somewhat recently, in a new'ish version of PHP, PHP made register_globals = off the default because it is safer. This totally broke Nuke, but luckily there was this import_request_variables() function. So a call to that got added somewhere...(where is it, mainfile.php?) and now it works in both environments. Thats just me guessing though.
 
fkelly
PostPosted: Fri Oct 20, 2006 10:15 am Reply with quote

From mainfile.php

Code:
if (!ini_get('register_globals')) {

   @import_request_variables('GPC', '');
}
 
Gremmie
PostPosted: Fri Oct 20, 2006 11:00 am Reply with quote

Thanks fkelly.

So if we were to write the next generation CMS, wouldn't we want to use the current PHP best practices, and go to the $_GET and $_POST arrays to get user input and not pretend that register_globals is on like Nuke does?

I suppose that nothing is preventing a new module author for a current Nuke from using $_GET, etc for more safety. I should rewrite the 2 modules I created with this technique to see if there are any issues with that.

Thoughts?

Thanks everyone I have learned a lot in the past few hours. Cheers
 
evaders99
PostPosted: Fri Oct 20, 2006 12:06 pm Reply with quote

Yes, it would be better if modules read $_GET and $_POST and secure all inputs themselves. Sadly, phpNuke provides the quick measure of import_request_variables and this has allowed addons to slack. Even the phpNuke code is so heavily reliant on the register_globals functionality, it will take a good amount of work to rewrite it to use all $_GET/$_POST variables.

That may be a future goal for RavenNuke, but it is just not handled at this stage. All addons would have to take this into account where compatibility is concerned.
 
fkelly
PostPosted: Fri Oct 20, 2006 12:39 pm Reply with quote

I have a couple of custom modules. I use $_POST extensively and after Raven taught me a few things Smile I "sanitize" all the variables that are read in thru $_POST even though in most cases I've already validated them with Javascript while the form is being filled out. I've never found an occasion to use $_GET and I don't much like exposing the "internals" up on the address bar so people can see what's going on.

You should probably also be aware that Sentinel runs a pretty good set of tests against $_GET and $_POST variables too before they even get to your application logic. For instance your form will have an action but it will go thru modules.php to get to the action screen and when it does modules.php includes mainfile.php which in turn includes nukesentinel.php which in turn does its screening. One of the problem people new to Nuke have (and probably some oldbies too) is tracing this complex flow of logic when there is a problem to determine exactly where the problem is occurring.
 
Gremmie
PostPosted: Fri Oct 20, 2006 12:49 pm Reply with quote

Yeah, me too, I've never trusted client side Javascript to do any validation for me. I've always assumed someone could turn off Javascript in the browser and send me something sneaky.

And if you were writing a general module, you can't assume the poor dope installing it into his Nuke is running Sentinel. (Of course he should...) So you would probably still want to run your own checks on the $_POST and $_GET variables.
 
montego
Site Admin


Joined: Aug 29, 2004
Posts: 9449
Location: Arizona

PostPosted: Fri Oct 20, 2006 6:39 pm Reply with quote

fkelly, I am glad that you are still sanitizing them server-side (very important to do ALWAYS), but want to just point out the following for the "readership":

Quote:

I "sanitize" all the variables that are read in thru $_POST even though in most cases I've already validated them with Javascript while the form is being filled out


I just don't want folks to think that using Javascript is appropriate for sanitizing input. Very easily bypassed, as in reality, because all I have to do is write a form on my own domain with the GET or POST action comparable to what you are using... no javascript.

Javascript is great for providing client-side field validation just from an end-user experience perspective, meaning that most of their input errors can be caught up-front without having to take the "round trip" to the server and back each time.

_________________
Only registered users can see links on this board! Get registered or login!
Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message Visit poster's website
fkelly
PostPosted: Fri Oct 20, 2006 7:17 pm Reply with quote

Probably "sanitize" was an inappropriate word to use to describe what I try to do with Javascript. Wherever possible I try to "edit" fields on forms "immediately" ... for instance if they enter a phone number as soon as they onmouseout (or whatever that syntax is) I try to make sure that it's in the right format for a phone number and give them a meaningful message right away. Same thing with date fields, though I usually try to have them picked from drop downs.

There is some duplication of effort but it's necessary. I may "know" that the date field that comes from MY form is valid because of the Javascript validation but that doesn't mean that someone external isn't submitting something that looks like my form but really is just hiding a link to an external script in the date field. Well, that might be hard to get thru because MYSQL would probably cough it up for not being in date time format but they could stick something nasty in any text field if I didn't validate the $_POST.

Just as an aside I found out the hard way that browsers, especially MAC based browsers have limited support for onmouseout type actions so you can run into compatibility issues. And Javascript is IMHO a pita to debug and, though I can't quite put a finger on it, syntatically quirky.
 
djmaze
Subject Matter Expert


Joined: May 15, 2004
Posts: 719
Location: http://tinyurl.com/5z8dmv

PostPosted: Sat Oct 21, 2006 4:38 am Reply with quote

another crappy thing is magic_quotes and finally it's off by default.
 
View user's profile Send private message Visit poster's website
technocrat
Life Cycles Becoming CPU Cycles


Joined: Jul 07, 2005
Posts: 511

PostPosted: Mon Oct 23, 2006 10:14 am Reply with quote

And finally gone in PHP 6

_________________
Only registered users can see links on this board! Get registered or login!
Only registered users can see links on this board! Get registered or login! / Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message
montego
PostPosted: Wed Oct 25, 2006 7:03 am Reply with quote

:clap:
 
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> General/Other Stuff

View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2007 phpBB Group
All times are GMT - 6 Hours
 
Forums ©