Forum Moderators: coopster
My host is now running PHP 5.2 and I have found that I have had to set my htaccess file to read 'php_flag register_globals On' for my scripts to work.
Would it be now good practice to start declaring my variables so I dont need to turn on register globals?
Can I get some feedback on how best to do this when using 'get' and 'post'?
it is easy to use $_POST and $_GET instead. just put the variable name like echo $_POST['varName']; since it is an associative array so within a string you can use it like echo "{$_GET['varName']} welcome";
I have written my own class for this purpose, which has a function get_value(); which checks all the global arrays and get me the variable value. You can do that too.
yes, absolutely
>> Can I get some feedback on how best to do this when using 'get' and 'post'?
you need to assign the variables from POST, GET or other explicitly to local variables. You can even use the as is $_POST['varname'] but I wouldn't suggest that. You need to make sure that these variables are safe/clean before using them in your code since they are all supplied by the user.
How you clean them will depend on what type of data is expected. You could look at this thread
PHP Security [webmasterworld.com]
>> which checks all the global arrays and get me the variable value
if this works along the same lines as extract then this also may be a security issue
1) Huge security implications which forced PHP to ship with register globals defaulting to OFF starting at version 4.2.0
2) The feature will be deprecated with PHP 6.
So you should really get out of the habit of using this feature ASAP.
though the links at the end of the article are good
What are the things that you consider "just plain wrong"?
very site specific and my answer would be "no you shouldn't"
>> the best solution is to use a source code version control system like CVS
disagree, for most this would be insanity
>> If you must store a password in a session variable (and I stress again that it's best just to avoid this)
then why give code to do it, just say "don't do it, ever". Then goes into a bunch about encryption that would be better spent on saving passwords to a db than saving them to a cookie, which again is not recommmended
>> The easiest way to protect against this is simply to escape the characters that make up HTML syntax (in particular, < and >)
a matter of opinion really, most of your user input shouldn't have tags in it at all and you should just rip them out, no problem
I know his bit on XSS essentially says, these other sites are better so read them, but I think that portion of his article assumes too much and could be misleading.
>> most particularly the single quotes ('). The simplest way to do this is to use PHP's addslashes() function.
well, he mentioned php 4.3 earlier and mysql_real_escape_string was available then and mysql_escape_string was what we muddled through with for a bit before that. Yes, that is db specific but it at least deserves a mention.
the next whole part about magic_quotes is out of place in the article and mainly wrong
The whole injection bit is just lean, it gives an image that isn't really the truth. A better and shorter way to say it would be to tell people to find out escape chars for their db and mainly just to make sure that all data is tested for what is expected and then run through a db safe function if one exists.
the whole data handling section is somewhat light. You could write a whole site on that alone but I thought it was just a bit off target, especially this part "Archive the data and store it offline, limiting the amount of data that can be compromised if your Webserver is breached", ah geez
overall the first page was good until we got to xss and then went downhill from there, the end was strong as the further reading was good.
just my opinions, no one need agree :)
A FREE, Volunteer article or post, I think, should be expected to have misleading information. Because a highly paid expert cannot spend hours to write an authenticated post or guideline for someone, it feels like some kind of overhead to them...
As we are getting modern versions of programming languages and tools we will keep changing our thoughts and techniques. It is possible that some day browser will be intelligent enough to handle most of the stuff we do with coding now. dreaming.... :)
